[kazinator]

On the job, I wouldn't go implementing whatever pops into my head without input from my manager and product management.

Even if the change could easily pass a technical review and get merged.

First you have to determine: do we need this for the product? If this change is made, does it break user workflows? What difficulties will users have if they pick up this change?

[tsimionescu]

Emacs is a community-driven project. And the author of this patch identified several issues with the feature, created a fix, proposed it for review, debated the impact with other devs on the mailing list for weeks, addressed all concerns raised, and then finally other more senior devs merged the change to master, where all new unstable changes go.

Then, people who agree to test out all changes to Emacs by using the head of master found, basically the QA department of Emacs, came back with feedback that they like some of the improvements, but that they don't like one particular aspect (the extra RET). Thierry started addressing them, and a setting to disable the feature was added - but the initial version missed the mark. The article author also was part of this process, and even proposed a patch, but their attitude made others ignore it after the initial review (their patch reverted all changes and only implemented a tiny subset of the original, behind the discussed flag).

[kazinator]

I've now read (or at least skimmed) this in it entirety:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66394

Thierry opened this as a simple bug, but then implemented something with multiple enhancements rather than addressing the bug, while causing UX regressions.

It looks like only one developer was engaging the content, a Michael H., and he pointed out early, as far back as in October, both the problems that Eschel later latched onto.

Eschel came up with a patch that just addresses #66394 in a small way.

The reply to that was:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=66394#201

"But your patch only fixes this bug, reverting half a dozen features mine adds."

Using a bug ticket as a vector for introducing enhancements is a software engineering no-no.

They should merge the simplest patch that closes the bug without regressing anything or introducing extraneous enhancements. For those, a new enhancement ticket should be opened.

If Eschel's patch can close #66394, and not break anything, the consideration of that it doesn't implement another solution's enhancements is actually a plus.

There is possibly another bug ticket hiding in there based on the remark [y]ou reintroduced the old implementation which was not wrote correctly about handling various keys, particularly C-g. Existing behavior of not correctly handling various keys sounds like a problem different from the 66394 issue.

If the project doesn't want the simplest fix for an issue, but to address something architectural, like with a view for adding enhancements or whatever, that can be turned into another ticket where you articulate that. The original bug can then be marked pending or blocked by that with a note that we don't fix this until that one.

[gpderetta]

Does Emacs even do enhancement tickets? It is a community driven project where people implement what they want to scratch an itch and get merged as long as they convince enough people; it is not a PM driven one with roadmaps, sprints and narrowly defined features.