On the permissions help page, It says that reporters can create merge requests.
However, I don't see how that is possible as they don't have permission to create new branches.
Cheers
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related or that one is blocking others.
Learn more.
@randx I'm curious why this is the case. It seems to me that if a contributor can fork a project they should be able to create a merge request to contribute back to it. The assumption of the fork is that they don't have commit access at all and so creating a merge request is their only method of contribution.
I can see limiting who can accept MR but not who can create them. Otherwise what is the point of the public project setting or the internal project setting if not to have contributors? Why provide the option to fork at all to non-developers if this is the mindset?
By Administrator on 2014-02-11T19:47:08 (imported from GitLab)
To give it a bit of perspective. I think the issue here is the name "reporter".
Currently we have "guest" (good in my opinion)
"reporter" (only issues, good too)
"general_dev" (missing - can fork, add merge requests, but has no other developer specific perms), "internal/project_developer" (bad naming)
"master" (good)
"owner" (good).
The new general_dev permission level would allow to finally have a review system without push access or protected branches, as I'm not sure that allowing a merge request and adding tags is actually equally important.
Additionally it would fix the issue here.
The only issue remaining would be that guests and reporters shouldn't be allowed to fork in the first place.
By Administrator on 2014-02-11T19:49:56 (imported from GitLab)
My concern with general_dev vs internal/project_dev is for e.g. an open source project. How does one create a MR if the project is public and can be forked? Or am I barking up the wrong tree and it's simply closed projects that suffer from this ailment?
By Administrator on 2014-02-11T19:52:10 (imported from GitLab)
I think it's quite difficult to decide. Internally I don't really need reporters to fork or add merge requests. On the other side on more public instances having the ability to fork and add merge requests is quite a great thing for open source contributions. So either we split it up in reporter, general_dev and internal_dev and then open source projects edit the default level or we stay with reporter only, but either add merge request and fork (already in) permissions.
(FYI, I was the one who went on #gitlab with this issue today)
The workflow seems very simple to me. I wanted to push a change to a repo, but I wasn't given commit access yet, so I forked the repo, and the tried to open a merge request for my changes and I couldn't.
I see no reason for forking if you can't make merge requests. The entire point of forking is so that your changes be merged upstream. The obvious example is Github.
I feel like forking and merge requests should be the same permission because one doesn't make sense without the other.
By Administrator on 2014-02-11T20:04:38 (imported from GitLab)
For my use case, I would like a permission level with the following characteristics:
same as Guest: new issues, comments, wall
same as Reporter: pull, download, snippets (I don't care either way about snippets)
definitely NOT a Developer: unable to create new branches, push / remove any branch regardless of protectedness, unable to manage issues / wiki
able to create merge requests
This would allow for the same setup as many GitHub projects, where anyone can fork and pull-request, but only specific people can do anything directly to the project.
By Administrator on 2014-07-17T00:41:56 (imported from GitLab)