DRAFT PAGE - STILL UNDER CONSTRUCTION - Christian
For most fields there is no further guideline needed, therefore just mentioning the ones here that require special handling:
The component should be set to the corresponding module, if possible. For each module, there is a default assignee, which should be used, if the issue is not created by the developer himself.
If there is a relation to an OCF Bugzilla entry, put the URL to the Bugzilla entry here.
← This change has been rejected. The Bugzilla ID shall go here. If a developer is interested in the corresponding Buggzilla bug, open Bugzilla and search for that ID.
If the ticket is assigned to a maintainer, it may be re-assigned to a developer. The developer should use “start progress” and “stop progress” to indicate when working on the ticket. If a developer sees that he can not handle the ticket at all, or for quite some time (vacation, …) it should be reassigned back to the maintainer of the module. A ticket should never be unassigned. An unassigned ticket has no owner.
Every month we will check for tickets that have not been updated for 3 month. The current ticket assignee will be requested to update the status of this ticket (in general this is either the developer working on the ticket, or the component lead). At this stage it may be elevated in priority. If a ticket is not updated for 6 month there needs to be a final decision if this should be either dealt with short term, or if it should be closed as 'withdrawn'. Again the component lead should take this decision.
Looks like the community feels that asking the current assignee about the ticket status via Jira is not sufficient. Instead there is a proposal to go through all of these tickets in a smaller group and triage the tickets. This would mean that we need to have a meeting/call at least once a month to go through these tickets. The tool that shall be used for this is still tbd. Proposal: Lets first implement the proposal above and check after a while if it is working or not. Introducing triage meetings includes some overhead to define a group for this, setup the meetings, decide on tools to use and finally it is difficult for this group to really check out every ticket as it requires from the group members an overall understanding of all tickets and the related code.
While working on a ticket, use “start progress” and “stop progress” When the work is done, use “resolve” Question: Who makes the transition from “resolved” to “closed”? Is this done by QA, the devloper, ….? Ideas here? There are right now 471 Tickets in resolved state in Jira!
Proposal: When commiting code to Gerrit, that is related to a Jira ticket, then provide a link to the ticket with the commit (ie: Using Bug: $url convention)