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
Re:New tools for open source maintainers
by fourthark on Wednesday April 18, 2018 @09:50PM
(#16872749)
I think they meant, when the contributor is also not the author of the changes. At least I hope this is what they meant.
Re:New tools for open source maintainers
by ocdtrekkie on Wednesday April 18, 2018 @09:54PM
(#16872763)
Ah, I didn't catch that, and that's a plausible read. Because any contributor making an edit has push access to the source branch.
I 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...
Re:New tools for open source maintainers
by dantiberian on Thursday April 19, 2018 @05:07AM
(#16874401)
That makes much more sense, I was a bit confused by that section.
Namespace retirement: Agreed with Nullability, just disable username reuse, it causes a lot more oddities than just cloning projects from unknown sources, old comments link to incorrect users and the like, it's awful.
Accidental PR protection: So this won't affect anyone, if I read it correctly, who types something in the PR description? As long as that's the case, fine, but I definitely don't want to overly impose upon the drive-by contributor... as an occasional drive-by contributor. (Sometimes I fix spelling errors, someone's gotta do it.)