From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: Trunk still not open Date: Sun, 16 Mar 2014 03:09:46 +0100 Message-ID: References: <6xwqfxhl88.fsf@fencepost.gnu.org> <83txb1mcsy.fsf@gnu.org> <87siqlku0i.fsf@uwakimon.sk.tsukuba.ac.jp> <87wqfxari2.fsf@yandex.ru> <87ha70kyy3.fsf@uwakimon.sk.tsukuba.ac.jp> <5323B66B.5070405@yandex.ru> <837g7vdg70.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1394935833 8244 80.91.229.3 (16 Mar 2014 02:10:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Mar 2014 02:10:33 +0000 (UTC) Cc: Eli Zaretskii , Dmitry Gutov , Stephen Turnbull , Emacs developers To: Glenn Morris Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 16 03:10:43 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 1WP0XB-0001y3-3H for ged-emacs-devel@m.gmane.org; Sun, 16 Mar 2014 03:10:41 +0100 Original-Received: from localhost ([::1]:52017 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WP0XA-000343-HZ for ged-emacs-devel@m.gmane.org; Sat, 15 Mar 2014 22:10:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59305) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WP0X5-0002z9-8z for emacs-devel@gnu.org; Sat, 15 Mar 2014 22:10:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WP0X4-00061u-55 for emacs-devel@gnu.org; Sat, 15 Mar 2014 22:10:35 -0400 Original-Received: from mail-yh0-x22f.google.com ([2607:f8b0:4002:c01::22f]:46674) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WP0Ww-0005zp-SN; Sat, 15 Mar 2014 22:10:26 -0400 Original-Received: by mail-yh0-f47.google.com with SMTP id 29so4069495yhl.6 for ; Sat, 15 Mar 2014 19:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Y5jI9IXKjV2VyPr/UhApgN/FfQD4i3TQFSO3Y2hrpJ8=; b=TxNZWnIVW+TuTo6F2xrabHYuMceNvICz6NhnIdxnpYw1mqlvT/GRgbEy6jZsI0bB00 5ujDl6cK94dbca1XsGPeaSZ6u8PPlLW4zMcOM22QHM19+yAEygsg7ce+wQMMYK2sbCfd kofgZT0nORm4bdMngU+jIn/wy2tEixQyvzyjQJRJzb2QiSDNKTqI31iUz26/VsC6XImI myr7m29QUc6wwnBx4hJu1VoqZTF8vpZYeMr4tYy0h7WvgG9J29jK4rmhWjj+AP6C4jDh IMQD14KG2/V2XtMru07AiS+BgToMv0PIEP+82ckr5u5VgmSmoNwcZWxA5Ier9m0sKV0v E00Q== X-Received: by 10.236.91.144 with SMTP id h16mr33104yhf.123.1394935826378; Sat, 15 Mar 2014 19:10:26 -0700 (PDT) Original-Received: by 10.170.163.3 with HTTP; Sat, 15 Mar 2014 19:09:46 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4002:c01::22f 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:170408 Archived-At: On Sun, Mar 16, 2014 at 2:08 AM, Glenn Morris wrote: > You can't force people to do anything, and that's not what I asked. True, though that kind of sentiment has at least been thrown around. Quoting Stephen: > All very true, but practically speaking this has to be decided at the > project level, and accompanied by a no-push-without-required-docs > policy. It's quite possible that this policy once explicitly decided > will require essentially zero enforcement (part of the problem is that > there's probably much less than 100% awareness of the less-interesting > tasks), but you need to be prepared to enforce by demanding docs, and > if necessary reverting doc-less patches. and that motivated my answer. > I just want people to try more, rather than relying on someone else to > do it. "Relying on someone else to do it" can also be interpreted as "leaving that particular work for those that are more skilled at it". > If your English is not the best, then do the best job that you can, and > ask people to proof-read the result. This is much better than doing > nothing at all. Hmm. I'm not so sure, because I don't agree with the "doing nothing at all". I mean, surely there are some metrics in which it is "much better", but these metrics are not necessarily related to efficiency, but peers' goodwill (or project satisfaction, if you will), etc. If developer A requires X hours to document something, and developers B, C or D could do it in a tenth of that time, it is really efficient for A to do it, assuming that in general A will spend these X hours in another Emacs-related task anyway? Of course, A has no right to demand B or anyone else to do it in their place; that's a given. But at the end of the day, isn't contributing to a project like this a matter of knowing how to spend your time in productive ways? I suppose a counterargument could be given against developers who only want to do "shiny new" things and leave the grunt work to others, but I do believe that's not the case in the emacs devel community: most of us do our share of grunt work (squashing bugs, fixing typos, testing, revising and commenting proposed patches, commiting code from non-committers, building snapshots, etc.). > (If you were talking about yourself, I think your > English is totally up to the task of writing Emacs docs.) Well, I'm not just talking about myself. But thanks. > To get specific: please try and document frameset.el in the lispref. I didn't even know that it had to be documented in the lisp reference. There are pretty fundamental libraries, like uniquify, which are not (uniquify is briefly described in the Emacs manual). I will be very surprised if the non-doc status of framesets has kept the freeze from unfreezing ;-) But assuming I try, where would that go? A subnode of "Frames", perhaps?