From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 29F8DF2F for ; Tue, 2 Feb 2016 07:56:00 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id A235D10C for ; Tue, 2 Feb 2016 07:55:59 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:61b6:56a6:b03d:28d6]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id D2DF538A9783; Tue, 2 Feb 2016 07:54:42 +0000 (UTC) X-Hashcash: 1:25:160202:dscotese@litmocracy.com::10cEq0aRglE88Oku:a35xi X-Hashcash: 1:25:160202:bitcoin-dev@rgrant.org::NahwDdMdVP+Kd0nS:aKzmR X-Hashcash: 1:25:160202:bitcoin-dev@lists.linuxfoundation.org::8rwrs7bkBE/JOjqj:ePDKK From: Luke Dashjr To: Dave Scotese , Ryan Grant Date: Tue, 2 Feb 2016 07:54:29 +0000 User-Agent: KMail/1.13.7 (Linux/4.1.13-gentoo; KDE/4.14.8; x86_64; ; ) References: <201602012253.18009.luke@dashjr.org> In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201602020754.31734.luke@dashjr.org> X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_SBL, RP_MATCHES_RCVD autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 07:56:00 -0000 On Tuesday, February 02, 2016 5:50:29 AM Dave Scotese wrote: > The section that starts "Should two software projects need to release" > addresses issues that are difficult to ascertain from what is written > there. I'll take a stab at what it means: > > Would bitcoin be better off if multiple applications provided their own > implementations of API/RPC and corresponding application layer BIPs? > > - While there is only one such application, its UI will be the obvious > standard and confusion in usability will be avoided. > - Any more than a single such application will benefit from the > coordination encouraged and aided by this BIP and BIP 123. The original question is intended to answer both: a) why only one implementation is insufficient for Final status, and b) why two is sufficient. If every application had its own BIP (how I understand your version), none of them would be standards and it wouldn't make sense to have a BIP at all - just project documentation would be sufficient. > "To avoid doubt: comments and status are unrelated metrics to judge a BIP, > and neither should be directly influencing the other." makes more sense to > me as "To avoid doubt: comments and status are intended to be unrelated > metrics. Any influence of one over the other indicates a deviation from > their intended use." This can be expanded with a simple example: "In other > words, a BIP having the status 'Rejected' is no reason not to write > additional comments about it. Likewise, overwhelming support for a BIP in > its comments section doesn't change the requirements for the 'Accepted' or > 'Active' status." Extending this to "influence" is probably too far - after all, comments may discourage implementations, which can very well result in the Status eventually becoming Rejected rather than Final. How about: "To avoid doubt: comments and status are intended to be unrelated metrics. In other words, a BIP having the status 'Rejected' is no reason to write (or not write) additional comments about it, nor would a status of 'Final' preclude comments discouraging [further] implementation. Likewise, overwhelming support for a BIP in its comments section doesn't change the requirements for the 'Final' or 'Active' status." > Since the Bitcoin Wiki can be updated with comments from other places, I > think the author of a BIP should be allowed to specify other Internet > locations for comments. So "link to a Bitcoin Wiki page" could instead be > "link to a comments page (strongly recommended to be in the Bitcoin > Wiki)". Hmm, I wonder if this could be too easily abuse to discourage comments (because the commenter does not wish to register with yet another forum), and/or censor negative comments (because the author has made his own forum specifically for the purpose). On Tuesday, February 02, 2016 6:35:07 AM you wrote: > For section "Formally defining consensus", > > Where objections were not deemed substantiated by the community, clear > reasoning must be offered. I have integrated this into the draft. > For section "BIP Comments", > > Comments should be solicited on the bitcoin-dev mailing list, and > summarized fairly in the wiki; with notice of summarization and time > for suggesting edits on the mailing list. Wiki registration and > monitoring should not be a required hurdle to participation. The intent is for the commenter to edit the wiki page himself. I have updated it to reflect this. Luke