Fedora Docs Weekly triage

Project Discussion
1

On one hand, it seems the weekly meetings’ agendas are already full very often. On the other hand, scheduling additional meetings introduces all the disadvantages of synchronous workflows (we talked about that previously).

What do you think of doing a weekly triage here on discussion.fp? This should not contain any obligation for assigning each unassigned issue ticket / MR or to push something/someone. But I think it makes sense to have a weekly overview and find out (and document over time) if things remain unassigned and talk about why, or to identify if something is more urgent that something else.

Except adding the labels, the workflow starts after the assignment (so after the triage). Here, we can weekly focus for a moment on coordinating the triage and exchanging relevant information if necessary without becoming synchronous and without capturing the weekly meeting. It might be also added if something is in “support needed” or “approval needed” to make aware or to find out if no one is able to approve this specific issue/MR (for whatever reason).

Also, this gives people the possibility to check out comments and arguments about the tickets, which can be interrelated, and contain themselves relevant comments. So an additional meeting would maybe need several minutes until someone can answer anyway.

And this would document developments over time, adding information to the static boards: you see something in the triage and you are not sure if it is important, or why it is still there? Check out the last weekly triage and you will know!

So, what I suggest would be the following (just as an example):

Weekly triage 18. Aug

  • Issue dashboard: 6 tickets in triage
    → 2 major changes with multiple MR likely
    → 2 major changes without
    → 1 minor change with multiple MR likely (1 is a good first issue)
    → 1 Internal task (1 is a good first issue)

  • Open MR list: 3 MR in triage
    → 1 major change without
    → 2 minor changes with multiple MR likely

Addition:
→ As already elaborated here, I would consider install guide #11 more important than the other issue tickets
→ contributors guide !7 was approved. If this can be aligned with the ongoing work of @pboy , I would merge it already now and then we can introduce the new structure later. As this is not time critical, I would only do that if it does not increase the workload for pboy.

→ ! = MR
→ # = issue ticket

As already noted above, this is not to urge people to take on more assignments. It is just to have an overview what is going on, and what is not going on… and identify+document “why” in order to (asynchronously) facilitate an appropriate response by the individual members or the team as a whole :slight_smile:

If you want to try a “weekly triage” for some time to see if it is advantageous or not, I can do this for now.

2

My hunch is that triage is an activity better done synchronously. But I think your proposal is worth trying. My hunch is just a hunch: I have no data to suggest that it’s correct and would welcome being wrong on this point.

1 Like
3

Well, originally we agreed in the discussion to keep it completely asynchronously except the thorny ones, with members doing triage individually on themselves. However, in order to integrate the workflow into the team, it may be useful to facilitate discussions and coordination to achieve the above, and to lower the entry barrier for assigning: members can give each other security regarding the expectations, and can be reminded here and there to watch the boards regularly until it becomes a habit. And of course to reveal problems of the workflow if there are some.

Of course that’s a hunch, too :slight_smile:

2 Likes
4

Your suggestion (iteration of activity tracker in dashboard) helps things in check.
I’m halfway overcoming self-made barrier :slight_smile: I begin to understand collaborative workflow.

1 Like
5

I’m not sure I understand your point, but the workflow doc is already in staging if that helps: Files · stg · fedora / Fedora Docs / Community and Tools Documentation / Documentation Contributors Guide · GitLab

If anything is unclear in the doc, or if something in the workflow proves to be disadvantageous or cumbersome, we can revise both the doc or the workflow itself. Let’s see how far we get with what we have :slight_smile: