| | 1 | As mentioned in the call, when updating the issue tracker we should be consistent about re-assiging issues when we respond to them - this is the primary way that people can check what issues they need to respond to. A few notes: |
| | 2 | |
| | 3 | - The maintenance team will respond to all "new" (unassigned) issues, since they have to add their BSIL statuses and they are best placed to know if the issue is a duplicate (in which case inform and close) and check if the fields in the tracker are basically set correctly (eg make sure that priority is set realistically and something has not been set as critical or high when it should be low). The team will either accept the issue themselves or assign it to who they think might be appropriate (for example, back to the original reporter if further clarification is needed). See diagram: http://www.helios-foundation.org/issue-tracker/chrome/common/guide/basic-workflow.png. |
| | 4 | |
| | 5 | - We must also close ("resolve") issues to avoid having a distracting huge clutter of resolved issues showing up in the tracker. The process is that when a fix is made by maintenance team the issue is resolved to "in-testing" and it is up to the original reporter to finally declare that it is resolved fully once UAT has been confirmed passed. |
| | 6 | |
| | 7 | - Both of the of the above are set by the action block at the bottom of the issue page. |
| | 8 | |
| | 9 | - Correct assignment of issues allows filtering by owner - eg report 8 http://www.helios-foundation.org/issue-tracker/report/8 |
| | 10 | |
| | 11 | - We will look into making the set or reports more relevant for the project. in particular we should be using milestones to group issues... like we do in the QTS. |
| | 12 | |
| | 13 | - I have added permissions to all registered uses: In particular, editing the main description is now possible by al, so that this can be modified to reflect issue more closely if required. |
