5 ms·

I really like the idea behind Fossil ... but on the other hand, I want to bring all development together into one homogeneous interface: I want to do almost eve

I really like the idea behind Fossil ... but on the other hand, I want to bring all development together into one homogeneous interface: I want to do almost everything without leaving Sublime Text. For that reason, I am experimenting with storing all my documentation (requirements, plans, task lists etc...) as text files in a git repository, using YAML when I need structure, and markdown when I need formatting or something richer. To tie everything together, I maintain a diary, which consists of one text file per developer per sprint. This diary holds allocated jobs to do each sprint, together with a record of what was done each day. Because all of my work information is available in the repository as text (markdown or YAML or JSON) - it means that I can automate my workflow in ways that would be much harder to achieve otherwise. For example, I can extract appropriate git commit messages automatically from this diary, meaning that I have perfect traceability back to requirements on every commit. I can get my build to (optionally) commit changes automatically (rolling back if the build was not successful). I can even get it to (again optionally) make sure that all changes associated with a particular job are kept on a separate branch until that job is complete. In other words, I have lots of options when it comes to tying my workflow together with my CMS/VCS in an automated and scripted way. And all because I am too lazy to open my web browser to look at JIRA or Trac (or whatever). :-)

w_t_payne 11y ago
It also means that -- because my "tickets" and "requirements" documents are just bits of YAML with a particular structure -- I can store tickets, requirements and so on pretty much anywhere in the repository - either in their own directories, or interspersed with and embedded within the source code as comments -- sort of like a TODO but with super-powers.
- madeofpalk 11y ago
  > sort of like a TODO but with super-powers. Funnily enough our team just introduced an eslint warning (https://github.com/eslint/eslint/blob/master/docs/rules/no-warning-comments.md https://github.com/eslint/eslint/blob/master/docs/rules/no-w...) to discourage those TODO comments as we found they just always sat around forever collecting lint.
  - falcolas 11y ago
    Similar here. If the todo survives the development branch, it should be moved into the ticketing system. Otherwise, you have two ticketing systems, one of which will be forgotten when it comes time to prioritize new development.
  - w_t_payne 11y ago
    You are quite correct. It is always a bad sign if you have tasks that are captured but never actioned ... (Almost as bad as never capturing the problems in the first place) However, it is just as easy to have unloved, unwatched tasks festering in JIRA or Trac as it is to have TODOs festering in the source code. (I've seen both). The form in which the problem manifests itself isn't terribly important here ... or at least, its' less important than the solution. What is needed is a robust and active process to triage new issues; to action items that really are a problem, and to record the decision to discard problems which are not worth resolving. If you have this process in place and working, then you don't need to care as much about where the tasks are stored: SQL database or text file or Excel spreadsheet ... all can be made to work. Now, personally, I would argue that having a structured, human-readable and editable serialisation scheme, under version control and configuration management, usable for tasks, requirements and other items of engineering documentation will (does) make it easier to build the level of comprehensive scripting and automation that (I believe) is required for a truly disciplined engineering process.
_ZeD_ 11y ago
sigh, I miss the IDE days... you can say whatever you want about eclipse or svn, but... in those day I have a source tracker, a bug tracker, unit tests, a wiki internal doc all linked from eclipse; I got bug #ids, clicked on them, make my fix, test them, commit, etc... without miss the dots (in the commit message there was an autogenerated link to the bug, etc)
- w_t_payne 11y ago
  Yeah ... I'm sure all of this is available from Eclipse. But, like I said, its' an experiment for my own enjoyment and education. In a commercial environment, the best solution (by far) would be to use an off-the-shelf solution.
xena 11y ago
Do what I do and stick the markdown into yaml directly.

w_t_payne 11y ago

It also means that -- because my "tickets" and "requirements" documents are just bits of YAML with a particular structure -- I can store tickets, requirements and so on pretty much anywhere in the repository - either in their own directories, or interspersed with and embedded within the source code as comments -- sort of like a TODO but with super-powers.

madeofpalk 11y ago
> sort of like a TODO but with super-powers. Funnily enough our team just introduced an eslint warning (https://github.com/eslint/eslint/blob/master/docs/rules/no-warning-comments.md https://github.com/eslint/eslint/blob/master/docs/rules/no-w...) to discourage those TODO comments as we found they just always sat around forever collecting lint.
- falcolas 11y ago
  Similar here. If the todo survives the development branch, it should be moved into the ticketing system. Otherwise, you have two ticketing systems, one of which will be forgotten when it comes time to prioritize new development.
- w_t_payne 11y ago
  You are quite correct. It is always a bad sign if you have tasks that are captured but never actioned ... (Almost as bad as never capturing the problems in the first place) However, it is just as easy to have unloved, unwatched tasks festering in JIRA or Trac as it is to have TODOs festering in the source code. (I've seen both). The form in which the problem manifests itself isn't terribly important here ... or at least, its' less important than the solution. What is needed is a robust and active process to triage new issues; to action items that really are a problem, and to record the decision to discard problems which are not worth resolving. If you have this process in place and working, then you don't need to care as much about where the tasks are stored: SQL database or text file or Excel spreadsheet ... all can be made to work. Now, personally, I would argue that having a structured, human-readable and editable serialisation scheme, under version control and configuration management, usable for tasks, requirements and other items of engineering documentation will (does) make it easier to build the level of comprehensive scripting and automation that (I believe) is required for a truly disciplined engineering process.

_ZeD_ 11y ago

sigh, I miss the IDE days... you can say whatever you want about eclipse or svn, but... in those day I have a source tracker, a bug tracker, unit tests, a wiki internal doc all linked from eclipse; I got bug #ids, clicked on them, make my fix, test them, commit, etc... without miss the dots (in the commit message there was an autogenerated link to the bug, etc)

w_t_payne 11y ago
Yeah ... I'm sure all of this is available from Eclipse. But, like I said, its' an experiment for my own enjoyment and education. In a commercial environment, the best solution (by far) would be to use an off-the-shelf solution.

xena 11y ago

Do what I do and stick the markdown into yaml directly.