Using GitLab labels for issues on Drupal projects

According to the recent Slack discussion adding a note that we probably would need to setup a Gitlab bot to allow making changes to status labels by contributors (similar to what is possible now). Otherwise only maintainers + developers would be able to to that and it could create a lot of work for something contributors used to do. Maybe we will need a follow-up issue for this?

@poker10, how do you envision interaction between contributors and bot?

Seems like there is already an issue for this: #3317273: Set up a Drupal.org GitLab issues bot →

I think that contributors should be able to do most of changes they are allowed to do on Drupal.org currently. This includes changing labels, etc. Unless of course we want to completely change the workflow for contributors and add more work for people with extra permissions, which I think we probably don't (but it is my personal opinion).

So something like we @mention a bot in the comment with some labels and bot will add these to the issue. And so on. Currently I do not have full picture what else could be needed (especially for core), but I think this will be discussed further in the referenced issue.

We have #3317273: Set up a Drupal.org GitLab issues bot → , that bot will really just be www.drupal.org making posts. Hopefully we can find something more off-the-shelf for community label updates. https://gitlab.com/gitlab-org/ruby/gems/gitlab-triage may be what GitLab.com uses for this.

The problem was really that GitLab didn't scale at all when adding many users to a project. If this wouldn't be an issue then the feature would be built-in. We could set the "reporter" role at group level (ie: "project"), users will inherit the permission (https://docs.gitlab.com/ee/user/permissions.html) to edit labels automatically, no need for bots.

Did we ever create an issue upstream about the scalability problem we had?

A thought on the above limitation (so just thinking out loud here...)

When the new fork management system is in place, users wanting to collaborate will need to "request access", and this will give them access to the fork. We can expand that functionality by adding the user at the same time to the canonical project as well as "reporter" with an expiration date (https://docs.gitlab.com/ee/api/members.html#add-a-member-to-a-group-or-p...). This way users who do not participate regularly will be cleaned up automatically/regularly.

We could even implement a separate CTA to grant "reporter" access to a project and we can implement this from the project page or at issue level (with the automatic message we're sending when creating issues).

Did we ever create an issue upstream about the scalability problem we had?

📌 Give everyone with git.drupalcode.org commit access to all issue forks Closed: won't fix & https://gitlab.com/gitlab-org/gitlab/-/issues/381745 were the issues. We would have the same scalability issue with mass-granting access to the project group. GitLab must internally do something like updating records for every person who has access to every project. There is some possibility we could absorb the issues now that we have better servers and GitLab is always making performance improvements.

We could even implement a separate CTA to grant "reporter" access to a project and we can implement this from the project page or at issue level (with the automatic message we're sending when creating issues).

That could work, not really ideal, but is a lot better than expecting people to get bot commands correct and issue summary updates would not be really possible otherwise.

Info regarding how the mapping of metadata to labels is done on the migration scripts:

LABELS
  // Calculate labels for new GitLab issue.
  // Project-specific.
  $labels = _drupalorg_gitlab_get_tags($record);               // same tag values (taxonomy_vocabulary_9)
  $labels[] = _drupalorg_gitlab_get_component($record);  //component::___(camelized)
  $labels[] = _drupalorg_gitlab_get_version($record);        //version::___
  // Global.
  $labels[] = _drupalorg_gitlab_get_priority($record);        //priority::___ (critical, major, normal, minor)
  $labels[] = _drupalorg_gitlab_get_category($record);      //category::___ (bug, feature, plan, support, task)
  $labels[] = _drupalorg_gitlab_get_state($record);            //state::___ (accepted, fixed, closed, postponed, needsReview, needsWork, rtbc, toBePorted)
  $labels[] = _drupalorg_gitlab_get_why($record);             //why::___ (duplicate, wontFix, workAsDesigned, needsInfo, outdated, cannotReproduce)

The :: syntax is GitLab-specific to display the labels by category:

I would like to express an opinion against granting reporter rights.

In my opinion this is a trusted role, equivalent to the “manage issues” D.O. permission and should not be granted to general users

I’ve had a number of issues in projects that the Drupal Security Team will not consider Security issues however they are sensitive enough that the ability to use GitLab’s Confidential Issues feature would be useful to coordinate between maintainers.

Confidential issues may also be useful for when a user might want to give a maintainer a chance to review an issue to be sure it doesn’t have a larger impact even though it doesn’t meet guidelines to submit to SDO.

Granting the reporter rights wold nullify the ability to use that feature.

Additionally, unless we are going to change policy to allow the security team to delete issues setting an issue confidential to me appears it may be the only way to hide them?

Additionally with the increased access users would be able to compromise the ability to reliably use other GitLab planning tools (such as issue boards).as they could change all labels.

To me the suggestion to use issue templates seems the most interesting and the closest fit into how GitLab is designed to be used.

This is a policy issue which will inform how the migration of labels will take place. Once we have consensus, documented in the issue summary, then the issue can be closed, and implementation done in appropriate issues, which are already started.

For all the metadata fields listed in the issue summary - Status, Priority, Category … - we need to decide:

• Do we migrate to group labels, which are consistent across all projects, the maintainer has no control over them.
• Or do we migrate to project labels, which project maintainers can update later. For example, they could delete Status:Critical if they don’t want critical issues.
• When we migrate to project labels, we need to decide if we set up the same defaults for new projects. If Status is a project label, do I have Status:Critical set up when I start a new project?

In the issue summary I filled out “Component - project label, no default for new projects” as an example. Components are already set up per-project, and I don’t think there’s any need for any default component labels for new projects. They do currently have defaults Code/Documentation/Miscellaneous/User interface, but I personally lean toward those not being useful defaults; new project maintainers can have a clean slate.

Follow up to #17, we can see the group labels here: https://gitlab1.code-dev.devdrupal.org/groups/project/-/labels

A possibility that we should really consider is to NOT have global labels, and make them all project-specific. The labels will be migrated to the issue and project, so the information from existing issues will be there, but they don't need to be used for future issues. So the labels would always be project-specific.

Each project maintainer can decide what makes sense for their project, without having any limitations.
ie:
- some smaller projects might not even want labels at all.
- or some projects might have their own kanban board and use those states.
- some projects might want to use a subset only or to expand the current ones where it makes sense.

Creating complicated workflows around labels might not be ideal and will add complexity when trying to contribute. This means that we will not have standard/common metadata between projects, but maybe that's ok.

There would be no difference for end users or even maintainers but it will make processes easier.

My main concern if we set all labels as project-specific is, that it will have a potential to confuse contributors in terms of that the contributing experience will not be uniform anymore.

Currently these settings are similar in all projects and contributors know what to expect (and I think it is good, as all projects are under drupal.org, so at least some uniformity is important). It would not be good if a contributor goes from one contrib project to another and has to explore how differently it goes there. On the other hand, I understand, that there is a lot of non-code projects, where some labels does not make sense.

I think labels like "category" does make sense to be project-specific.

But I would be cautious with "status" label and not sure about "priority" either. Maybe if it would be possible to create them as project specific, but for each project (existing a new) set default values to what we have now, so at least all are at the same starting point (further customization by projects will be ok, but if we do not set the default values, then I can imaging the "mess" it could become in some contrib projects).

I suppose that "version" label will be according to the branch names and tags?

Then there is a question about issue tags - currently you can search all projects for example by PHP8 tag ( https://www.drupal.org/project/issues/search?issue_tags=PHP%208.1 → ). Would this be possible with Gitlab issues, when each project would have a separate issue tags, to do this? I think this is a beneficial feature.

In my opinion this is a trusted role, equivalent to the “manage issues” D.O. permission and should not be granted to general users

Not sure which extra permissions this role has, but currently all contributors could change practically everything in d.o. issues and that is good and contributors are used to it. If we remove this ability, we would move a lot of work to a few maintainers, which would not be good. And we would also need to "re-train" contributors to the new workflow. So I think we need to carefully consider this to do only the most necessary changes (in the first step?). The next step could be to allow to utilize more new Gitlab features and consider, how to do this.

For priority, I end up pretty much ignoring it in contrib. My priority as a maintainer might mismatch the reporter’s priority. It isn’t worth nitpicking over what the correct priority is. Core has more-formal definitions of priorities, so it is useful there. As a contrib maintainer, I would like the ability to remove the priority metadata from some projects.

Version will have to be per-project regardless. GitLab does not have the same sort of version field in issues, it will be just another scoped label. The label values will have no relation to the tags, branches, or releases, except for naming conventions. Migrated issues will have the existing issue version values migrated. We’ll have to decide if Drupal.org creates a new label for the project when a new release is made, or if that’s left to maintainers to do, if they want.

It would be nice to be able to remove 'support request' as an option in the core issue queue, because the core issue queue is never the right place to get an answer to a support request.

It would be useful if the version and component fields were multiple select - I have a feeling this is the case anyway, and potentially off-topic for this issue, but mentioning here in case it's not.

However being able to remove something isn't the same as being able to add lots of new ones, so it could get confusing if there's no convention at all and different project have completely different labels. Defaults on new projects might be enough to keep things somewhat consistent though.

Thanks for bringing up multiple select, I see scoped labels are mutually exclusive: https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels

So we should also decide if we want to migrate each field to a scoped label like component::GitLab, or non-scoped with a prefix component GitLab, or simply GitLab. I can't think of a reason not to migrate components for every project to non-scoped labels. This is a good issue for planning that.

I also took a look at the labels UI for in GitLab. Projects without labels have a "Create a default set of labels" button which results in https://git.drupalcode.org/project/drupalorg/-/labels (Any labels you create now will not be special-cased for issue migration, so I don’t recommend creating labels for your projects now, unless they help your MR workflow.)

I opened ✨ Grant credit for all closed issues, not just fixed issues Active , which we will need to resolve if we do not have standard group labels for closed issue resolution, like fixed, works as designed, duplicate, etc.