PD: The email is long, but I hope it clarifies how I work about the GitLab stuff to anyone that might be in doubt about the evaluation process and how I set priorities to issues that impact GNOME.
> Hmm, applying the same logic you can open a GNOME's gitlab issue for
"tips of the week" and update it, instead of sending the message here,
because you are addressing the same group of people, no? :)
How...do you think I track them? :) [spoiler]
https://gitlab.gnome.org/Infrastructure/GitLab/issues/101 [/spoiler]
> But seriously, my main point is that not every developer follows issues
filled in GNOME infrastructure gitlab issue tracker, thus even it's a
public place, it doesn't reach the group of people whose the decision
will influence the most.
So what do you propose? We are precisely doing this right now... discussing an issue you consider important.
Don't you think doing something else will add even more noise to the already noisy GitLab topic that we can barely achieve people to get engaged and involved with? Don't you see that what I'm trying to do with all this stuff is to make sure noise is low and focus that people participate in the real important topics?
I believe you are proposing just what we already do, the 'question of the week' is intended to give focus onto a single issue per week, so at least I can tell the community 'look, this is important and impacts all of us in a higher level, please participate, I promise I'll keep request for feedback low'.
Regarding individual items as priorities, as I mentioned I evaluate the big picture and the feedback from everyone, if you don't follow all the issues and feedback about this stuff that's fine, that's why I do it to take everything into account to create that list... if you are particularly interested into one, feel free to send an email this mailing list and say "what you all think to make this higher priority?" If you get people interested, and after explaining the big picture for that particular one you all agree this deserves higher priority, I will just increase it, I don't have any personal preference or interest while doing these GitLab tasks.
If this didn't happen much until now, it's because I believe people here are happy with how this is being handled and the priorities given to each issue, always keeping in mind these evaluations are done with a GNOME wide mindset, not with an individual mindset, and also keeping in mind that we should avoid making it a voting contest, as
our folks at Mozilla can tell too when they were evaluating the switch to Phabricator.
> It also surprised me that the fresh "Allow to disable group mentions -
#43686" is considered Minor. It's not a deal breaker, of course, but it
has some consequences too.
Ok I'll explain my process of evaluation for priorities. Usually I do:
- Evaluate the context: how the issue was done, what frequency, how many projects, how important are the projects and how many people it affects...
- Evaluate the consequences: What a developer would feel and for how long, for how many times this affects their performance, how much it affects their performance, how much it impacts the willing to use the tool, if the issue was present before in BZ...
- Evaluate solutions: how much the solution impacts people affected, how fast can the admins be to apply the solution, how effective is it.
- Evaluate if an upstream solution is possible and if it fits upstream vision: There is no point to propose to GitLab to do something completely against their vision, so I need to eavluate this and scope the issues as much as possible. This is all our meetings with them, discussions how we can make fit both GNOME needs and GitLab needs, and if there is some possible trade off, then it's viable to add it to the list.
Now, let's go to your issue #43686:
- How many people does it affect? It affects all GNOME. This makes it to the list directly, there is no doubt.
- Now, how frequent is it? Well, once per two months.
- What are the consequences? Developers get an email, get angry for 2 minutes
- What are the solutions? Admins go and stop the thing locking the issue and everyone moves on.
- How the dev performance was impacted? It might be a lot, but it's only for two minutes. It doesn't prevent you to work further or to stop using the tool.
- Is it a big impact in the whole GNOME that affects their workflow in a considerate way? I don't think so.
- Evaluate if an upstream solution is possible and if it fits upstream vision: Yes, they
disabled @all recently for non-project members.
Now let's evaluate the issue just a bit above this one, an "internal error when editing a issue description with task list":
- How many people does it affect? Potentially everyone, but in reality one/two people per week.
- What are the consequences? Developer cannot longer edit an issue or put a task as completed. This could block the developer into working on something for hours. Could forgot about what needed to be done once it's fixed.
- What are the solutions? Admins check the issue and mark it as non-spam
- How the dev performance was impacted? Blocking work on that issue, if repeated, potentially be reason to be annoyed enough to stop
using the tool, since the tool is going against their willing. PD: that's
why we disabled Akismet in the past, we got requests and feedback about
this.
- Is it a big impact in the whole GNOME that affects their workflow in a considerate way? Up to some point, taking into account all, it's "minor" but more than being pinged once every two months.
- Does it fit upstream vision?: Yes, it's just a bug in their spam protection.
Now here it's missing the big picture, which is certainly not easy to write it down. Also, keep in mind that the more items we add to the list, and the more higher priority we make them, the more diluted our leverage is to make them actually happen.
Hope this was useful and clarified any doubt you might have, it certainly took some time to write.
> By the way, how does that
https://gitlab.com/gitlab-org/gitlab-ce/issues/43566 work? Once the
"High" section is done all left GNOME projects will be migrated to
GNOME's gitlab instance and bugzilla will be switched to read-only
mode, or?
The plan is to migrate already, our blockers were fixed in the past already. And yeah, after mass migration BZ will be put into read-only mode.
Best,
