Hi,
With the upcoming migration to GitLab in mind, while reading some
books, using a kanban board locally, and with the idea to make the
contribution process smoother for both newcomers & long-timers, I've
thought quite a bit about how we use tickets to organize our
work recently.
My main conclusion so far is: I want to make it easier to determine
and set the status of a ticket.
Currently, the status of a Redmine ticket is built from the
combination of "Status" and "QA Check"; it does not help that some of
these combinations make no sense at all. I've noticed that many of us
have a hard time managing these 2 fields, regardless of how long
they've been contributing to Tails; so this data is very often wrong.
This, plus Redmine limitations, makes it impossible at the moment to
have an overview of a set of tickets, grouped by their actual status
(defined by a combination of "Status" and "QA Check").
So I propose that we drop the "QA Check" field and instead, introduce
a "Needs Validation" status. So a ticket would typically go through
this journey:
New → Confirmed → In Progress (once someone starts working on it)
→ Needs Validation (once it's deemed ready to be merged by the
person/team who's been working on it) → Fix committed → Resolved.
And if the reviewer requests changes, they would set the status
back to "In Progress".
The only thing we lose along the way is QA Check = "Info Needed" plus
the associated reassignment dance. Removing that has only benefits
IMO:
- This value is very often wrong because we forget to drop it and to
reassign back, after providing the requested info.
- Assigning a ticket to someone else + Info Needed, merely to get
some input regularly causes trouble: it makes the task invisible to
the person who's requesting the info, which makes it harder to
organize their work — occasionally I'll be surprised when a ticket
lands back on my plate after the info is provided. And if the
requested info is not provided in a timely manner, WIP can be
stalled for a long time, with no easy way for the requester to
notice and decide whether they should move on without that info.
Given we now have "mentions" (@nickname) on our Redmine, for the
majority of cases, when the requested info can presumably be provided
cheaply and quickly, I think we should use mentions and not reassign
the ticket. And when I'm mentioned, if I realize that providing the
requested info needs will take me great amounts of work, I should
do whatever works for me to track this work, be it on a new ticket
or my personal offline organization tools.
Thoughts?
I'll be happy to implement this proposal.
Cheers,
--
intrigeri
