Hacker News Reader

Comment by bzg | Hacker News Reader

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.

View on HN

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.

"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 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.

Interesting, I did not expect to find fennel there!

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). 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

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? :)

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.

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 - 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 :)

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.

Reviewers possibly use org-mode to keep track of those things. Would be trivial if Emacs is their mail reader.

For those who are really taking advantage of org-agenda et al, I'd argue GitHub issue tracking UI is far more restrictive for tracking patches.

If I were in that position I'd be duplicating issues into org-mode anyway (or using an Emacs mode to interact with/sync them). Maybe that's the missing link?

Isn't org-mode part of emacs now? You don't require the FSF copyright assignment paperwork?

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.

"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 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.

It's not about specific platform. It's about accepting PRs instead of patches.

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.)

I guess you may have a different viewpoint on this. But from my perspective, that's a context switch, I have to now load up my mail client and be subjected to whatever email arrived since I last opened it.

I also don't have "mailto:" hooked up to my actual email client, so that's extra steps for me to get that set up. (Blame me for this if you want to, but I'm guessing that there are probably more people like me in the world than there are people who have their email client set up to handle "mailto:" simply due to the fact that work is required to set it to anything other than the system default.)

The question is, what are you filtering for? There are always tradeoffs, and I hope I've demonstrated that the email-based interface is not "free" even for fairly savvy tech users. For less savvy tech users, I'd consider the situation even more difficult.

This is my approach:

- Copy email eddress - M-x mu4e - S-C C-y C-c RET f <select patch exported with magit>

I found just sending an email with my contribution to be a much smoother experience than filing a pull-request.

Also M-x org-submit-bug-report

> I don't personally think that Github makes PR formatting any harder

GitHub deliberately made GitHub-flavored Markdown incompatible with the way that Markdown dictated line breaks should be handled, although this affects more than just pull requests. In general, the way that people "write" Markdown meant to be published for GitHub is unreadable as plain text, even though it's supposed to be roughly as nice to read raw Markdown as it is to read the rendered form.

Many projects' commit logs are also a mess as a result of the way that GitHub pushed their pull-requests-for-everything model on the world. There is no end to the number of projects where every other log entry is a crufty merge commit, and the messages in those projects are generally useless, anyway. Folks shouldn't have to trawl through a disconnected web service to glean the info that should have been included in the commit message but was stuffed into the pull request instead.

> 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 have no horse in any Emacs race, but I agree that proper bugtrackers trump mailing lists. It's just a shame that so many people have consolidated around GitHub (and workalikes, like GitLab and Gogs/Gitea), which is poorly implemented. GitHub implements less-than-optimal workflows for its own reasons, and those reasons generally mirror other Valley-based "social" endeavors, where what's most important is growth, user engagement, and the perception of value at the expense of actual productivity and the adoption of addictive dark patterns to drive it all.

Second to the actual mechanics of GitHub is "the GitHub community", which routinely proves to be as much of a liability as an asset.

The fact that Emacs is a free software project and GitHub is not and GitHub is only slightly less of a walled garden than Facebook and that its privacy controls (what little it provides, if you want to even try to argue that it provides any) are worse than what Facebook and Twitter provide...

... are all reasons that make for a very bad suggestion to move to GitHub.

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

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/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 ?

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_7zhTGf...

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.

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...

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.

"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.

"Few" is a red herring; all it takes is one, and in Emacs's case it's more than hypothetical. They were forced to deal with the threat of the project being stalled due to Gosling/Unipress's stake in some code that was reused in the early days. After that, Stallman said never again.

And in general people people in the current era of open source seem to be sloppier/more reckless than before. Ever looked behind the scenes of Wikipedia (or heck, just perused YouTube)? You know how much plagiarism and copyright infringement is involved? Enough to worry about it. (And in the case of media uploaded to Wikipedia, people have to specifically declare that the work is theirs to license or otherwise is free content, but even with those barriers, there are people still willing to do things that jeopardize the project.) Even if only half a dozen people were ever deterred (and the numbers are certainly higher than that), then that alone would be worth it.

They don’t stop you. They just don’t take your proposal for a better sign at the entrance. Because they already had the experience of artists forbidding them to change the sign for copyright reasons (no, a yellow line around it so people with bad sight recognize it would violate my artistic vision).

Which is the better analogy than picking up trash, by the way.

With all due respect, I suggest you contrast the effort it takes to overcome these issues versus what it took to start the GNU operating system.

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/

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

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.

We do. Gitlab or Gitea are FOSS (the first one partially, the other fully I think).

And https://sr.ht.

Hehe :)

But you forget about Catholic Church dedication to Overall Truth that cannot contradict reality. Or you do not belive in it. I do. So, probably no point in discussing this, right ? ;)

In contrast to corporations dedication to them selves... Which just only on surface looks like cysnism on our part, sadly.

So, obviously MS takover over Github will end as soon as it will be convenient for MS.

But realy we have bigger problem on our hands: common ppl greed or just reluctance to pay (quite not much) for hosting of their own projects. Or paying anything for their privacy. This also is why FB already replaced home pages. And Discord (almoust overnight) TS.

We realy need to ad private git repos and own vpn's. For agents raiding servers locations should be enough.

I'm no defender of mailing lists as a substitute for real bugtrackers (I'm fairly strongly against it, actually), but GitHub is also apt to drive people away more than its fans admit.

https://news.ycombinator.com/item?id=24378401

There's also the matter of its privacy controls being extremely lacking. It's another site that takes the position that you don't get a choice on everything being "social" now, so they'll index your activity on a central timeline whether you ask for it or not and broadcast it to anyone else who does ask for it, leaving you with no recourse except to opt-out entirely.

I agree that Github is not the solution the open source community is looking for, and feel the pain of the lacking privacy controls. Still, I feel that development on Github is much more accessible than that on a mailing list, and there's probably a solution which would be more accessible but still encourage people who aren't part of the mailing list culture to contribute.

For example, mrsh has its development on sr.ht[1], but accepts pull requests on Github or the mailing list for the project[2]. This seems like (almost) the best of both worlds to me, where people who want to use a mailing list can, and people who want to use a GUI can, though there is overhead for the maintainers to fuse together the results at the end. An alternative like Gitea or GitLab might be better for your mentioned privacy concerns while still lowering the barrier to entry that a mailing list workflow presents.

Design is not my passion, so I'm drastically underqualified to comment on whether any of these websites is an effective implementation of their ideas.

[1]: https://git.sr.ht/~emersion/mrsh

[2]: https://git.sr.ht/~emersion/mrsh#contributing

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.

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.

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 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 :)

> 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.

If you want more engaged contributors you need more occasional contributors. Some of them will grow into core contributors or co-maintainers. Putting more obstacles is not the way to filter the out less engaged and keep the committed one but way to discourage the potential valuable contributors. That is why being on github where practically all of the OSS is happening is important(even being is gitlab won't have the optimal effect).

> For example, the magit maintainer responded rudely, aggressively, and discouragingly to recent PRs against magit. Stallman's absurd one- or two- sentence replies.

I must reject that unfounded criticism. I looked at all PRs since May and the only one that I rejected without much of a justification is https://github.com/magit/magit/pull/4191. I have a hard time imagining how you justify going from that to your harsh choice of words.

Luckily feedback is overwhelmingly positive, but because I have a thin skin, harsh criticism still hurts me and at least temporarily makes me lose motivation.

> I am sorry to say it but the emacs community has an atmosphere problem: it is common for people to be unpleasant in public.

I don't think it is common, but it does happen.

Hi tarsius, I should have said "a PR" singular. I'm sorry but I did find your reply to me in the tiny PR I submitted to be dismissive and unfriendly. I love magit and think your work is fantastic and I don't have any reason to justify extending from that anecdote to any generalization about your maintenance style. Sorry to subject you to an anonymous and undocumented public criticism but the fact is that it was an anecdote that was in my brain about my recent experiences with emacs development.

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

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

Reply on news.ycombinator.com