Allow changing GitLab issues labels for all contributors

Possible options:
- Triage bot (eg: https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage) - this is only possible if inside an issue.
- Custom integration via custom commands (we are experimenting with this at the moment) - this is only possible if inside an issue.
- Reporter access to users (with clean-up) - this would allow issue edits and board drag and drop for example. Where do you request the access? Issue I guess too...

[edit: added some comments to each option]

Can we give all users the reporter role globally so that they can edit and change tags on all issues in all projects?

That would be the same behavior as we have on drupal issues right now.

- Triage bot (eg: https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage) - this is only possible if inside an issue.

The triage bot is good at reacting to issues in a certain state, and runs on cron. GitLab.com/gitlab-org has their triage bot rigged up to react to webhooks, so actions are near-instantaneous. Our Drupal integration already handles reacting to webhooks and custom slash commands, so it will be more maintainable.

Regardless, the usual drawbacks of custom slash commands apply. There is no interface other than knowing the right thing to type, it is very much a power-user feature.

- Reporter access to users (with clean-up) - this would allow issue edits and board drag and drop for example. Where do you request the access? Issue I guess too...

#3262293: Grant GitLab “reporter” access to project maintainers with “edit project” or “maintain issues” has some expansion of this role, not any sort of requesting system, other than each project adding maintainers.

Can we give all users the reporter role globally so that they can edit and change tags on all issues in all projects?

We tried this for issue forks, and it went badly. Some part of the GitLab internals created internal queue items at an overwhelming rate as we added people. I don’t expect that GitLab to improve scalability here, as it is a legitimately unusual use case for them.

The way GitLab.com/gitlab-org handles this is a separate site that contributors to manage labels and do other actions, https://contributors.gitlab.com. We have some capability to build the parts we need in Drupal, like we have needed for credit & forks.

We tried this for issue forks, and it went badly. Some part of the GitLab internals created internal queue items at an overwhelming rate as we added people.

Could we do this for people who've posted on a gitlab issue though maybe? e.g. you post once without the ability to change labels, but once you've done that, you can.

That logic (#6) would be doable as we already have the webhooks.
We could add "reporter" role to the repo with a X-month expiration date. I'll let @drumm weigh in on this as there may be some drawbacks.

We could add "reporter" role to the repo with a X-month expiration date.

See my comments in https://www.drupal.org/project/infrastructure/issues/3254602#comment-154...

TLDR: Security concerns related to giving any random person reporter status.

Allow some labels to be settable by anyone: https://gitlab.com/gitlab-org/gitlab/-/work_items/15384

No activity in a few years though

Reposting a comment I made in a thread from the AI initiative team as they start to get used to what this transition means.

Excerpt summarizes multiple issues that could be addressed by the reporter role grant, not just the issue label one in the summary here

...
Permissions work per vanilla GitLab, so the role restrictions are what they are.

https://docs.gitlab.com/user/permissions/#project-permissions

Some examples of known issues:

• Labels require the reporter role at least, there are some proposed ideas for this.
• Assignment is the same, needs reporter or higher
• Assigning a reviewer requires Developer role or higher.
• Only the author, assignee, reporter role or higher can edit the issue description.
• For migration reasons, to preserve the issue node ids and all their associated references and cross linking, the migrated issues are authored by drupalbot, but new isues will be authored by the user who created them.

Most of these could be resolved with a solution to add the reporter role.
...

#6 and #7 do seem promising if we can carefully review concerns raised in #8

The reporter role grant would be less 'hacky' than:

• Custom slash commands/triage bot style solutions
• Custom UI on the contrib record/fork management page, although since we're already doing this to some degree it isn't too much extra tech debt, maybe.

The fact that GitLab themselves can't convince their product leads of the importance of these features and has to make their own separate UI does not encourage me that we can expect a fix coming from them.

So my preference on next steps would be:

• Let people work with a bit more, and get used to it a bit. Change is hard.
• Do a more detailed risk analysis of reporter role granting, decide if we're comfortable with that surface area (if it doesnt open more defacement than our current 'open' issue queue on d.o it may be fine)
• Otherwise, do a bit of an internal regroup on bot+slash commands and/or UI on the fork management and contrib record.

A TLDR; summary of #8

1. First, and perhaps most difficult to resolve - granting reporter in any automated way potentially risks exposing confidential issues. (But does it? We should validate/test this...)
2. Second, wide access to the reporter role risks pollution or even defacement of project labels, which would cascade to issue boards and such.

IMO, the label editing concern is not so much more risky than what d.o issues are like today. We have many duplicate/slightly mispelled/poorly defined labels being created, but we are able to collectively manage the hygiene of this. It's true that people can't arbitrarily change existing labels on D.O, but overall I'd consider this a non-blocker/lesser evil of granting reporter.

However, it looks like the first concern is very legitimate, if this Claude AI summary is accurate...

Regarding confidential issues, Reporter role can:

• View and access confidential issues in the project (Guests cannot, unless they authored or are assigned to them)
• Create confidential issues
• Convert existing issues to confidential (though as of GitLab 17.7, this minimum was raised to Planner)
• See confidential issues in search results, boards, and lists (hidden from users without sufficient permissions)

The practical implication for the concern you quoted: once an issue is marked confidential, anyone with Reporter or higher can see it.

This can be confirmed: https://docs.gitlab.com/user/project/issues/confidential_issues/#who-can...

The 'Guest' role would be safe, but doesn't have most of the permissions we want.

Sigh.

I think that means we are back to triage bot+slash commands and/or UI built into the fork management/contrib record page.

At least for anything that is a true workflow blocker, and not just a matter of getting used to the norms in GitLab..

I think it'd be cruel to expect maintainers to follow every issue and track the status. Maybe it's 20+ years of practice, but if we can't "crowdsource" the changing of the status as an issue progresses through its lifecycle, and only expect maintainers/committers to see stuff once it reaches "RTBC", we're in big trouble. It'd be clunky and weird to change the issue meta data at the contribution record page, but if that's the only viable option, so be it. triage bot + slash commands sounds more "inline" with how we do stuff now -- add a comment at the issue when you've addressed feedback and set it back to "Needs review", or add a review, point out problems, and add a comment to set to "Needs work", etc. So something like /status Needs work and if I put that on a comment, some bot will notice and change the label if I don't have an elevated role in the project...

Priority I care less about. If only maintainers can change that, so be it. 😉 Folks can comment they think it should be changed, but a maintainer/developer/reporter can actually make the change if agreed. Same for Category, Component, etc.

But status seems like an absolute deal-breaker to me.

Meanwhile, I don't know if moving issues between projects is at all even possible in GitLab. I think we probably have to give up on that workflow entirely, right? If something is "mis-filed" to the wrong project, someone has to copy/paste the relevant bits and start over in a new issue, correct? So if some deprecated module moves out of core, we just "close outdated" all the issues and folks have to start fresh with new issues in the contrib project, huh? Maybe this should be spun off into another issue? The project isn't really a "label" in the GitLab sense, it's a more fundamental property of the issue...

Re: #11: Related (but sort of off topic for this issue), does that mean that all of us the core subsystem maintainers (who are either developer or reporter) are going to be able to view all confidential security issues submitted for core? Seems like it. That's not currently how access to sec.d.o works. I'm generally only added to security issues for "my" parts of core. I don't *think* anyone would mind if subsystem maintainers can see all core sec issues. But if that is or becomes true, it's something we need to be more explicit about in the rules / responsibilities for subsystem maintainers ("and I solemnly swear to keep all confidential security issues strictly confidential", etc).

The reporter role fixes most of the issues reported above. Maybe we don't need to grant reported role to everyone, but only to certain trusted people within the projects (similar to the "sub system maintainer" role, which only have a subset of responsibilities). 99% of contrib projects will be fine with this, and maybe this is a new role that core could adopt and grant some users ("trusted reporter" or however you want to call it). Anyway, this was just thinking out loud.

Doing integrations and listening to commands is easy. We are already doing it for some commands as a trial. However, we first want to identify the real needs. For example: changing labels - do we need changing all labels or do we just need "rtbc" so maintainers see this?

Re #15: I don't think even the subsystem maintainer community should be expected to track every issue in the core queue to make sure the status is always accurate. I think "everyone" needs to be able to change the status. Sounds like Reporter is going to subvert the point of confidential issues, which would be bad. So we need a safe way for any "guest" to be able to at least change the status label.

ps. Also re: #15: I don't want to have to be the only one to track the status of all issues in all my contrib projects, either. 😅 I'm not sure "99% of contrib projects will be fine with this" is accurate, either. 😉 I strongly vote for a generalized solution, across the entire ecosystem, that allows "anyone" to at least toggle the Status label among the per-project defined values.

1% of Drupal contrib projects is nearly 400 projects 😅. I don't have the exact numbers handy, but when checking the number of issues per project before the migration, +36K projects have less than 100 issues in total. Most of those have very few maintainers that "own" very few projects. That's what I meant by that 99%. The 1% of Drupal projects that don't fall in this category are probably really important to the ecosystem and we need to provide the right tools/workflow so contribution continues to be easy (or even is accelerated!), but again, even if available, it might not be needed for many other contrib projects.

In any case, what I mean is that we need to identify the real needs here (whether it's RTBC label, or status, or whatever comes out of trying for real the new issues and the workflow and the implications). This is why we have the opt-in phase. Modules that opted in knew that we are in early days and their feedback is critical.

We can build custom commands or add bots, etc. None of them will be as "neat" as the default GitLab experience, which offers autocomplete suggestions. Maybe some needs are worth trying to contribute upstream, maybe some need to be custom, but let's find out what exactly first.

Re labels, and coming back to comment #2 here, to stay focused on the issue.

Fixing upstream in Allow some labels to be settable by anyone would be the best place.

But if that doesn't happen
1. Triage bot, still an option?
2. Custom integration - we could do (no autocomplete):

/do:add-labels list,of,labels 
/do:remove-labels list,of.labels
/do:set-labels list,of,labels (reset labels to these)

3. Reporter access seems to have security implications, so probably worth looking at in a different issue

Doing 2 is not a huge effort, but we'll need to document it and we need to know that there is no autocomplete for the command nor the labels, so users will need to know that it's there.

If this is agreed/accepted, it's something that I could work on.

We were talking "Reporter" a lot, but what about "Planner"?
https://docs.gitlab.com/user/permissions/#default-roles

#3586372: Allow security team members to make the issue confidential to track information re confidential issues.

We'll continue the focus on labels on this issue.

This would be amazing if the community could update labels. This is our biggest pain point at the moment. Thanks everyone!

I would say we should move forward on option 2 above, @fjgarln.

Although (and I know its more work) I think adding a manage labels tab to the contrib record that uses js to pull in the current label list and allow changing from there would be a lot less prone to errors/multiple redundant comments as people try to use the slash commands.

Posting my suggestion here as well, drupalbot (or something like it) could manage removing labels like state:: when an issue is closed after 2 weeks of inactivity.

Needing to remember to remove or change state labels when resolving an issue is going to be difficult for people (like me).

Re #26 - I can start working on it. I can start with the commands and start also thinking about the UI. Rather than adding to existing screens I'd rather have tabs. So instead of adding to the contribution record screen (fully managed by a separate module) or the fork management, we could have a "Issue metadata" tab, independent from the others but accessible via the top tabs.

I'd like to have @drumm's thoughts on this too, regarding the commands in #21 and possible UI, in case he has some suggestions.

--

Re #27 - Many projects might not choose to continue using the "state::" labels and use the status fields provided by GitLab.

Re #27 - Many projects might not choose to continue using the "state::" labels and use the status fields provided by GitLab.

I thought the (newish) Status fields weren’t going to be used at first? Or are we going to change to that?

Regardless anything that would help automate removing labels that need to be removed from the standard work flow would be great.

I do not think we want to encourage people to deviate from a standard work flow as that will increase the burden for learning contribution for new folk if every project is encouraged to do their own thing.

The idea is that each maintainer will choose what they want to use. Contrib projects have very different needs depending on the volume of issues, number of contributors, etc.

We want to try what the flow with "standard" GitLab issues feels like, what are the needs/problems/issues, etc, before starting to change and add customizations to our GitLab integration.

Again, let's try to keep the focus of this issue purely on label management (via UI or custom commands). For other issues feel free to comment on slack or open a new issue, otherwise it's difficult to keep track of things.

Again, let's try to keep the focus of this issue purely on label management (via UI or custom commands).

Sorry, I thought that’s what I was doing by suggesting that drupalbot could be used to manage labels based on work flows per #21 above.

No worries. We'll work on the basics first and then see if that covers the needs. If we need to iterate or even work on new integrations they can be follow ups. I'll try to get the MVP version of this in this issue.

Moving to Drupal.org customizations where the implementation for issue management UI on new.drupal.org and site-wide slash commands will land.

For a UI, we’ll have to think through what else to add for tracking. The basics will be someone adds the label via new.drupal.org, then the issue will be updated with

drupalbot added … label

We’ll want to know who did that, so there will also need to be a note before or after that explaining who did something. We can post that note as either drupalbot, or as the person taking the action. Posting as the person taking the action would probably be best, so crediting is easier. Like any other comment posted by someone in GitLab, they would have edit access to it after posting.