From: Dave Scotese <dscotese@litmocracy•com>
To: Luke Dashjr <luke@dashjr•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 08:00:03 -0800 [thread overview]
Message-ID: <CAGLBAhfWj6YfnDPtXg4qaD_1hQtHK26_yP7hF1pbH8XNsYta8w@mail.gmail.com> (raw)
In-Reply-To: <201602020754.31734.luke@dashjr.org>
[-- Attachment #1: Type: text/plain, Size: 4242 bytes --]
On Mon, Feb 1, 2016 at 11:54 PM, Luke Dashjr <luke@dashjr•org> wrote:
> 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."
>
Yes, that is much better. The mention of "only one is insufficient" and
"two are sufficient" in the bullets clarifies them well too.
>
> > 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).
>
BIP acceptance hinges on accessibility and discussion. Wherever discussion
happens, someone can mention the Wiki page they created to sidestep such an
unfortunate abuse. I have always been in favor of allowing people to do
stupid things simply because that helps them learn not to do them. The
result is often some (at least slight) embarrassment of the bad actor and a
lesson for everyone paying attention. The censorship of BitcoinXT
discussion had this effect and has softened the enthusiasm many had for...
let's call it: guarding against their own cognitive dissonance through
censorship and intimidation.
In fact this last item is probably what raised a flag for me when thinking
about the specification that they should "link to a Bitcoin Wiki page with
a summary tone of the comments." I have too often seen great discussions of
controversy lose a lot of valuable input because they lived in an
environment controlled by someone who let bias infect their moderation
decisions. I know that even I might do that, so encouraging others to have
access to my competitors feels right.
[-- Attachment #2: Type: text/html, Size: 5321 bytes --]
next prev parent reply other threads:[~2016-02-02 16:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-01 22:53 Luke Dashjr
2016-02-02 5:50 ` Dave Scotese
2016-02-02 7:54 ` Luke Dashjr
2016-02-02 16:00 ` Dave Scotese [this message]
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=CAGLBAhfWj6YfnDPtXg4qaD_1hQtHK26_yP7hF1pbH8XNsYta8w@mail.gmail.com \
--to=dscotese@litmocracy$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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