Fix cross-organisation "Allow edits from maintainers"

[xmo-odoo]

(aka "Allow edits by maintainers")

Currently, if a PR is created from a fork living under an organisation (rather than an individual) it's not possible to allow edits by maintainers. This is better than the previous state of affairs where the feature was available but did not work, but it remains less than great.

Cf isaacs/github#1681 for a long list of maintainers mentioning exactly this issue on dozens of PRs (which probably undercounts the issue by orders of magnitude as they'd need to know about the informal isaacs tracker).

[joao-paulo-parity]

You might want to change the title to match the exact option name

-allow edit by maintainer
+Allow edits from maintainers

I just filed #9921 because I was not able to find this issue before

[dafreitag]

Interestingly the documentation shows a screenshot that is "Allow edits from maintainers", but I just did the same thing on a personal pull request and it shows "Allow edits by maintainers

"

[joao-paulo-parity]

Moving over feedback from #9921

Personally, I do not see a reason for "Allow edits from maintainers" to have a different behavior if the pull request is coming from a organization. If you think otherwise and it's working as intended then please explicitly state what's the official decision regarding this behavior.

This is blocking some commit-automation-based tools from working as intended, as reported in isaacs/github#1681 (comment)

• feat(codebuild): allow setting concurrent build limit aws/aws-cdk#14099
• Companion for impl Zero and One for fixed point numbers paritytech/polkadot#2922

[xmo-odoo]

Personally, I do not see a reason for "Allow edits from maintainers" to have a different behavior if the pull request is coming from a organization.

I would assume the reason is that organisation accounts have different and more complex collaboration models so not breaking anything is probably riskier, and furthermore orgs are commonly companies which may not want "unmanaged" / "stealth" contributors of that fashion.

Not that that makes this limitation any less of a pain, mind. But it's not hard to imagine why it would be.

[dafreitag]

This is increasingly becoming an issue for pull requests to outside projects from forks inside our Org. I concur with @joao-paulo-parity opinion. If there is a technical limitation causing this option to be missing, we would like an explanation and clearer documentation as to the difference between Org and user created forks in respect to this option's availability.

Is there a simple work around in the meantime? Can commits be added directly to a pull request by the maintainer if they are added to our fork as an outside collaborator? It's not an ideal solution if so, but may help with the issues we are experiencing while making contributions.

[xmo-odoo]

Can commits be added directly to a pull request by the maintainer if they are added to our fork as an outside collaborator?

Yes IIRC if the maintainer is added as a collaborator to the repository they'll get whatever access you grant them.

But that can be rather distasteful as the "write" access level (necessary for pushing code to the repository) also provides write access to a lot of meta-information which you may not want to grant to the maintainer on the other side. Though I guess it's less of an issue when it comes to forks.

[DenverCoder1]

This is still an issue.

I use an organization account in order to keep my forked repos separate from my main projects, so I'm always making PRs from an organization account.

There have been several times I wanted to allow edits from maintainers, but was unable to find the option.

[danez]

Same exact use-case and problem here.

[luciosis]

IS there any update to this issue? we got same use-case and problem here

[ShayBox]

Same problem, nobody can commit to my forks, I keep them in an org for separation.

[denverbaumgartner]

still a problem :(

[g-s-eire]

This is still an issue.

[dluc]

HELP! Please fix this, or we shall move to svn 🥲

[sethgw]

help

[piRGoif]

Hello,

We have the same issue in our Combodo/iTop repo. Some of our contributors are employees of companies that are Combodo partners, so they are using forks in their employer org and won't create forks in their personal account...
Sample PR where this was an issue : Combodo/iTop#523 (comment)

I understand a repo in an organization is shared with more people than just personal repo... Maybe add org to org authorizations ? Like in the previous example, allow Combodo/iTop maintainers to have access to Itomig fork during a day ?

[FVidalCarneiro]

This seems to still be an issue and is limiting organization's ability to contribute to open source projects, example pull-request here.

[3kh0]

Still a issue and waiting for something to be done about this

[dluc]

If "edit from maintainers" isn't an option for PR submitters, consider adding "block PRs from organizations" for repo owners.

Receiving PRs without the ability to collaborate is frustrating, and repeatedly explaining the issue is a time-waster.

[ChrisBarker-NOAA]

WOW -- still an issue.

Anyway -- if it's not going to be changed, then at least put some prominent text on there, so I doin't spend who knows how long looking desperately for the check box!

Maybe, in place of the check box:

"Allowing edits from maintiners is not allows for org accounts' or SOMETHING!!

[rkboni]

Great idea, I just did the same thing this morning, looking at the PR from all aspects, looking through repo settings, etc. Also, mentioning this in the docs would be a great idea!

[geky]

I think this is also affecting forks of org forks, even if the resulting fork don't live in an organization. Which is quite confusing for new users.

Example: littlefs-project/littlefs#1013

[rkboni]

Another example of this: openwrt/openwrt#16779 (comment). In my case I'm using an org because I have multiple forks of a project for collaborating across different feature sets (hardware in the case of OpenWRT), and I'm unable to keep multiple forks without an organization :/