While working on the new workflow, we revealed issues in Implementing the new Docs workflow organization - Fedora Discussion
→ Merge Requests can be labeled and assigned, just like issues. But they cannot be added to the dashboard. This becomes an issue especially for external, or casual, contributors and their proposed MR.
→ some MR need follow-up commits or MR (if multiple branches are affected)
→ The triage has to be done in some way
In the above mentioned thread there is already some elaboration of the issue by me and @darknao
I agree with @darknao that it might cause unnecessary work to create a separated issue ticket for each MR, and that it can be questioned if this institution will survive on the long term. The current workflow would NOT include an issue ticket if an MR is directly processed by an assignee (including checking if it applies to multiple branches and then adjusting all affected branches at once). In other cases, it would include an issue ticket.
Additionally, there is the possibility of unprocessed MR (I think there were several in the past pagure repos), which indicates that we need to use the available time of members more efficient, and that we have to ensure an organization that does not forget these MR.
Also, it has to be ensured that MR are checked if they apply to multiple repos. E.g., many changes that are merged towards “main” should be also done in the current release branches (so F35 and F36 at the moment).
So, we have now three interrelated questions that might be discussed to then maybe find a consensus in the meeting:
- How to handle MR in the organization?
My proposal, which is a bit a compromise between my original approach and the suggestions of @darknao is:
→ expect from the members to check not only the dashboard but both the dashboard and the MR list once or twice per week. At the best, once before the weekly meeting.
→ we can use the same labels in the MR list. If you open the MR list, you can see immediately the labels of each MR. So you would see it if one is labeled “support needed” or “approval needed”.
As long as the number of MR is limited, this should work and is possibly more efficient than creating additional tickets.
If a member takes over an MR that merges into “main” and then does two additional commits to, e.g., F35 and F36 because it is a minor change that affects three branches, everything is fine anyway.
But if it is a major change that requires more than one MR, my suggestion remains to create an additional issue ticket because the ticket collects all related MR on its top (see an example here). This summary of related MR is initiated just by mentioning the ticket name in the MR or vice versa. This approach would also tackle the next question:
-
How to ensure that each MR is checked for applicable branches?
There are many proposed changes that require updates of multiple branches (e.g., main, F35, F36). The above approach is able to manage that, too.
→ does it make sense to add an additional label here? Something like “multiple MR likely” or such. This could be added during the triage in conjunction with the major/minor label. A dedicated ticket makes here sense because the MR will disappear once it has been merged (creating the risk of forgetting about follow-up MRs/commits). However, that ticket could be created once it is for sure that multiple MR are necessary, not automatically in the beginning. -
How to do Triage? In meetings? Or asynchronously on the dashboard/MR list?
The workflow does not yet consider how we do triage. Indeed, my original idea was to become more independent of meetings: expect each member to check the dashboard (and the MR list), and if a member has some time to contribute, label what has to be labeled (if you know about the topic), and check what has already been labeled by someone else (so check what is already in the “triage” category to have a review of triage decisions). Then, if something needs approval or support, take over. If there is something already in triage which you could do, assign yourself.
My reason to suggest reducing dependency on meetings is:
→ the members lose time, in which they could contribute by processing an MR or so: e.g., the member is involved in 2 topics that are tackled in a meeting for 10 minutes, whereas the remaining 50 minutes tackle topics he/she is not involved in and thus, cannot contribute to (just an “extreme” example for illustration of my point).
→ the Docs lose time: besides the above, members have often to wait for the next meeting to find out if and where they can support/contribute (“unused contribution time” cannot be accumulated).
→ a meeting has to be scheduled: contributing for about 1 hour a week is easier than fixing in advance exactly when I have to contribute this 1 hour.
→ a triage would take much time if done in additional meetings, and the amount of time will increase with increasing contribution (much to schedule). It would take less time if the meetings are only to review the board/MR list and check what is going on and what remains unassigned but has to be done. The latter could be integrated into the weekly meeting.
→ more comprehensible documentation of activities, tasks, events.
The disadvantages of my approach, which would be mitigated by meetings:
→ my approach expects some “discipline” from members. It assumes that they regularly check the dashboard + MR list. We can see if the labeling gets done, but we cannot see if there is a well review of the labeling.
→ it should not be underestimated that it is not so easy to get used to such a new approach (labeling, document, etc.), and also to stay used to it → it has to prove competitive and to remain encouraged in the meetings and by the board.
→ the meetings are better in immediately responding to unforeseen developments/issues.
→ meetings might be better for team building
→ my approach feels very formal
Concerning new members:
Some potential new members might be encouraged by the boards where they can see in advance what they would be up against if they join the team (cognitive dissonance about what someone is up against can be very deterring), others would be encouraged by the meetings which enable them to participate without elaborating much in advance. I think this is balanced among the approaches and not really an argument for or against any of them.
Feel free to discuss. I have not yet added one of the approaches to the draft.