public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Luke Dashjr <luke@dashjr.org>
To: Dave Scotese <dscotese@litmocracy.com>,
	Ryan Grant <bitcoin-dev@rgrant.org>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses
Date: Tue, 2 Feb 2016 07:54:29 +0000	[thread overview]
Message-ID: <201602020754.31734.luke@dashjr.org> (raw)
In-Reply-To: <CAGLBAhffm+1m=DAph-ac8mA9ytLpKqTT45XG1r6UFGFoUvJ+PA@mail.gmail.com>

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


  reply	other threads:[~2016-02-02  7:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-01 22:53 [bitcoin-dev] BIP Process: Status, comments, and copyright licenses Luke Dashjr
2016-02-02  5:50 ` Dave Scotese
2016-02-02  7:54   ` Luke Dashjr [this message]
2016-02-02 16:00     ` Dave Scotese
2016-02-02 15:58 ` Gavin Andresen
2016-02-02 17:38   ` Jorge Timón
2016-02-02 19:41     ` Luke Dashjr
     [not found]       ` <CAGLBAhdFo2pXcDfvPCTpm7ufQuG8z4mHsdoidGkhB3q5SWLj=A@mail.gmail.com>
2016-02-03  0:03         ` Luke Dashjr
2016-02-03  0:59           ` Jorge Timón
2016-02-02 19:08   ` Luke Dashjr
2016-03-10  0:37   ` Mustafa Al-Bassam
2016-02-04  4:15 ` Luke Dashjr
2016-02-04 17:45   ` Ryan Grant
2016-02-04 21:17     ` Luke Dashjr
2016-02-05  0:09       ` Ryan Grant
2016-02-02  6:35 Ryan Grant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201602020754.31734.luke@dashjr.org \
    --to=luke@dashjr.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=bitcoin-dev@rgrant.org \
    --cc=dscotese@litmocracy.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox