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>