From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: More metaproblem Date: Fri, 05 Dec 2014 10:51:40 -0600 Message-ID: <87iohq6nvn.fsf@ktab.red-bean.com> References: <20141203142859.24393.98673@vcs.savannah.gnu.org> <20141203192721.GE12748@thyrsus.com> <547F6774.50700@cs.ucla.edu> <838uio5vjw.fsf@gnu.org> <20141203211447.GB15111@thyrsus.com> <871toge5zw.fsf@floss.red-bean.com> <83388v6hsq.fsf@gnu.org> <87egsftgd5.fsf@ktab.red-bean.com> <83egsf3yci.fsf@gnu.org> Reply-To: Karl Fogel NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1417798327 15865 80.91.229.3 (5 Dec 2014 16:52:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Dec 2014 16:52:07 +0000 (UTC) Cc: esr@thyrsus.com, eggert@cs.ucla.edu, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 05 17:52:01 2014 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 1Xww6o-0001Yo-6y for ged-emacs-devel@m.gmane.org; Fri, 05 Dec 2014 17:51:58 +0100 Original-Received: from localhost ([::1]:51329 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xww6n-0007OY-Kl for ged-emacs-devel@m.gmane.org; Fri, 05 Dec 2014 11:51:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56786) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xww6g-0007OR-2N for emacs-devel@gnu.org; Fri, 05 Dec 2014 11:51:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xww6a-00014A-Hg for emacs-devel@gnu.org; Fri, 05 Dec 2014 11:51:49 -0500 Original-Received: from mail-ig0-x22a.google.com ([2607:f8b0:4001:c05::22a]:60164) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xww6a-00013s-Av; Fri, 05 Dec 2014 11:51:44 -0500 Original-Received: by mail-ig0-f170.google.com with SMTP id r2so1066170igi.3 for ; Fri, 05 Dec 2014 08:51:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:reply-to:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=VkIyEyISQitQwsix+eBqoT2AQlbpo5BlidMvfZ7wlS0=; b=mfoukHoR5D0ugN0jctP6qDfjxpm8PIV9uI5mV9zKPBR2+uuV3KW0QHs7yUC5K6PxWM VkWizaH+qupYBrmpnllQ4vdis4CLtU4wxkwC0FV9T4BPNNXhHjgE62B6LKSw43oVXPFe UbTN42OtrIGg3jxSdyphMAkROLSyh5oKpCVkyxrrspptFYaPRJ3kvBfLVFb7/+T3pIC0 kriVy+LlU19yc/iZRe51xTbJ4ZSpUsl/4J2eZdrWkEh4YGLzXcvnpx1Dtf7lALbyyUZa 2k7zim/0hc5CMO4/7wfXaw5R2CY6s7mlAJ4vDvwlYdUCGPfksAl0ne2bpV54pub2Nsvv WZOg== X-Received: by 10.43.120.69 with SMTP id fx5mr13581628icc.45.1417798302536; Fri, 05 Dec 2014 08:51:42 -0800 (PST) Original-Received: from ktab.red-bean.com (74-92-190-113-Illinois.hfc.comcastbusiness.net. [74.92.190.113]) by mx.google.com with ESMTPSA id l5sm1050546igu.10.2014.12.05.08.51.41 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Dec 2014 08:51:41 -0800 (PST) In-Reply-To: <83egsf3yci.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 04 Dec 2014 23:21:33 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c05::22a 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:178951 Archived-At: Eli Zaretskii writes: >Not really sure how to respond to this. What exactly is the purpose >of what you wrote? I'm trying to spell out the nature of the problem in order to persuade influential Emacs developers (like you) that there is a problem. If enough agree, that can make it easier to fix, even if those people aren't the ones who fix it. For example, momentum is building around auto-generated ChangeLogs now, largely because developers who contribute a lot to Emacs are either supporting it or no longer actively resisting it. I'd like to build momentum similarly around the idea of revamping the way we treat contributors, especially new or lightly-contributing ones. If we had a consensus about how to improve the contributor intake process, that might make people who are currently too afraid to volunteer to do it less afraid. Currently, volunteering to do it implies long arguments on this list with people who think things are fine the way they are, which is prospectively exhausting, so no one's likely to come out of the woodwork and even try right now. >> What most projects do is have a development web page. linked to from >> their main user-facing web page. The development page organizes all >> this stuff and provides links to source code repository, dev guidelines >> & documentation, etc. > >Volunteers are welcome to take similar care of the Emacs Web page. >I'm sure they will be most welcome if and when they come. Hmm, what is the path for such volunteers? That site & page are maintained by the FSF -- they're not in the Emacs tree anywhere. In other words, whatever the procedures are for improving the Emacs home page (and creating a developer welcome page), they are completely different from the procedures for improving the Emacs code. So, yay, now I have to learn *two* contribution paths. >> > Feel free to contribute the missing documentation, and thanks in >> > advance. >> >> It's not just a matter of contributing documentation. We don't even >> *have a place to put such documentation* right now. > >Of course we do: etc/CONTRIBUTE. We just decided to move it to the >top-level directory. It should be a web page. That's how things work now. But my hypothesis is that anyone who tried to convert it to web page right now would face multiple obstacles, including not just technical obstacles but resistance to goal itself. I'd love to be wrong about that. Am I? Specifically: If we could work out the technical details to have a "www/" directory at the top level of the Emacs source tree, and have that be where both the home page http://www.gnu.org/software/emacs/ *and* soon-to-be-written new developer-oriented pages are maintained, would you be in favor of that? (I don't mean volunteer to help, I just mean support the goal or anyway not oppose it.) >> Mozilla Firefox or LibreOffice, to name two off the top of my head. > >Don't know anything about those. I do know about GCC, GDB, Groff, >Guile, heck, even Make. Nothing easy there for newcomers. You've named some of the oldest free software projects on the Net, and ones specifically oriented toward GNU toolchain programmers. I think there *might* be some selection bias at work here :-). >And what counts as "easy", anyway? having a "contribute" Web page? >Are you really going to seriously claim that this is all that stands >between a project and being "easy" on newcomers? If so, perhaps we >have been contributing to 2 very different classes of software >projects, because the main obstacle in my experience is not the >mundane rules like that, it's the need to understand the architecture >and the design of a complex piece of software, enough so to be able to >contribute non-trivial changes. (See above about selection bias.) My claim was specific: I claimed that in the other projects I named, you *don't* see people complaining about how hard it is to contribute, the way we regularly see here. I'll add to that the claim that you *do* see new contributor acquisition and retention at a better rate in well-run projects. I have seen this myself in projects I know well, and I've checked my impressions with people in other projects and they confirm it. Above, you seem to be confirming my assertion that you don't think there's a real problem here -- that is, you think that the changes I describe would not make Emacs easier to contribute to, because the real causes that make Emacs hard to contribute to have to do with the nature of the code base. I don't think that's true, especially in Emacs' case: it has a well-documented extension language and gazillions of lines of Elisp code for people to use as examples. Few projects should be as easy to contribute to as Emacs should be. >To summarize, my analysis of what you wrote is that you expect too >much of the handful of volunteers who develop and maintain Emacs >entirely on their free time. A few people can only do this much. You >want to improve things -- come aboard and be welcome. My request is simple and specific: I'm asking the biggest contributors to Emacs (you, among others) to - Not oppose a revamp of the contributor documentation along the lines I described; - Not oppose using a modern bug tracker -- one that supports email manipulation but *also* supports manipulation via a web browser. (Redmine, for example.) Those two changes alone would lower the barrier to entry significantly. Senior developer resistance to those changes effectively means they can never take place. Absence of such resistance doesn't guarantee that they will take place, but is certainly a necessary precondition. Right now, any volunteer energy toward such changes is pre-quashed: anyone who might think of doing them, but who reads this list, would quickly come to the conclusion that it would be a huge fight, a months-long abuse fest, and give up in advance. So I'd love to see that barrier go away, just to see what would happen. -K