3 ms·
No, you can do all of that on the mailing list too. - Send the mailing list an email with a url for your repository. Request that they pull from it. We call th
by db48x 4y ago
No, you can do all of that on the mailing list too.
- Send the mailing list an email with a url for your repository. Request that they pull from it. We call this a “pull request”, rather than a “Pull Request”, but it’s the same thing.
- Send an email to the development mailing list, making sure to write a nice introduction describing the changes that you’ve made, their background, motivation, drawbacks, hesitations, and so on.
- participate in feedback conversations with the maintainers and other developers with comments situated next to quotations of specific lines of code from specific revisions or specific diff hunks.
- Just run “make check”. 99% of all of the code in Emacs is written in Emacs Lisp, which is platform–independent. If the tests pass on your own computer you can rest assured that they will pass on everyone else’s too.
- sending emails to ask questions and discuss them with other developers
- feel free to include any type of media in your emails, all but one participant in the mailing list can view them
- and many other things
- count 4y ago> - Send the mailing list an email with a url for your repository. Request that they pull from it. We call this a “pull request”, rather than a “Pull Request”, but it’s the same thing. This is the 'we have PRs at home' point of view. It's not WRONG, but I think it does miss the point. 'Just do everything different from what tons of other folks are doing day in and day out' is not the best answer. The project is well within it's rights to do so, but, there's a reason GitHub specifically is super popular, and it's mostly to provide structure and avoid the pain in the neck that the 'do it by email' and 'just use these different things' approach while collaborating.
- db48x 4y ago> 'Just do everything different from what tons of other folks are doing day in and day out' is not the best answer. Following the herd is definitely the wrong answer.
- cercatrova 4y agoWell, GNU does make both.
- db48x 4y agoOk, that made me laugh.
- dagenix 4y agoFollowing the herd absolutely can be the right answer. Especially if the question is how to reduce friction for contributors.
- db48x 4y agoEveryone already has email. Not everyone wants to sign up for yet another web service. Email _is_ the low–friction option. Emacs even has a built–in way for any user to report a bug: just run `M-x report-emacs-bug` and it will give you an email template to fill out right there in your editor. No need to even open a separate program.
- BeetleB 4y agoEveryone has email. Yet less than 5% of developers have set up email workflows so that they're not drowning in patch/mailing list emails. Organizing one's email does take a fair amount of effort - an effort that you don't have to make using services like Github.
- db48x 4y agoConfiguring your email client to sort and categorize your emails for you should be easy. If it’s not easy for you, then I suggest that you are using the wrong email client. Also, I note that Github emails you every time anyone interacts with your pull request, just the same as if it were a mailing list. I recommend a client called Gnus, which can score messages based on their content, and then sort by that score. That way messages about things you are interested in (such as your own patches, features that you care about, etc) float to the top.
- machinawhite 4y agoWould you enlighten us what email clients are so amazingly good, because everything other than Mail.app is a traumatizing experience that I'm trying to avoid. Gnus doesn't look very user friendly
- deleted 4y ago[deleted]
- xfallow 4y agoThe friction there and the lack of discoverability is enough of an annoyance to me that I don't bother trying to get any of my modifications merged. I feel like plenty of other people feel the same and I'm just hoping Neovim eventually reaches feature parity because the community feels so much more inviting.
- alwillis 4y agoI'm just hoping Neovim eventually reaches feature parity because the community feels so much more inviting. Not sure what feature parity would look like… Neovim has had a built-in LSP client for quite a while. I do agree that the community around Neovim feels super inviting.
- db48x 4y agoHmm. What do you need to discover in order to send in a patch?