Re: New maintainer

[Przemysław Wojnowski]

> > W dniu 04.10.2015 o 08:26, Eli Zaretskii pisze:
> > > > IMHO one problem might be that, due to lack of roadmap and clear
> > > > priorities, a lot of different things are developed at the same time,
> > >
> > > I don't think you can prevent that in a project as multi-faceted and
> > > multi-discipline as Emacs, nor do I think you should want to.
I'm not saying that people should stop work on things that would not be
on a roadmap or in the next release. My point was that there should be a 
vision of Emacs in 5-10-15 years (what we would like it to be?), a 
roadmap based on that - list of features that bring us closer to that 
vision, etc. All written down.

Based on that maintainers would be able to plan releases with features 
from a roadmap - with consensus with developers. Maybe not many features 
would make it into the next release. Maybe just one of them. But it 
would make it clear what we want and were are we going (the vision). It 
would also make developers to focus on the next release.

For new developers clear goals are very important. Nobody wants to work 
on a project that goes nowhere. There always have to be some goal.

For example I see Emacs in 5 years with strong tests that immediately 
catch bugs and make refactoring fun. To achieve that I would add a goal 
that can be started right now, especially by newcomers:
1. Write unit tests to learn how Emacs works.
It's clear, very easy to do, very good for newcomers, and brings value
to Emacs. :-)


Anyway, the beauty of Agile Software Development is its adaptability.
Such teams try different things to improve their development process.
Things that don't work are refined or rejected. It's like evolution. 
IMHO Emacs community could try to apply such process. :-)

> I just don't
> think it could relieve the workload of the head maintainer and the
> resulting burn-out, which is what you were suggesting, AFAIU.
IMHO working on a concrete release would constraint number of topics
and decisions to make, which would relieve the workload.

Here are other ideas:
1. Constraint maintenance term (for example 3 years)
Such people wouldn't be exploited and maybe would step down to
development. Of course, after that time such person can decide that
everything is ok and can be a maintainer for another X years.

IMHO having ex-maintainers still in community would help subsequent
maintainers with making hard decisions. So it would also relieve the
workload.

2. Cut off-topics and end with action items.
Cutting off-topics should be done be everyone on the list. It creates a
flood of, maybe interesting, but irrelevant to the main topic, messages.

Unrelated messages make it very hard to follow the main thread.

Even this topic has a number of unrelated threads (politics, keylogger,
mac os, compiler support, etc.). How that help to find a "New
maintainer"?


Sorry for late reply. :-|

Cheers,
Przemysław