I claimed in a thread today, that projects using GitHub as a mirror, but refusing to process pull requests were being unnecessarily hostile to newcomers. This could be automated.
I decided to check my claim. Hilarity.
Turns out if you append the six characters ".patch" to the URL of the pull request, GitHub serves up a plain-text patch formatted as an mbox format file.
The man-page for `git send-email` specifies that as it's first preferred input format...
@HerraBRE Well that's cool. I mean so as long as GitHub maintains that feature, but definitely cool for now.
@cstanhope Yeah, this could totally disappear tomorrow. Such is the nature of SaaS.
But for now, it's very low hanging fruit for building bridges.
@HerraBRE to me one of the best perks of the mailing-list-centric flow is precisely *because* it makes it so much easier to accept patches from a variety of sources. let casual contributors send patches from GitHub, core contributors can email the mailing list for discussion, others can link to a small .patch in an IRC channel; it all ends up in the same place in the end.
@technomancy @HerraBRE I think gitlab even has email patches interop?..
@technomancy @HerraBRE Yeah, I think it's kind of unfortunate that projects have to make a choice between mirroring to Github (with all of the exposure that provides) and working the way they want to work. OTOH, I see the point about this being easy to automate. It seems like it wouldn't be that hard to write a bot to forward a pull request to a mailing list as a patch.
@HerraBRE @technomancy I'm trying to interpret that move as generously as they can, and I think the counterargument would be that if they didn't clarify their usual development process to newcomers, then those newcomers might never find out. There's a lot of value to participating in mailing lists and they'd be missing out on if they just throw PR's over the fence.
I think Github could do a better job as well. Someone in your previous dialog mentioned that Github makes it nearly impossible to turn PR's off. I actually haven't found a way to do it at all. It'd be an easy feature that would send people to the README and save them the aggravation.
@djmoch @HerraBRE @technomancy You think this discussion is timely. I'm punting on putting things on GitHub largely because of maintenance but also because I do want to encourage the use of Git as a tool and not some "magic" that's procured by GitHub (someone I mentored thought sadly that GitHub made Git).
@djmoch @dgold @jalcine @technomancy Not so weird, when you consider how much of Open Source these days is businesses sponsoring the creation of open dev tools and platforms used to build closed proprietary products just like GitHub.
GitHub was never as popular with folks who prefer the term Free Software...
I use it grudgingly. I'm weirdly more comfortable making devs, who know enough to manage their risks, use a closed platform than I would be publishing non-free code to innocent end users.
@HerraBRE might be of easier in some cases: How to apply a Patch or Pull Request by directly pulling it https://github.com/pyinstaller/pyinstaller/wiki/How-to-apply-a-Patch-or-Pull-Request-to-PyInstaller
@kirschwipfel Correct. There are many ways to skin this cat. People just need to decide it's worth doing.
@HerraBRE that's handy. However is there any way to convince GitHub's infrastructure to email this out? The main problem we have with this sort of thing is you need and end-point for a web-hook which means having a server somewhere and someone to configure and maintain it.
@stsquad I don't know!
I agree that would be handy, I suspect GH don't do it for the usual corporate SaaS silo reasons, but I'm just wildly guessing.
My comment here was in the context of projects that have already written bots that interact with GitHub and auto-close the PRs.
@stsquad If someone reads the email notifications and helps out folks that get confused, that can be enough. All depends how it's done, right?
It's extra work, but being welcoming to new contributors always is.
@HerraBRE sure and we try our best. It's less of a problem on PRs (who at least tend to come from someone familiar with code) than it is with bug reports. If you just copy and paste a form response pointing to our bug reporting guidelines that can come across as snarky but crafting an individual response to everyone saying thanks but you missed some vital information can get quite wearing.
@HerraBRE I had on separate occasion posted that same vid today! Spooky.
Generalistic and moderated instance. All opinions are welcome, but hate speeches are prohibited. Users who don't respect rules will be silenced or suspended, depending on the violation severity.