Considering how cheap git branches are, I would add that contributors could
create a branch with their potentially controversial changes committed in
the branch for people to better appreciate vs. users speculatively applying
patches in their own private branches. I agree with your other suggestions.
I remain a relative Emacs contribution outsider, however, despite decades
of Emacs experience as a user, and as a developer in general. I greatly
appreciate the level of discussion among Emacs developers vs. what I
experience (despite encouragement) in the commercial and educational
universes.

-Stephane

On Fri, Nov 22, 2024 at 12:25 PM Ihor Radchenko <yantar92@posteo.net> wrote:

> Alan Mackenzie <acm@muc.de> writes:
>
> > I'm resigning my position as Emacs contributor.
> >
> > The immediate reason is that, as maintainer of CC Mode, CC Mode's
> > symbols, its names, were taken by Emacs and used for other purposes
> > without informing me, much less consulting me.  That makes my position as
> > CC Mode maintainer here untenable.
> >
> > Eli Zaretskii and I have had extensive discussions, both in public and in
> > private email, over the last week or so, but we have been unable to reach
> > any satisfactory compromise solution.
> > ...
>
> It looks like most of the discussion in the original thread shifted
> towards personalities and specific example cases. I would like to create
> a new thread that will exclude that part and instead focus on possible
> constructive changes that might convince you Alan to re-consider the
> resignation.
>
> AFAIU, there are two main issues you are annoyed with:
>
> 1. Large changes are _sometimes_ committed without notice or discussion by
>    Emacs maintainers.
>
> 2. When discussing controversial changes, Emacs maintainers _sometimes_
>    make a judgment call and commit something without making it clear in
>    the discussion thread that the decision has been made.
>
> Would you re-consider if we somehow solve these issues?
>
>
> Tentative proposal:
>
> 1. Make a rule that non-trivial changes and new features _must_ be
>    announced on emacs-devel at least a month (or week?) in advance
>    before committing them, and are only committed if there is no
>    significant discussion or after the discussion is settled
>
>    If no announcement is made, they are reverted (temporarily), the
>    announcement is made, so that discussion has a chance to happen.
>
> 2. Make a rule that judgment calls are clearly indicated. If some change
>    sparks controversy/discussion and maintainer has to choose among
>    multiple solutions, such decision should be done in a separate,
>    clearly marked email, with a link to commit.
>
> WDYT?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>
>