* On 30 Sep 2013, jpac...@redhat.com wrote: > > by this email I'd like to open discussion about the future of the mutt > project. From year to year we can witness a small, but certain decline > in the overall mutt project vitality. This is in direct contrast with > the user-base which is (according to tickets and mailing lists) both > quite active and interested.
This is a fair assessment. > 1) The following question is expected to be answered by the current mutt > project maintainers/developers. Are you feeling you have enough > resources (individuals, time, equipment...) for continuing the > development & maintenance of mutt together with recovering from the > current approach of slow-dying? If not, are you willing to let volunteer > users to take over? There are four or five people with commit rights at the moment, and all of us are pretty stressed for time. However, mutt has always been a project which grows from the community, and it's also a true observation that the rate of submission of patches has declined tremendously. To some partial extent that's our fault: our lack of time for review and shepherding of those patches that do come in discourages people from submitting patches. I think that's fairly well established by personal perspectives that have been posted on the lists. But I would argue that an "approach of slow-dying" is an unfair characterization of what's happened. If there is a slow death, it's not by design. However, it does not follow that if five committers have limited time, the project needs to be turned over in toto to someone else. It only means we need committers with time for contribution review, and we need contributors. Whether the project changes leadership and direction is a secondary issue about which we can't draw conclusions until the primary is addressed. I think that before a discussion begins of someone "tak[ing] over", and before it's fair to think that "fork it!" is a good solution to our circumstance, there needs to be an effort to bring on other strong committers into the existing team. Those projects survive best which have cooperative transitions of leadership over longer periods of time, not which have abrupt shifts of direction. Lacking a regular contibutor who expresses interest in joining the leadership team, it's premature to discuss a handoff of project leadership. How is a current team to evaluate the appropriateness of a new leader without some record to follow from? In other words, the usual pattern is not broken: if you want to join the core committer team, begin by contributing patches and openly discussing with the current leadership your interest in building toward that goal. Step in. Review patches. Contribute patches. Become a part of the process, and make sure that current leaders know and recognize your work. Vincent and I have been brought in under that spirit, but unfortunately we both have had limited time to spend since then. This is where the current leadership's efforts need to focus right now: guiding new and past contributors to a position where they can assume continuity roles. I'll commit to spending more time on that, starting with reviewing some previously submitted [PATCH]es. But it is a tandem. We also need contributors to renew their efforts at contributing, and generally, with rare exception, to follow common protocol. As a minimalpractical guide to getting started, protocol means: 1. basing patchsets on distinct Mercurial revisions where possible; 2. fully engaging in the cycle of review and revision; 3. developing patches in a manner that makes patch review easier. Further, we encourage review from non-committing members of the community -- but we need to be careful about diverging into long, abstract discussions during the review itself. That consumes our limited resource, time. -- David Champion • d...@bikeshed.us
