5 ms·

Can you elaborate a bit more on how this would simplif the contribution process? Perhaps it would make it more familiar, but I don't think it would really simp

by bzg 6y ago

Can you elaborate a bit more on how this would simplif the contribution process? Perhaps it would make it more familiar, but I don't think it would really simplify it. First because I think issue handling on GitLab/GitHub kinda worsen the problem of the lack of maintainance resources, instead of fixing it Second because we are quite strict on how to format changelog entries, and I believe email interactions help educating contributors in a nice way, while MR/PR interactions might generate more fatigue -- not so sure about this one, though.

iLemming 6y ago
There was a long thread on the topic in the emacs-dev mailing list not too long ago that generated a heated discussion of over half-a-thousand messages (where most of it was around "the proper way of sending patches"). I'm not trying to start another flamewar. The basic notion is that the email threads model is focused around the subject line, and PR-model is specifically designed to have discussions where the code changes take the main stage. I'm sure if you ask Jonas Bernoulli, Steve Purcell, Oleh Krehel, Bozhidar Batsov, and many other prominent Emacs hackers, they'd probably agree, without PR-model, it would be a lot harder for them to find so many contributors for great Emacs packages they authored and maintain. To be honest, it feels a bit ironic when the shepherds of Free Software (GNU hackers, et al.) choose to ignore the people's free will, and in 2020 it is clear - people have made their choice. They don't want to deal with email threads, patches, etc. The majority of developers prefer to be able to issue Pull-Requests instead. But there's something else, there's now an entire generation of software developers who simply don't know how to deal with sending patches, etc., and they don't even care. And that's not a good trend. The issue of patches vs. pull-requests has become generational. And if the old software projects fail to adapt, I'm afraid they'd slowly start dying.
- bzg 6y ago
  "But there's something else, there's now an entire generation of software developers who simply don't know how to deal with sending patches, etc., and they don't even care. And that's not a good trend." Agreed. I hope https://sr.ht https://sr.ht can help resisting this trend. I'm sure there are plenty of happy Git(Lab/Hub) users here but again, I'm not convinced these platforms would fit Org's needs.
  - shaunxcode 6y ago
    Interesting, I did not expect to find fennel there!
  - tikej 6y ago
    I'm a beginner in elisp (and tbh in programming in general) but would like to help. For me pull request model is much more natural than mailing lists and patches. It doesn't matter at all if its GitHub, GitLab or (my personal preference as it's lightweight, open source and easy to use) Gitea (interestingly it's not present in comparison on https://forgeperf.org https://forgeperf.org). I don't even know how to make PR on sourcehut and can't find any tutorial. Of course I will try to learn in order to help org but the entry barrier is much higher than for Git(Lab/Hub/ea). EDIT: I just found orgmode code on Gogs here: https://code.orgmode.org/bzg/org-mode https://code.orgmode.org/bzg/org-mode That's great! I'll register and try to help soon! Mabye it should be more visible and linked in docs (I'll... make a PR I suppose? :)
    - moonchild 6y ago
      You can still do pull requests over email. Rather than attaching a patch, you simply send a link to your git repository (+branch if applicable), and the maintainer can pull from it.
    - bzg 6y ago
      We don't use code.orgmode.org for Org's development. But please clone Org's repo, make a patch - perhaps with https://magit.vc https://magit.vc - and attach it to an email you send to emacs-orgmode@gnu.org: that's all it takes. Then we will help with polishing your contribution :)
      - iLemming 6y ago
        Alright. Now, let's say everyone is busy, and the maintainers have no time to review the patch. Who's going to remember that someone sent an email with some improvements a few months later? AFAIK There's no easy way to find all the emails with patches that weren't merged/(not) accepted/upvoted/downvoted/closed/etc. It's not easy to refer to the specific email; it's difficult to pinpoint the exact conversation around a specific change using git-blame. GitHub/Gitlab/etc. make all that a lot simpler.
eslaught 6y ago
It looks like your bug tracker is a bunch of pointers into a mailing list. This means: (a) you have no ability to edit entries (or do anything else that email is bad at), (b) the mail interface is frankly hard to read, with everything in uniform monospace font and no formatting, (c) I can't participate or reply on the web interface, I have to sign up for something completely different to participate., and (d) because of the way the site is laid out, I can't see how to get the code, etc. from the bug tracker. I would presumably go back to Google and search for org mode and then try to figure it out from there. But that's just a lot more steps to do what could be made easy. Now, I'm not necessarily super crazy about Github and the like. But for these issues, in my opinion they do a pretty reasonable job. I don't personally think that Github makes PR formatting any harder; I would expect any contributors to use a git command line to look at what they put in the commit message. But at any rate, that's some user education you'll have to do one way or the other. With the current approach, you've got a bunch of other barriers to entry that prevent you from seeing certain users in the first place.
- bzg 6y ago
  "I can't participate or reply on the web interface, I have to sign up for something completely different to participate" Let me correct this one: no, you don't have to sign up to anything: (1) click on a bug entry on https://updates.orgmode.org https://updates.orgmode.org then (2) click on "try the mailto: link" link. This is other way around: if Org goes to GitLab, GitHub-only users will have to sign up to GitLab just to report an issue, and same for GitHub.
  - iLemming 6y ago
    It's not about specific platform. It's about accepting PRs instead of patches.
    - bzg 6y ago
      I hope one day both worlds will reconcile. After all, it should be possible to have PRs sent as patches over a mailing list (and we don't need manual patches to be published as PRs.)
throwaway-org 6y ago
Other than the issues others have raised about mailing list vs. PRs from Git{Hub,Lab}, here is the information you need to send to the FSF in order to contribute >15LOC: - [Did you copy any files or text written by someone else in these changes? Even if that material is free software, we need to know about it.] - [Do you have an employer who might have a basis to claim to own your changes? Do you attend a school which might make such a claim?] - [For the copyright registration, what country are you a citizen of?] - [What year were you born?] - [Please write your email address here.] - [Please write your postal address here.] I have several bugfixes and enhancements to various org-babel languages that I maintain for my local code, but I have no interest in jumping through copyright assignment hoops or sharing my age & mailing address to push them upstream.
- iLemming 6y ago
  Yeah, that's pretty stupid. Writing free and open-source code is not a privilege. It's a community service. Imagine if you decided to pick up some trash in your local park, and cops would stop you from doing that and ask you first to submit an official form, mail it to the city hall, wait for a few days for it to be reviewed and approved...
  - hyperion2010 6y ago
    If you have never contributed to a properly managed GPL codebase, you might be surprised the kinds of things you will be asked to do. More it the point, it most certainly isn't a right that you can contribute however you want to whatever project you want. Projects have constraints. Some people can _never_ contribute to Emacs because of the other code bases they work on (e.g. Chez Scheme). If you happen to be one of the folks who can, then in a sense, it is a privilege that reflects your freedom from other constraints.
    - iLemming 6y ago
      "Some people can _never_ contribute"... the emphasis is around "some". Going back to my hypothetical example of doing community service, sure some people should not be allowed to do that. Let's say there's a person with a criminal record for throwing garbage at people, or someone who is too old or disabled for that kind of work. But it is still quite enormously stupid to create tremendous bureaucratic obstacles for everyone, for the sake of protecting a few individuals or against the potential damage they may cause.
whelming_wave 6y ago
I can't speak for others, but I'm driven away from contributing to projects that use mailing lists because there's a high barrier to entry, and here's a source of other people having the same issue[1] to corroborate my anecdote a little. [1]: https://www.theregister.com/2020/08/25/linux_kernel_email/ https://www.theregister.com/2020/08/25/linux_kernel_email/
- cat199 6y ago
  as discussed in previous threads, the person promoting this claim within the linux foundation is also a microsoft employee, and microsoft owns github. so while it might represent some trend, it is also worthwhile to possibly consider editorial/selection bias as a factor for promoting the claim that this is significantly prohibitive
  - iLemming 6y ago
    Yes, MSFT acquiring GitHub was like if the Pope, supreme pontiff of the Catholic Church has announced that they are taking control over CERN and promised it would remain an independent research organization. What choice would all the scientists have in that case? They can't just say: "I'm leaving physics until someone else builds another LHC". Until we have a better, more superior, free, open-source, public service that can do things better than GitHub, I'm afraid we'd have to play along. But the point is not about GitHub vs. something else. It is about that Pull-Requests are preferred over mailing lists for open-source projects.
    - tikej 6y ago
      We do. Gitlab or Gitea are FOSS (the first one partially, the other fully I think).
      - bzg 6y ago
        And https://sr.ht https://sr.ht.
    - Woodi 6y ago
da39a3ee 6y ago
Hi bzg, I'm an ex-org-mode contributor (we've worked together in the past!) and I do strongly agree that hosting development on GitHub or GitLab encourages people and reduces friction and is what all (yes) open source projects should do. I still write emacs-lisp packages for MELPA, but I absolutely hate the way that development of packages that have been folded into emacs is hidden behind opaque mailing-list based procedures, and apparently with little code review. Another concrete example is eglot: it is developed in the open on GitHub, which is great. But it is closely related to two other emacs packages: flymake and eldoc, which are developed via emacs-devel, or something, I've never really understood. So when changes need to be made in those packages it suddenly becomes very opaque, and I am not at all sure how much code review goes on. (This is not at all a criticism of João Távora who maintains all three I think! It is more structural and related to Emacs development in general.) It dissuades me from contributing to emacs in general. There is nothing advantageous about reviewing code by mailing list when we have GitHub and GitLab. For those of us who use GitHub and GitLab in our day jobs for code review and collaboration, it is really baffling and frustrating. Furthermore, although the org-mode mailing list is, I am sure, just as pleasant as it always way, lists like emacs-devel are incredibly toxic and depressing to read; a bunch of men arguing just like they did over IRC in the 80s and 90s. And good god, don't ever go near the #emacs IRC channel if you're not someone of that gender from that generation! I am sorry to say it but the emacs community has an atmosphere problem: it is common for people to be unpleasant in public. For example, the magit maintainer responded rudely, aggressively, and discouragingly to recent PRs against magit. Stallman's absurd one- or two- sentence replies. This is of course not Org-mode's fault; but I believe the future of Emacs development is to embrace GitHub / GitLab like other open source projects and leave the crusty 90s-era practices behind.
- bzg 6y ago
  Hi! Thanks for your feedback. I think the Org mailing list has a pretty good record of both useful and polite conversations. I don't know if the tone of conversations is different on mailing lists vs. web UIs like issues, PRs or code reviews. As I said in another reply, I guess we can somehow reconcile both worlds by allowing PRs to be sent as patches to a mailing list - I guess https://sr.ht https://sr.ht could support something like this (if it does not already). The thing with the whole "entry barrier" point of people who want Org-mode development to happen on Git(Lab|Hub) is that they miss the point: I don't want more contributions, I want more engaged contributors, more committed support of any kind. I find emails to be more engaging than emojis on a web interface - and I use both on a daily basis, so perhaps I don't deserve my #okboomer yet :)
Abhinav2000 6y ago
Off topic - but thank you so much for org mode!
- bzg 6y ago
  Thanks! Also, this release is the work of... 94 contributors, I should have mentioned this in my post.
happy-dude 6y ago
I wish Bram Moolenar could chime in on how hosting vim on GitHub has accelerated or promoted development for the editor. From what I understand, Bram's vim development workflow is very similar to other emac's dev: submitting and discussing patches via the mailing list. There was something (a bot?) setup such that PRs are forwarded to the mailing list: https://github.com/vim/vim/blob/master/CONTRIBUTING.md https://github.com/vim/vim/blob/master/CONTRIBUTING.md This was discussed pretty extensively when vim moved from Google Code to GitHub: https://groups.google.com/g/vim_dev/c/Io5A_Zir--k/m/faPCHWYfvyAJ https://groups.google.com/g/vim_dev/c/Io5A_Zir--k/m/faPCHWYf... In general, PR/patches-friction should not be an obstacle for contributions because it can be alleviated in part by tooling that glues the workflows more-or-less seamlessly. EDIT: It might be worth asking how the neovim community in general may have been helped by the decision to make github their home, or maybe even ask the emacs-lsp devs on their gitter: https://gitter.im/emacs-lsp/lsp-mode https://gitter.im/emacs-lsp/lsp-mode ? EDIT 2: In the vim-dev mailing list, there are threads started from GitHub pull requests that include .patch and .diff files: https://groups.google.com/g/vim_dev/c/7VpUqzoQycY/m/W_7zhTGfAwAJ https://groups.google.com/g/vim_dev/c/7VpUqzoQycY/m/W_7zhTGf...
tikhonj 6y ago
In my experience, moving to GitHub probably is a downgrade from a more sophisticated process in terms of functionality—but it somehow lowers the barrier to entry enough for new people to contribute noticeably more. I'm sure there's some interesting psychology there but I don't know enough to theorize; all I can do is relay my observations. I don't know if there's some way to "partially" move to GitHub—it would be cool if there were some service that synced GitHub issues with a different tracker, for example, but I've never seen that. Perhaps it would become too noisy. Of course, more contributions might not be a net gain. For each dedicated contributor, you'll also get drive-by PRs and issues that add noise which maintainers have to deal with. I do not know how that trade-off plays out in practice. So I can't give a definite conclusion about whether GitHub is worth it, but I would be willing to bet that working on GitHub would get you more contributors.

by bzg 6y ago

iLemming 6y ago

There was a long thread on the topic in the emacs-dev mailing list not too long ago that generated a heated discussion of over half-a-thousand messages (where most of it was around "the proper way of sending patches"). I'm not trying to start another flamewar. The basic notion is that the email threads model is focused around the subject line, and PR-model is specifically designed to have discussions where the code changes take the main stage. I'm sure if you ask Jonas Bernoulli, Steve Purcell, Oleh Krehel, Bozhidar Batsov, and many other prominent Emacs hackers, they'd probably agree, without PR-model, it would be a lot harder for them to find so many contributors for great Emacs packages they authored and maintain. To be honest, it feels a bit ironic when the shepherds of Free Software (GNU hackers, et al.) choose to ignore the people's free will, and in 2020 it is clear - people have made their choice. They don't want to deal with email threads, patches, etc. The majority of developers prefer to be able to issue Pull-Requests instead. But there's something else, there's now an entire generation of software developers who simply don't know how to deal with sending patches, etc., and they don't even care. And that's not a good trend. The issue of patches vs. pull-requests has become generational. And if the old software projects fail to adapt, I'm afraid they'd slowly start dying.

bzg 6y ago
"But there's something else, there's now an entire generation of software developers who simply don't know how to deal with sending patches, etc., and they don't even care. And that's not a good trend." Agreed. I hope https://sr.ht https://sr.ht can help resisting this trend. I'm sure there are plenty of happy Git(Lab/Hub) users here but again, I'm not convinced these platforms would fit Org's needs.
- shaunxcode 6y ago
  Interesting, I did not expect to find fennel there!
- tikej 6y ago
  I'm a beginner in elisp (and tbh in programming in general) but would like to help. For me pull request model is much more natural than mailing lists and patches. It doesn't matter at all if its GitHub, GitLab or (my personal preference as it's lightweight, open source and easy to use) Gitea (interestingly it's not present in comparison on https://forgeperf.org https://forgeperf.org). I don't even know how to make PR on sourcehut and can't find any tutorial. Of course I will try to learn in order to help org but the entry barrier is much higher than for Git(Lab/Hub/ea). EDIT: I just found orgmode code on Gogs here: https://code.orgmode.org/bzg/org-mode https://code.orgmode.org/bzg/org-mode That's great! I'll register and try to help soon! Mabye it should be more visible and linked in docs (I'll... make a PR I suppose? :)
  - moonchild 6y ago
    You can still do pull requests over email. Rather than attaching a patch, you simply send a link to your git repository (+branch if applicable), and the maintainer can pull from it.
  - bzg 6y ago
    We don't use code.orgmode.org for Org's development. But please clone Org's repo, make a patch - perhaps with https://magit.vc https://magit.vc - and attach it to an email you send to emacs-orgmode@gnu.org: that's all it takes. Then we will help with polishing your contribution :)
    - iLemming 6y ago
      Alright. Now, let's say everyone is busy, and the maintainers have no time to review the patch. Who's going to remember that someone sent an email with some improvements a few months later? AFAIK There's no easy way to find all the emails with patches that weren't merged/(not) accepted/upvoted/downvoted/closed/etc. It's not easy to refer to the specific email; it's difficult to pinpoint the exact conversation around a specific change using git-blame. GitHub/Gitlab/etc. make all that a lot simpler.

eslaught 6y ago

It looks like your bug tracker is a bunch of pointers into a mailing list. This means: (a) you have no ability to edit entries (or do anything else that email is bad at), (b) the mail interface is frankly hard to read, with everything in uniform monospace font and no formatting, (c) I can't participate or reply on the web interface, I have to sign up for something completely different to participate., and (d) because of the way the site is laid out, I can't see how to get the code, etc. from the bug tracker. I would presumably go back to Google and search for org mode and then try to figure it out from there. But that's just a lot more steps to do what could be made easy. Now, I'm not necessarily super crazy about Github and the like. But for these issues, in my opinion they do a pretty reasonable job. I don't personally think that Github makes PR formatting any harder; I would expect any contributors to use a git command line to look at what they put in the commit message. But at any rate, that's some user education you'll have to do one way or the other. With the current approach, you've got a bunch of other barriers to entry that prevent you from seeing certain users in the first place.

bzg 6y ago
"I can't participate or reply on the web interface, I have to sign up for something completely different to participate" Let me correct this one: no, you don't have to sign up to anything: (1) click on a bug entry on https://updates.orgmode.org https://updates.orgmode.org then (2) click on "try the mailto: link" link. This is other way around: if Org goes to GitLab, GitHub-only users will have to sign up to GitLab just to report an issue, and same for GitHub.
- iLemming 6y ago
  It's not about specific platform. It's about accepting PRs instead of patches.
  - bzg 6y ago
    I hope one day both worlds will reconcile. After all, it should be possible to have PRs sent as patches over a mailing list (and we don't need manual patches to be published as PRs.)

throwaway-org 6y ago

Other than the issues others have raised about mailing list vs. PRs from Git{Hub,Lab}, here is the information you need to send to the FSF in order to contribute >15LOC: - [Did you copy any files or text written by someone else in these changes? Even if that material is free software, we need to know about it.] - [Do you have an employer who might have a basis to claim to own your changes? Do you attend a school which might make such a claim?] - [For the copyright registration, what country are you a citizen of?] - [What year were you born?] - [Please write your email address here.] - [Please write your postal address here.] I have several bugfixes and enhancements to various org-babel languages that I maintain for my local code, but I have no interest in jumping through copyright assignment hoops or sharing my age & mailing address to push them upstream.

iLemming 6y ago
Yeah, that's pretty stupid. Writing free and open-source code is not a privilege. It's a community service. Imagine if you decided to pick up some trash in your local park, and cops would stop you from doing that and ask you first to submit an official form, mail it to the city hall, wait for a few days for it to be reviewed and approved...
- hyperion2010 6y ago
  If you have never contributed to a properly managed GPL codebase, you might be surprised the kinds of things you will be asked to do. More it the point, it most certainly isn't a right that you can contribute however you want to whatever project you want. Projects have constraints. Some people can _never_ contribute to Emacs because of the other code bases they work on (e.g. Chez Scheme). If you happen to be one of the folks who can, then in a sense, it is a privilege that reflects your freedom from other constraints.
  - iLemming 6y ago
    "Some people can _never_ contribute"... the emphasis is around "some". Going back to my hypothetical example of doing community service, sure some people should not be allowed to do that. Let's say there's a person with a criminal record for throwing garbage at people, or someone who is too old or disabled for that kind of work. But it is still quite enormously stupid to create tremendous bureaucratic obstacles for everyone, for the sake of protecting a few individuals or against the potential damage they may cause.

whelming_wave 6y ago

I can't speak for others, but I'm driven away from contributing to projects that use mailing lists because there's a high barrier to entry, and here's a source of other people having the same issue[1] to corroborate my anecdote a little. [1]: https://www.theregister.com/2020/08/25/linux_kernel_email/ https://www.theregister.com/2020/08/25/linux_kernel_email/

cat199 6y ago
as discussed in previous threads, the person promoting this claim within the linux foundation is also a microsoft employee, and microsoft owns github. so while it might represent some trend, it is also worthwhile to possibly consider editorial/selection bias as a factor for promoting the claim that this is significantly prohibitive
- iLemming 6y ago
  Yes, MSFT acquiring GitHub was like if the Pope, supreme pontiff of the Catholic Church has announced that they are taking control over CERN and promised it would remain an independent research organization. What choice would all the scientists have in that case? They can't just say: "I'm leaving physics until someone else builds another LHC". Until we have a better, more superior, free, open-source, public service that can do things better than GitHub, I'm afraid we'd have to play along. But the point is not about GitHub vs. something else. It is about that Pull-Requests are preferred over mailing lists for open-source projects.
  - tikej 6y ago
    We do. Gitlab or Gitea are FOSS (the first one partially, the other fully I think).
    - bzg 6y ago
      And https://sr.ht https://sr.ht.
  - Woodi 6y ago

da39a3ee 6y ago

Hi bzg, I'm an ex-org-mode contributor (we've worked together in the past!) and I do strongly agree that hosting development on GitHub or GitLab encourages people and reduces friction and is what all (yes) open source projects should do. I still write emacs-lisp packages for MELPA, but I absolutely hate the way that development of packages that have been folded into emacs is hidden behind opaque mailing-list based procedures, and apparently with little code review. Another concrete example is eglot: it is developed in the open on GitHub, which is great. But it is closely related to two other emacs packages: flymake and eldoc, which are developed via emacs-devel, or something, I've never really understood. So when changes need to be made in those packages it suddenly becomes very opaque, and I am not at all sure how much code review goes on. (This is not at all a criticism of João Távora who maintains all three I think! It is more structural and related to Emacs development in general.) It dissuades me from contributing to emacs in general. There is nothing advantageous about reviewing code by mailing list when we have GitHub and GitLab. For those of us who use GitHub and GitLab in our day jobs for code review and collaboration, it is really baffling and frustrating. Furthermore, although the org-mode mailing list is, I am sure, just as pleasant as it always way, lists like emacs-devel are incredibly toxic and depressing to read; a bunch of men arguing just like they did over IRC in the 80s and 90s. And good god, don't ever go near the #emacs IRC channel if you're not someone of that gender from that generation! I am sorry to say it but the emacs community has an atmosphere problem: it is common for people to be unpleasant in public. For example, the magit maintainer responded rudely, aggressively, and discouragingly to recent PRs against magit. Stallman's absurd one- or two- sentence replies. This is of course not Org-mode's fault; but I believe the future of Emacs development is to embrace GitHub / GitLab like other open source projects and leave the crusty 90s-era practices behind.

bzg 6y ago
Hi! Thanks for your feedback. I think the Org mailing list has a pretty good record of both useful and polite conversations. I don't know if the tone of conversations is different on mailing lists vs. web UIs like issues, PRs or code reviews. As I said in another reply, I guess we can somehow reconcile both worlds by allowing PRs to be sent as patches to a mailing list - I guess https://sr.ht https://sr.ht could support something like this (if it does not already). The thing with the whole "entry barrier" point of people who want Org-mode development to happen on Git(Lab|Hub) is that they miss the point: I don't want more contributions, I want more engaged contributors, more committed support of any kind. I find emails to be more engaging than emojis on a web interface - and I use both on a daily basis, so perhaps I don't deserve my #okboomer yet :)

Abhinav2000 6y ago

Off topic - but thank you so much for org mode!

bzg 6y ago
Thanks! Also, this release is the work of... 94 contributors, I should have mentioned this in my post.

happy-dude 6y ago

I wish Bram Moolenar could chime in on how hosting vim on GitHub has accelerated or promoted development for the editor. From what I understand, Bram's vim development workflow is very similar to other emac's dev: submitting and discussing patches via the mailing list. There was something (a bot?) setup such that PRs are forwarded to the mailing list: https://github.com/vim/vim/blob/master/CONTRIBUTING.md https://github.com/vim/vim/blob/master/CONTRIBUTING.md This was discussed pretty extensively when vim moved from Google Code to GitHub: https://groups.google.com/g/vim_dev/c/Io5A_Zir--k/m/faPCHWYfvyAJ https://groups.google.com/g/vim_dev/c/Io5A_Zir--k/m/faPCHWYf... In general, PR/patches-friction should not be an obstacle for contributions because it can be alleviated in part by tooling that glues the workflows more-or-less seamlessly. EDIT: It might be worth asking how the neovim community in general may have been helped by the decision to make github their home, or maybe even ask the emacs-lsp devs on their gitter: https://gitter.im/emacs-lsp/lsp-mode https://gitter.im/emacs-lsp/lsp-mode ? EDIT 2: In the vim-dev mailing list, there are threads started from GitHub pull requests that include .patch and .diff files: https://groups.google.com/g/vim_dev/c/7VpUqzoQycY/m/W_7zhTGfAwAJ https://groups.google.com/g/vim_dev/c/7VpUqzoQycY/m/W_7zhTGf...

tikhonj 6y ago

In my experience, moving to GitHub probably is a downgrade from a more sophisticated process in terms of functionality—but it somehow lowers the barrier to entry enough for new people to contribute noticeably more. I'm sure there's some interesting psychology there but I don't know enough to theorize; all I can do is relay my observations. I don't know if there's some way to "partially" move to GitHub—it would be cool if there were some service that synced GitHub issues with a different tracker, for example, but I've never seen that. Perhaps it would become too noisy. Of course, more contributions might not be a net gain. For each dedicated contributor, you'll also get drive-by PRs and issues that add noise which maintainers have to deal with. I do not know how that trade-off plays out in practice. So I can't give a definite conclusion about whether GitHub is worth it, but I would be willing to bet that working on GitHub would get you more contributors.