6 ms·

It also means that -- because my "tickets" and "requirements" documents are just bits of YAML with a particular structure -- I can store tickets, requirements a

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.

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.