No milestone No assignee A lonely feeling —-after Yosa Buson (1716-1784)
7.2.1. Triaging principles¶
The purpose of issue triage process is to make sure all the Invenio issues and tasks are well described, sorted out according to priorities into timely milestones, and that they have well assigned a responsible person to tackle them. The triage process is done collectively by the representatives of various Invenio distributed teams. The triage team members make sure of the big picture, cross-consider issues and tasks among interested services, help to note down, understand, prioritise, and follow-upon them.
- Every issue should have an assignee. Issues without assignees are sad and likely to remain so. Each issue should have a driving force behind it.
- Every issue should have a milestone. Issues without milestones are sad and likely to remain unaddressed.
- Use additional type and priority labels. Helps to find related issues out quickly.
- Use additional service labels. Helps to distinguish which issues are of utmost importance to which services. Helps to keep a service-oriented dashboard overview.
- Silent since a month? Ping responsible. An issue shouldn’t be opened without update for more than a month.
- Nobody in sight to work on this? Discuss and triage. The triage team should take action if there is no natural candidate to work on an issue.
- No time to realistically tackle this? Use “Someday” or close. We don’t want to have thousands of open issues. Issues from the someday open or closed pool can be revived later, should realistic manpower be found.
- No reply? Ping @inveniosoftware/triagers The triage team should take action if there is no update on an issues for more than a month.
7.2.2. Triaging team¶
Invenio triaging team consists of persons who manipulate issues, create labels, attribute assignments, follow up progress, and collaboratively decide on milestones for various Invenio projects on GitHub.
To enter a triaging team, the following conditions must be met:
- The person is an established Invenio scrum master or developer who knows well the wider project ecosystem. E.g. worked for more than N1 years on the project OR maintained more than N2 modules OR committed more than N3 lines of code to N4 different modules. (For respectably large values of N.)
- The person will use triaging rights for manipulating tickets only;
never for pushing code. Since GitHub ticket-manipulation rights
are indistinguishable from GitHub code-pushing rights, the persons
in the “Triagers” team should take extra care to avoid accidental
mishaps in this direction. (Such as doing
git push myorigin master -fand realising only afterwards that “oops myorigin was wrongly set so now I have accidentally replaced the whole Invenio canonical project commit history”.) The code pushing is being done by the “Integrators”, not by the “Triagers”.
- The person will endorse social contract related to participation in the collaborative consensual triaging and milestone decision-making process. The triaging team will represent various Invenio developer teams and services, participating together with the release management team on decisions related to the roadmap milestones and releases.
7.2.3. Triaging process¶
The process of triaging issues is being done continuously. This usually means that labels are being attached to issues, assignments are being decided, progress is being tracked, dependencies being clarified, questions being answered, etc.
The triaging team meets regularly (say once every 1-2 weeks) to go over the list of open issues for any catch-up, follow-up, and re-classification of issues with respect to milestones.
7.2.4. Issue labels¶
The issues are attributed namespaced labels indicating the following issue properties:
- t_bug: bug fix
- t_enhancement: new feature or improvement of existing feature
- p_blocker: highest priority, e.g. breaks home page
- p_critical: higher priority, e.g. test case broken
- p_major: normal priority, used for most tickets
- p_minor: less priority, less visible user impact
- p_trivial: lowest priority, cosmetics
- c_WebSearch: search component
- c_WebSubmit: submit component
- in_work: developer works on the topical branch
- in_review: reviewer works on reviewing the work done
- in_integration: integrator works on checking interplay with other services
- r_fixed: issue fixed
- r_invalid: issue is not valid
- r_wontfix: issue will not be dealt with for one reason or another
- r_duplicate: issue is a duplicate of another issue
- r_question: issue is actually a user question
- r_rfc: issue is actually an open RFC
- maint-x.y: issue applies to Invenio maint-x.y branch
- master: issue applies to Invenio master branch
- next: issue applies to Invenio next branch
- pu: issue applies to Invenio pu branch
- v0.99.1: issue was observed on version v0.99.1
- v1.1.3: issue was observed on version v1.1.3
The label types and values are coming from our Trac past and may be amended e.g. to take into account new component names in Invenio v2.0.
7.2.5. Milestones and releases¶
Issues may be attributed milestones that are closely related with feature-dependent and/or time-dependent release schedule of Invenio releases.
There are two kinds of milestones: “release-oriented” milestones (say v1.1.7) and “someday” milestones (say v1.1.x) for each given release series (v1.1 in this case). The release-oriented milestones may have dates attached to them; the someday milestone may not.
Typically, a new issue is given (a) the closest milestone in the given release series if its urgency is high, or (b) a later milestone in the given release series depending on the estimated amount of work and available resources, or is (c) left in the catch-all someday milestone out of which the issue can be later cherry-picked and moved to one of the concrete release-oriented milestones depending on available resources.
Example: after Invenio v1.4.0 is released, all incoming bug reports for this version will go to the “someday” milestone for this release series, i.e. to “v1.4.x”. A new XSS vulnerability issue will go straight to the next milestone “v1.4.1” because its release is urgent. A typo in an English output phrase in the basket module will remain in the someday milestone “v1.4.x” until it is picked for one of later releases, say v1.4.7, depending on available resources in the basket team.
The triaging team together with the release management team will periodically review issues in a given release series and decide upon the set of issues going into a concrete release-oriented milestone (say these 15 issues for v1.4.1 milestone) after which the issue set is freezed and a sprint may be co-organised to meet the target deadline. Once all the issues have been solved, a new Invenio bug-fix release v1.4.1 is published and the release-oriented triaging cycle starts anew with v1.4.2.
(Note that someday milestones are usually more useful for new feature releases; they might remain relatively empty for bug fix releases.)