Trello Communication
Specification title
Overview |
|
Title |
Trello Board Communication |
Blueprint |
|
Assignee |
Specification assignees |
Release |
|
Detailed specification
The detailed specification should go here.
Areas covered in the specification should be the following (where applicable):
Summary: The team should use a method to enable more detailed communication of issues arising
Rationale: At various points during the T Cycle - it took longer to find out the status of an 'issue' than to actually do anything with regard to the 'issue' A case in point, during the last weeks of the cycle brainwash, ochosi and elfy were looking at the suspend with lid-close bug - more time was spent catching up on what had been done - and then redoing tests than was necessary. Blueprints work for general statements of fact but are no real use for detail.
Use cases: Lists within the board itself can be setup for QA, Docs, Development and any others of use. A Single Done board would suffice for all Done items. This is in addition to the current blueprint system.
Detailed application comparison Currently we ask people what the status is - if they are about, or hope that someone else is aware, or guess, or wait. Looking at a board to check status would be a more efficient use of our time.
Notes on design, implementation and maintenance work Board would need initial setup once a cycle, members of '-team' would need a trello account to access it.
Discussion on the specification
Current QA listing
Back of autopilot card