Re: How to keep our backlog healthier and improve the WIP visibility

[Alberto Fanjul Alonso <albfan gnome org>]

Take this as a constructive disagreement. If mailing list works for Buildstream I can live with it. Maybe with time I could find why it is better.

I see lot of implementations starting from blurry ideas on issue trackers, where you can discuss, attach MR to support your thoughts, link other issues, add images, screencasts, get partial reviews, pass CI. Plain text emails (where someone answer in the middle of previous response) is a sustainable way to discuss ideas? 

Personally I'm not scared about having issues open for years, that didn't mean anything, but help people to relay on issue tracker about status of a feature, like: I though about this feature, let's see if someone has the same idea, or if there's any WIP branch with some explanations with problems with it.

As we use communication channels like IRC with bots linked to issue trackers, that's another reason to agreed with issue tracker as core channel for discussion.

In general, the pace for IRC/bots vs mailing list is slower in several orders of magnitude, maybe that's better for important features, I experimented that on GNOME mailing list about bridge our IRC gimpnet to matrix.org. the post had lot of traction and responses, but can see why discuss on an issue tracker would be less effective (apart from people use to discuss on mail list).

The main idea is that issue tracker is and always will be, a chaos. The concept of icelog (before backlog) can be useful, as the automated closing of issues without updates for X time.

El dom., 24 jun. 2018 17:49, Agustín Benito Bethencourt via Buildstream-list <buildstream-list gnome org> escribió:

Dear BuildStream colleagues,

Each ticket has associated to it a significant amount of effort when measured
over a period of time. As the project grows, more and more tickets become
zombie in our ticketing system for a variety of reasons. Zombie or idle
tickets increases the management overhead, reduces WIP visibility and backlog
cleanness.

Please consider the following tips before opening a new ticket in order to
reduce the risk of zombie tickets:

   * Be sure there is a clear description of the problem or proposed actions
when opening a new ticket. Add all the relevant information. Tickets are not
for "suggestions", "inmature ideas", future considerations or similar. They
should provide as much certainty as possible. Rely on the templates. Take them
seriously.

   * Use the mailing list to shape the idea, to suggest something, to tackle
an issue or to get feedback. Then, only when you are sure about what you
intend, when the action is clear and can be described in a few lines or bullet
points, when the bug is confirmed... open a ticket.

Once you have opened a ticket, please be aware of the following:

   * If you are the creator of a ticket, please make sure you follow up on it,
specially when your colleagues add comments to it.

   * If there is no answer to your ticket in some time, use the mailing list
to highlight its relevance when appropriate. Do not let it idle on the
ticketing system for weeks. Ping the person you are expecting to answer. We
might have overlooked it or have forgotten to answer to it. Do it kindly
though. Remember that people might be busy with other activities.

   * If in the course of the discussion, the original description of the
ticket is no longer valid, please modify it so it is always up to date.
Remember that Gitlab keeps history of your changes. It is very important to
have an up to date description.

   * If the ticket description requires a radical change as outcome of the
discussion, please consider closing the ticket, opening a new one and relate
both of them. By doing this you prevent people from going through all the
comments only to understand what is the ticket really about.. If you create a
ticket, you own it. Please keep them in shape. Your colleagues time is as
important as yours.

These enhancements will reduce not just the number of zombie tickets but also
the amount of management effort required in keeping the WIP clean and a
healthy backlog. At the same time, we will benefit from more and better
discussions on the mailing list about topics that end up in actions items,
increasing alignment.

In summary, please consider to use the mailing list before opening a ticket.
Remember that Google is better at searching than Gitlab, specially if we copy
the mailman archive into some web tool.

I will add these advice to the policy as Good Practices if you have no
objection.

Best Regards
--
Agustín Benito Bethencourt
Principal Consultant
Codethink Ltd
We respect your privacy.   See https://www.codethink.co.uk/privacy.html
_______________________________________________
Buildstream-list mailing list
Buildstream-list gnome org
https://mail.gnome.org/mailman/listinfo/buildstream-list