Can't assign issue to contributor

In GitLab, we can track all the issues that are being worked on. As an open source project, it is important to have many contributors, to ensure a healthy ecosystem. They can take up part of the work, as the project committers can't do everything.

However, we can assign issues only to committers. Contributors thus have to add a comment to the issue to indicate they are working on an issue. See e.g. eclipse/escet/escet#55 (comment 6179).

Also, in a GitLab milestone, the issue will belong to the 'Unstarted Issues (open and unassigned)' category, rather than to the 'Ongoing Issues (open and assigned)' category, as nobody will be assigned to it. See e.g. %v0.2 in eclipse/escet/escet.

It would help if issues could be assigned to contributors as well. That way, it is clear who is working on an issue. It would also provide a better overview in the GitLab milestone overview for a certain release.

Could this be configured? Is it possible at all?

changed title from Assign issue to contributor to Can't assign issue to contributor

As a first step: all developers can assign issues to contributors, once they have commented on an issue. To do this, click on the three dots on the right of an issue comment of a contributor and select "Assign to commenting user". Unfortunately, this still requires manual work from the developers.

The next step would be to invite a contributor to the project's group and assign the "reporter" role, which allows to assign issues, label issues, etc (see https://gitlab.eclipse.org/help/user/permissions).

Inviting a user to a group requires at least maintainer permissions (currently blocked by https://gitlab.eclipse.org/eclipsefdn/gitlab/-/issues/17). This also needs to be supported by our GitLab sync script.

Inviting a user to a group requires at least maintainer permissions (currently blocked by https://gitlab.eclipse.org/eclipsefdn/gitlab/-/issues/17). This also needs to be supported by our GitLab sync script.

Looking at https://github.com/EclipseFdn/eclipsefdn-github-sync/issues/143, this is supposed to work already, but it does not.

[...] click on the three dots on the right of an issue comment of a contributor and select "Assign to commenting user".

Ah, that's very hidden. I was looking at the right side bar. There for 'Assignees' I could only auto-complete committers. I could also not add anybody manually, only the auto-complete entries. I'll try the approach via issue comments.

Ah, that's very hidden. I was looking at the right side bar. There for 'Assignees' I could only auto-complete committers. I could also not add anybody manually, only the auto-complete entries. I'll try the approach via issue comments.

I agree that it's quite hidden. It's in fact similar to GitHub were outside collaborators also have to comment first on a issue, before it can be assigned to them.

I've commented on https://github.com/EclipseFdn/eclipsefdn-github-sync/issues/143. Let's hope it can get fixed soon.

As a first step: all developers can assign issues to contributors, once they have commented on an issue.

That is a precondition that already doesn't hold for at least 5 issues we have in the Eclipse ESCET project. A contributor directly created a merge request. There are no comments. So this approach is not sufficient for those cases. See e.g. eclipse/escet/escet#60 (closed).

However, we can assign issues only to committers.

Confusingly, I can assign a merge request to a contributor. See e.g. eclipse/escet/escet!32 (merged), a merge request for eclipse/escet/escet#60 (closed).

Ok. To sum up:

• you can assign an issue to a contributor via the context menu (three dots) of a comment
• you can assign a merge request via the right sidebar

Looking into this, currently, ESCET isn't making use of the contributor field in PMI (https://projects.eclipse.org/projects/technology.escet, under Source Code and Issues/Bugzilla). If this field is properly populated with contributors, they will be given Reporter privilege in the repository. Managing users through Maintainer privileges is not recommended, as users not managed through PMI are purged multiple times a day.

Not being able to select users without permissions on a given project is a base Gitlab feature that I don't believe we can affect and can be resolved through the above workflow. Once this is done, collaborators will be able to assign themselves the issues even.

Thanks @malowe for the clarification. So adding contributors to PMI is the correct way to handle this use-case.

Thanks @fgurr and @malowe. I add the contributor as you suggested. After some time the permissions were then enabled.

closed

mentioned in issue #577 (closed)

mentioned in issue #1718 (closed)