4 ms·
I'm really hoping they're only blocking PR's from non-collaborators if the PR description is empty. Requiring someone to be a collaborator on a repository to op
by quiq 8y ago
I'm really hoping they're only blocking PR's from non-collaborators if the PR description is empty. Requiring someone to be a collaborator on a repository to open a PR is a step backwards to me. It's really nice to notice a trivial fix like a typo when browsing the code, fix it in the integrated editor and hit PR right there. I could see having the option to disable PRs useful, but removing the functionality entirely
- fourthark 8y agoI think they meant, when the contributor is also not the author of the changes. At least I hope this is what they meant.
- ocdtrekkie 8y agoAh, I didn't catch that, and that's a plausible read. Because any contributor making an edit has push access to the source branch.
- dantiberian 8y agoThat makes much more sense, I was a bit confused by that section.
- archi42 8y agoI think that's what they meant. Anything else wouldn't make much sense anyway. Seems like making a PR out of someone else's "private" changes now requires two PRs: first into my fork, then to upstream. Not that this is a common use case, but I did consider this two or three times the last five years...