From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Przemys=c5=82aw_Wojnowski?= Newsgroups: gmane.emacs.devel Subject: Re: New maintainer Date: Tue, 6 Oct 2015 23:58:33 +0200 Message-ID: <56144409.5070501@cumego.com> References: <560CCEBA.9080607@online.de> <874miapdhs.fsf@openmailbox.org> <87pp0yktyx.fsf@fencepost.gnu.org> <22029.59130.54156.957525@turnbull.sk.tsukuba.ac.jp> <87io6pnujl.fsf@red-bean.com> <874mi840si.fsf@wanadoo.es> <561034C3.2060101@cumego.com> <838u7j2lq0.fsf@gnu.org> <5610CF32.6080701@cumego.com> <83vban14y5.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1444168735 333 80.91.229.3 (6 Oct 2015 21:58:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 6 Oct 2015 21:58:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 06 23:58:46 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZjaFw-0006z0-UI for ged-emacs-devel@m.gmane.org; Tue, 06 Oct 2015 23:58:45 +0200 Original-Received: from localhost ([::1]:54243 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjaFw-0000Og-6Q for ged-emacs-devel@m.gmane.org; Tue, 06 Oct 2015 17:58:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36238) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjaFs-0000OH-HP for emacs-devel@gnu.org; Tue, 06 Oct 2015 17:58:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZjaFq-0005xt-20 for emacs-devel@gnu.org; Tue, 06 Oct 2015 17:58:40 -0400 Original-Received: from smtp10.iq.pl ([86.111.242.219]:59367) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjaFp-0005x2-Ph for emacs-devel@gnu.org; Tue, 06 Oct 2015 17:58:38 -0400 Original-Received: (qmail 7236 invoked from network); 6 Oct 2015 21:58:34 -0000 Original-Received: from unknown (HELO [192.168.1.102]) (esperanto@cumego.com@[159.205.196.239]) (envelope-sender ) by smtp22.iq.pl with AES128-SHA encrypted SMTP for ; 6 Oct 2015 21:58:34 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: <83vban14y5.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 86.111.242.219 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:191025 Archived-At: >> 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