The dashboard is ready and I already did the “triage” for several issue tickets (feel free to challenge my classifications):
Also, I added my two “not major/minor related” tasks to “In progress” with the “Internal task” label, as an example.
I have created descriptions for all lists! If you keep your cursor on the list title, you will see a description that aims to explain what this is and what to do here (or what to do next). Maybe this helps a bit.
When externals create an MR, we have to manually create an issue ticket so that this MR ends up on the dashboard. Currently, no one seems to be responsible for external MR by default; there are already some: Merge requests · Fedora Docs · GitLab → are the external MR in that list already being processed by someone?
If we keep fostering external contributions (7-step HowTo and such), we have to consider that. We can assign labels to the MR, but MR will not be shown on the dashboard; only their issue tickets. (@darknao do you know any workaround for that?)
In short: We need not just to do the “triage” on the “open” tickets, but also on the “MR” list, whereas the latter also requires us to create an issue ticket.
If that makes sense, I have no problem with taking this responsibility for now (so, create a ticket for each external MR so that we have it on the dashboard). This task might be merged with doing Triage in general?
Do we really need to do that? I understand you want to see them on the board, but for what purpose?
MR should be about done work. Either someone just wanted to fix a typo or other minor changes, and in that case, it’s only a matter of approval to get it merged.
Or it’s about a more complicated change and may require some further discussion. It can be in the MR itself, in a meeting, over here, or in a dedicated issue.
That should be per MR basis only, and most of the time, I don’t think we really need it.
Yes! We need to triage both new tickets and review MR. And I think the best way to do that is in a dedicated meeting. That should not be the responsibility of a single person to take that role.
This can be a short meeting, like 30 minutes top, where we review new issues and take a first look at new MRs.
Pretty much what we did some times ago, but in a separate meeting instead of the weekly one.
As a new contributor, there is nothing more discouraging than seeing a MR sitting there for 3+ months with no feedback. We don’t need to merge them right away, but at least a +1 or any kind of feedback/comment is always a good start.
Unfortunately, I do not understand that comment What do you mean?
I thought it is the list where externals can pick tickets, and once a ticket has been assigned, the job of the label is fulfilled. But for me, both makes sense. I will delete the list and adjust the workflow page. So we keep such tickets in the “triage” with the additional label “good first issue”?
My argument was already based upon the workflow. So a ticket would be necessary only if it is a major change, or if a minor change MR requires additional MR (e.g., when different branches are affected) while the assignee does not want to do all these MR himself and at once. Especially for the latter, a ticket would not just enable asynchronous workflows (not bound to discussing in meetings) but also division of work.
I assume you mean that we should do the triage jointly in meetings, and also the allocation of MR. And the latter without tickets. Generally, we can do that and see how it develops.
But I see several issues with that, which already contributed to my decision to propose a workflow:
We should not take it for granted that people can always dedicate time. We already struggled to fulfill tasks in the past. Sometimes, people can dedicate time, but they do not know if and where they can support (I had that already several times): waiting for the next meeting is not efficient. And then, there will be maybe too much to discuss in the meeting, so that much cannot be tackled.
The meetings are already often overbooked. Often we have to shift topics to the next weeks, which increases the 1) issue. If we add weekly a discussion about determining what is major, what is minor change, what does maybe require additional MR in other branches, then we have two hour meetings, if not more when we achieve our goal of more external contributions. This also relates to the next issue:
Currently, external MR seem to be approved/merged arbitrarily. What is done? By whom? Is there a check if a change affects other branches? If something is only merged into “main” but also affects the currently supported releases (which is often the case), it might take up to one year until all supported release branches contain this change. I agree that a minor change should be just merged, and if the self-assigning member of us has the time, it is the same if a minor affects several branches: make all at once, and then it is done without any tickets. But as soon as the job cannot be done in the very moment (or if a member does not want to do all himself/herself), I thought a ticket is a good thing to ensure that a) a check is done to ensure that all affected branches get adjusted and b) no one needs to do the whole job alone while c) it does not take much time in the meetings. So the idea was instead of meetings, everyone just has a look on the dashboard once or twice a week, and then contributes to what he sees/knows/has experience with, which may also lead to cross-checks.
A slight addition about meetings: what did annoy me once in the past was a meeting, where I joined for a 2 or 3 minutes topic, while I had no experience with the remaining topics we discussed, so I couldn’t contribute much. The outcome is that I lost much time that I could have used to contribute somewhere else.
So, I think the question that we have now is: what to do with external MR if they are major, if they are minor, and if they are minor with several branches affected (and how to ensure that the latter question is tackled and it’s follow-up MRs don’t become forgotten). And of course how/where to do this triage. I will wait a bit before I make further changes so that we can discuss that.
Is this realistic? Especially if we achieve the goal of more contributions, and then also discussing triages for each ticket/MR?
Absolutely agreed. This is why I suggested to ensure that they don’t get lost, that division of work gets enabled, and that we can persistently keep working without waiting for meetings. But in either case, we have to check and ensure that all affected branches get adjusted: can we ensure that if everything keeps consolidated in the one original MR? This makes us again dependent on having a meeting for that, and that we always check each single MR which and where we have to discuss. An issue always contains automatically a list of all related MR on its top (just like that one).
However, I will think myself a bit about the issue, alternatives, etc. as now that I identified it, I am not satisfied by my own solutions either.
An alternative would be to encourage members to not only check the dashboard but also the MR requests. And label them just like the tickets. If an MR needs support or requires additional MR, a ticket can be created as soon as this occurs (even if not on the dashboard list, an MR can still be assigned the “approval needed” label). This would work as long as there will be not too much external MR. Also, it would avoid that we waste time for creating additional tickets where they are not necessary.