5 ms·

You don't use GitHub/GitLab/SourceHut/Codeberg by "replying to emails". You use them by: - pushing branches to your own fork so that others can see your work w

You don't use GitHub/GitLab/SourceHut/Codeberg by "replying to emails". You use them by: - pushing branches to your own fork so that others can see your work while it's in draft form - opening PRs against the main project, and writing a nice PR introduction describing the changes that you've made, their background, and motivation, drawbacks and hesitations, etc. - participating in a feedback conversation with the maintainers and other developers with comments attached to specific lines in the code (at a specific revision), as well as attached at diff level - having the project CI run against your branch to check that all tests pass, across a collection of different OSs and architectures. (You can also run their CI in your own fork to check it works there before even opening a PR). - opening Issues, and discussing with other developers - having the ability to write your text comments along with images, videos, and syntax-highlighted code fragments. - and many other things

rekado 4y ago
You can still do that with your fork on a forge. And all that other stuff relating to communication (commenting on specific lines of a change set, writing a nice introduction describing the changes you've made, discussing with other developers, etc.) is possible just as well with a patch-via-email workflow.
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 ago
      Well, GNU does make both.
      - db48x 4y ago
        Ok, that made me laugh.
    - dagenix 4y ago
      Following the herd absolutely can be the right answer. Especially if the question is how to reduce friction for contributors.
      - db48x 4y ago
        Everyone 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.
mrelectric 4y ago
I get your point but why do you think that's what they need and that you're the target audience in the fist place?

rekado 4y ago

You can still do that with your fork on a forge. And all that other stuff relating to communication (commenting on specific lines of a change set, writing a nice introduction describing the changes you've made, discussing with other developers, etc.) is possible just as well with a patch-via-email workflow.

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 ago
    Well, GNU does make both.
    - db48x 4y ago
      Ok, that made me laugh.
  - dagenix 4y ago
    Following the herd absolutely can be the right answer. Especially if the question is how to reduce friction for contributors.
    - db48x 4y ago
      Everyone 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.

mrelectric 4y ago

I get your point but why do you think that's what they need and that you're the target audience in the fist place?