ToDo flows

From JazzTeamWiki
Jump to: navigation, search
Language: English  • русский

TODO

  1. very often mark small, rather "stupid" pieces of code. Could be adjusted without discussion. So implement and remove todo.
  2. Some kind of architectural decisions/discussions should be done as a certain TODO is not trivial. This could be done in the following way:
    1. discussion just with person introducing this TODO or with your architecter/team leader
    2. putting all necessary info to forum, and discuss there
  3. TODO could appear during code review process. When making code review people agree on date when all should be fixed. So some TODO activities could be handled as tasks.