I partially suggested in light of the concerns I heard on IRC and how the
Katello plugin has dealt with similar issues by having a weekly triage.
We've been doing this for quite a while and I think it works quite well to
address every issue. What follows is a run down of how we manage that
process. I'll start with some background information that will help the
process explanation make more sense. The Pulp team runs a community triage
via IRC using a bot to help out which is another avenue that could be
pursued.
If any of the Katello triage runners see something I missed or mis-quote
here please correct me. Also, as I finished writing this I realized I
should transfer this to our official docs.
Triage Runner
We have a few standing developers that switch off running triage. Typically
it is myself or Justin but we try to get the current release owner to jump
in and run it as well as encouraging others to take it on. Takes one or two
to get the hang of it, but it is a good experience.
Frequency
Triage is done once a week for an hour. As long as a week is not skipped,
this has been enough time to get through every issue and leave 5-15 minutes
extra. When a release is pending, or a new release has been sent out the
volume does spike.
Issue States
There are a few important states that issues can be in that are worth
knowing about before going into the process:
- New: Unassigned issue
- Assigned: Developer has taken responsibility
- Needs more information: User who filed the issue has been asked for
further information to help triage or debug the issue
- Needs design: The issue requires investigation by a developer
- Ready for Testing: An issue has an open PR
- Closed: An issue has been fixed
Release States
There are a few important states the issue can be in with respect to the
'Release' field within Redmine. These release states have an impact not
only a release itself but the triage process as a whole. A quick definition
of each that will make more sense in the process section:
- Empty: No release has been set, this is the "untriaged" bucket
- Katello Backlog: Issues that have been put on the backlog and not
scheduled for a release due to any number of reasons
- Katello Recycle Bin: Issues that have been rejected, or are a
duplicate, or have been in 'Needs more information' for longer than a week
- Katello X.Y.Z: Standard releases for issues to be targeted at
Process
The triage runner starts the meeting by going through sets of issues broken
down into different groups by priority of the grouping. This is so that if
time were to run out, the most critical categories of issues are triaged.
This list (with easy links for the runner) are at [1]. The runner is in
charge of ensuring the flow of the meeting, and updating issues or ensuring
that someone on the call takes responsibility for updating an issue. This
latter part sometimes occurs if a duplicate needs to be looked up, or
another developer on the call can explain/ask the user for more information
more clearly than the runner.
Recycle Bin
The first on the list is our 'recycle bin'. This the place to put issues
that don't fit into a release, or were filed by a user who has since gone
dark on the issue. Another way to look at it is a place for unresolvable
issues. Issues are moved onto the recycle bin if there has been no activity
by a user for a week. And they are closed if a week on the recycle bin goes
by without any further updates.
General Flow for New or Needs More Information
The general flow is to open an issue and the runner to exam the issue,
typically reading the general idea outloud. This allows for any developers
with knowledge to chime in with any relevant info. The runner attempts to
answers the following questions:
- Does this issue need more information from the user?
- If yes, leave a comment asking for that information
- Does this issue need a developer to investigate it further to properly
triage it?
- What release should the issue be targeted for? (e.g. next z-stream,
current release, next release, backlog)
- Does any developer want to own it?
- Issue category?
General Flow for Ready for Testing
- Will this PR get completed by the next release?
- What release should the issue be targeted for? (e.g. next z-stream,
current release, next release, backlog)
General Flow for Closed
- Should this issue be targeted at the next z-stream? Current RC phase?
Or just throw it in the "next" release (aka develop or master)
Notes
A few notes about some automatic operations that are performed by the
prprocessor that help facilitate this workflow.
- All issues are set to an empty release, which again represents
"untriaged"
- Any issues on the backlog that a PR is opened for has its release set
to 'empty' to ensure that it flows through the triage process
- Developers that believe an issue should be considered for a release,
should set the release to 'empty' and show up to triage to argue their case
[1] Foreman :: Plugin Manuals
···
On Wed, Nov 8, 2017 at 10:28 AM, Greg Sutcliffe wrote:
So on IRC the idea of a regular issue triage for core issues in redmine
came up, and I think it’s a pretty good idea.
I think we’d want to do this on a public stream (but recorded, I think),
and then anyone interested can join. We’d need a minimum number of
people involved to make it work, I guess we’re looking at anyone with
commit / interest in foreman core itself. Proxy, plugins (and possibly
the installer) are out of scope, at least to start with.
Is anyone interested in participating in this? When should we hold it?
I’m guessing around lunch-time GMT if we want maximum coverage, or we
could alternate EMEA-friendly/US-East-friendly time slots? Avoid
Thursday if you can as demos and other recorded content tend to happen
then 
Greg
–
You received this message because you are subscribed to the Google Groups
“foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
Eric D. Helms
Red Hat Engineering
