>    That's fine, let's not discuss it then.
   > 
   > You've not explained what is hard, you raised multiple preferences,
   > but not _why_.  Sending an email to emacs-devel@ with a patch, even
   > without following those eight bullets is not hard -- people seem to be
   > doing it all the time.

   Well, I don't know how, but you managed to completely miss my
   point. First of all, this isn't a "preference", I enlisted actions
   that you *don't* do with other projects, actions that create mental
   load. And then I also mentioned that basically 90% of devs would
   expect such things to just work.

Because you are over exaggerating the hurdle to contribute to Emacs.
You claimed that you "_need_ to go read HUGE 'Sending patches
section".  It is literally: send feature suggestions (patch or not!)
to emacs-devel@, and bugs to bug-gnu-emacs@ -- that is it.

If you plan on contributing a lot, it is quite courteous to read a few
documents like the Contributing section (or how about, Emacs Lisp
Coding Conventions?) which is not "absolutely large", it is respectful
to all to know what is expceted.  

Your message was quite far larger than both documents together
... consider that for a second.  

   The reason I asked you if you ever contributed to other projects is
   because the only reason you'd ask me what's the problem with
   development workflow here is if you just have no other experience.

Yes, plenty projects over the course of 30 years.  And the process you
outlined ("PR's") is probobly the worst -- in my experience -- you
might prefer it though.  Often leading to quite bad quality since it
is so easy to just accept anything that goes through "the test"
without any regard for what it does and how it does it.

But I wouldn't call the "PR process" hard, but it does cause a barrier
(IMHO...) for people, since they need to go through many more steps
(creating a login, an issue, branch, pr, ...) instead of just editing
a file, running C-x v = and sending the result to a list.

   > Your responsibility as a contributor ends as soon as you fixed
   > whatever issues are raised by the maintainters, and they commit
   > the patch.  There is no need to look at some CI machinery to know
   > if you screwed up -- it sorta isn't your problem.

   Well… You are right. But then how do you expect a contributor to
   become a maintainer when they see problems? 🤷‍♂️

It is unrealistic to _expect_ contributors to become maintainers.
Becoming a maintainer, specially for something complicated and large
like GNU Emacs should be hard, because it is a hard and complicated
job.

Emacs has a high bar when it comes to _standards_, and _quality_ --
but contributing is trivial.  And all the praise to the Emacs
maintainers for keeping things to high standards.