Re: contributing to Emacs

[Eli Zaretskii]

> From: Konstantin Kharlamov <hi-angel@yandex.ru>
> Cc: dsmasterson@gmail.com, arne_bab@web.de, ams@gnu.org, luangruo@yahoo.com,
>   philipk@posteo.net, emacs-devel@gnu.org
> Date: Tue, 20 Jun 2023 18:45:03 +0300
> 
> > I already said I didn't think this was a good idea, and explained why
> > I thought so.
> 
> You said you afraid some information will be lost. I explained that it won't.
> You didn't provide any counter-arguments, so I kind of hoped it is clear at 
> this
> point that it will only bring benefit. If you are referring to something I
> didn't answer, please point that out, because to my knowledge I replied to
> everything.

If you carefully re-read what I wrote about those suggestions, you
will see that the issue is exhausted from my POV.

> > In any case, that section hardly has any bearing on the main issue at
> > hand: how to make it easier for people to contribute.  I explained
> > that as well.
> 
> That is because the large issue consists of many small ones!

You cannot solve a complex problem by explaining it.  So adding more
and more explanations will not get us closer to the goal.  Especially
since almost no one reads that, especially not the new contributors.
They instead learn it on the job, one bit at a time.  And there's
nothing wrong with that, from where I stand.

> The only single
> "big move" that is theoretically possible is just move Emacs to a Gitlab
> instance, which will remove necessity to care of any docs because finding a
> developer who doesn't know how git-forges work is unlikely. But I *do not*
> suggest doing that because I know many long-timers would not want that. So
> instead I am trying to bite at different pieces that could be improved without
> affecting existing workflow. This docs discussion is just one small piece.

We considered Gitlab, and also a couple of other alternatives.  They
all had problems that needed to be solved first, and no one stepped
forward or succeeded to do that.  You can find all this in the
archives, including our minimum requirements to any such
workflow/framework.