| > thevast majority of modern software developers do not want to use email
as their communication channel Wait. What? I must be old school then, with my ~12 years of experience, because I think email is much more approachable than some of the modern communication methods. I create text and send it in an email. I get an email back. Repeat until complete. Or do people really think it's better to go out and sign up for yet another account with Slack (or is that Github? Or Discourse? Or HipChat? Or BitBucket? or...), verify my email (ironic, no?), get into a chat room, try and get a dev's attention in the rolling spam of giffy links... Or perhaps I'll create yet another gitlab issue and pull request, so they can get lost in the thousands of others, due to the lack of organization capability present in most email clients. Yeah, I prefer email, personally. > the Old Guard and the Next Generation An excellent way to alienate the people you're trying to get help from. > put a Code of Conduct in place for all communications on gitlab. Sigh. This again? > If Emacs could move onto gitlab and use a pull request workflow What real benefits does this offer, over an email patch? If this is the "New Guard", perhaps it's best they are scared away by email. |
Also, I hate the pull request workflow; it's a big barrier to entry for people dipping their toes in with small changes. If you're trying to recruit more participants, or encourage an open-source project to open itself up to more participants, why on earth would you adopt a workflow which requires more up-front folderol on the part of the patch submitter? Just let people send in their patches and be gracious about accepting them. You can gently suggest that they start jumping through git branching hoops and other project-specific processes later, when they're already on board and committed to participation.