Re: contributing to Emacs

[Konstantin Kharlamov]

On Sat, 2023-06-17 at 14:36 -0400, Alfred M. Szmidt wrote:
>    (I changed the email title as I feel this is kind of offtopic regarding
> Android)
>
> My "qualifications" are also off-topic for emacs-devel, it is you who
> needs to answer what "notoriously hard" means.  Clearly, people do not
> find it as hard as you claim to.

Okay, well. You see, in 90% of open source projects contributions work like 
this: you
create a branch, you add commits, you `git push` — and then if your changes 
weren't
registered yet for review, you'll get a link in your terminal to immediately
send them for review. Otherwise you don't do anything at all, it is already in
review, and simple push makes it available to maintainers to see.

A few projects have special requirements, like "have a Signed-off-by" line. In 
such
case in a few minutes you'll get an email saying your commits didn't pass CI, 
so you
look at it, you fix it.

Such simplicity makes contribution a complete no-brainer. I can't count how many
times I was stumbling upon something easily fixable in a project I don't even 
use,
(in such cases it's mostly docs improvements) and in five minutes I had changes
applied and sent for review.

This "90%" you can count as the chance that if a new developer comes, they would
expect it to be that simple. Which isn't the case for Emacs. If contributing to 
most
open sources projects only requires finding out their upstream URL, in Emacs 
case you
also need to go read HUGE "Sending patches" section. And then if that's not 
enough,
from what I've seen maintainers also expect you to have read CONTRIBUTE section,
which is absolutely large, much bigger than "Sending patches". (to be fair, if 
you
are a new contributor, you won't know it exists because "Sending patches" has no
mention of it).

This alone may eliminate a number of contributors who has no experience with
contributing via mailing lists (I think a lot of devs has no such experience, 
because
offhand the only widely popular projects that still use MLs are the kernel, 
glibc,
gcc and Emacs), and who wouldn't like to have to spend too much time figuring 
it out.

But some devs know how contributing via ML works. They will probably send their
patchset to bug-gnu-emacs, and… they will find out that debbugs for some reason
created a dozen bugreports for each individual patch 😄 Amazing.

But let's set aside the "newness" problem, let's imagine a developer who 
already has
experience, know all these problems and obstacles. Like me. Even in this case
contributing is inconvenient, because you can't "just push new revision" and be 
done,
you need to also send it to some URL. And then some maintainers have differing
requirements: typically in ML-managed project you just do `git send-email`, but 
I've
also been asked once by someone to attach patches instead, which makes 
situation even
more complicated. You see: these are complete no-brainer in 90% of projects. But
every time I contribute here I have to think about such stuff which is 
completely
irrelevant to the changes being sent.

And how do you even get a link where to send new patch revision? I have two 
dozens
email notifications coming to my email everyday. So I will have to search 
through all
that stuff.

And then, debbugs has no syntax highlight whatsoever and does not show the 
latest
patch revision. So studying the patch quickly in the interface is inconvenient 
at
best, you'd rather open it locally in Emacs (if you have the patch locally).

How do maintainers review code being sent I don't even know. I am a 
co-maintainer of
`color-identifiers-mode`, and we have set up CI and tests, so I immediately 
know a
contribution at least passes tests. But in absence of CI I guess you have to 
manually
check that the patch someone sent at least compiles…?

So, yes, contributing to Emacs is hard.