* [bitcoin-dev] BIP Process: Status, comments, and copyright licenses
@ 2016-02-01 22:53 Luke Dashjr
2016-02-02 5:50 ` Dave Scotese
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: Luke Dashjr @ 2016-02-01 22:53 UTC (permalink / raw)
To: Bitcoin Dev
I've completed an initial draft of a BIP that provides clarifications on the
Status field for BIPs, as well as adding the ability for public comments on
them, and expanding the list of allowable BIP licenses.
https://github.com/luke-jr/bips/blob/bip-biprevised/bip-biprevised.mediawiki
I plan to open discussion of making this BIP an Active status (along with BIP
123) a month after initial revisions have completed. Please provide any
objections now, so I can try to address them now and enable consensus to be
reached.
Thanks,
Luke
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses
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
2016-02-02 15:58 ` Gavin Andresen
2016-02-04 4:15 ` Luke Dashjr
2 siblings, 1 reply; 16+ messages in thread
From: Dave Scotese @ 2016-02-02 5:50 UTC (permalink / raw)
To: Luke Dashjr; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3037 bytes --]
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.
"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."
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)". Also, under "Will BIP comments be censored or limited to
particular participants/"experts"?" You could add:
- The author of a BIP may indicate any commenting URL they wish. The
Bitcoin Wiki is merely a recommendation, though a very strong one.
On Mon, Feb 1, 2016 at 2:53 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> I've completed an initial draft of a BIP that provides clarifications on
> the
> Status field for BIPs, as well as adding the ability for public comments on
> them, and expanding the list of allowable BIP licenses.
>
>
> https://github.com/luke-jr/bips/blob/bip-biprevised/bip-biprevised.mediawiki
>
> I plan to open discussion of making this BIP an Active status (along with
> BIP
> 123) a month after initial revisions have completed. Please provide any
> objections now, so I can try to address them now and enable consensus to be
> reached.
>
> Thanks,
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
[-- Attachment #2: Type: text/html, Size: 4083 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses
2016-02-02 5:50 ` Dave Scotese
@ 2016-02-02 7:54 ` Luke Dashjr
2016-02-02 16:00 ` Dave Scotese
0 siblings, 1 reply; 16+ messages in thread
From: Luke Dashjr @ 2016-02-02 7:54 UTC (permalink / raw)
To: Dave Scotese, Ryan Grant; +Cc: Bitcoin Dev
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses
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 15:58 ` Gavin Andresen
2016-02-02 17:38 ` Jorge Timón
` (2 more replies)
2016-02-04 4:15 ` Luke Dashjr
2 siblings, 3 replies; 16+ messages in thread
From: Gavin Andresen @ 2016-02-02 15:58 UTC (permalink / raw)
To: Luke Dashjr; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
On Mon, Feb 1, 2016 at 5:53 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> I've completed an initial draft of a BIP that provides clarifications on
> the
> Status field for BIPs, as well as adding the ability for public comments on
> them, and expanding the list of allowable BIP licenses.
>
>
> https://github.com/luke-jr/bips/blob/bip-biprevised/bip-biprevised.mediawiki
>
> I plan to open discussion of making this BIP an Active status (along with
> BIP
> 123) a month after initial revisions have completed. Please provide any
> objections now, so I can try to address them now and enable consensus to be
> reached.
>
I like the more concrete definitions of the various statuses.
I don't like the definition of "consensus". I think the definition
described gives too much centralized control to whoever controls the
mailing list and the wiki.
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 1691 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses
2016-02-02 7:54 ` Luke Dashjr
@ 2016-02-02 16:00 ` Dave Scotese
0 siblings, 0 replies; 16+ messages in thread
From: Dave Scotese @ 2016-02-02 16:00 UTC (permalink / raw)
To: Luke Dashjr; +Cc: Bitcoin Dev
[-- 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 --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses
2016-02-02 15:58 ` Gavin Andresen
@ 2016-02-02 17:38 ` Jorge Timón
2016-02-02 19:41 ` Luke Dashjr
2016-02-02 19:08 ` Luke Dashjr
2016-03-10 0:37 ` Mustafa Al-Bassam
2 siblings, 1 reply; 16+ messages in thread
From: Jorge Timón @ 2016-02-02 17:38 UTC (permalink / raw)
To: Gavin Andresen; +Cc: Bitcoin Dev
In the section https://github.com/luke-jr/bips/blob/bip-biprevised/bip-biprevised.mediawiki#formally-defining-consensus
Can we please find another term for the "consensus" here (which is
often confused with "consensus rules", "consensus code" etc)?
In BIP99 I used the term "uncontroversial", but I'm happy to change it
to something else if that helps us moving away from consistently using
the same term for two related but very different concepts.
"nearly universal acceptance", "ecosystem-harmonious"...seriously,
almost anything would be better than keep overloading "consensus"...
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses
2016-02-02 15:58 ` Gavin Andresen
2016-02-02 17:38 ` Jorge Timón
@ 2016-02-02 19:08 ` Luke Dashjr
2016-03-10 0:37 ` Mustafa Al-Bassam
2 siblings, 0 replies; 16+ messages in thread
From: Luke Dashjr @ 2016-02-02 19:08 UTC (permalink / raw)
To: Gavin Andresen; +Cc: Bitcoin Dev
On Tuesday, February 02, 2016 3:58:21 PM Gavin Andresen wrote:
> I don't like the definition of "consensus". I think the definition
> described gives too much centralized control to whoever controls the
> mailing list and the wiki.
How can I improve this? Inevitably, every medium of communications will be
controlled by someone (even if unmoderated, it becomes effectively controlled
by trolls who spam it with garbage).
I think it's important to note that this is also only for updating the status
of BIPs, and is not in any way relevant to such proposals *actually* being
accepted. So if the BIP process were to breakdown on this or any other point,
it isn't somehow controlling the actual reality. To explicitly clarify this
point, I have added to the end of the section:
"These criteria are considered objective ways to observe the de facto
adoption of the BIP, and are not to be used as reasons to oppose or
reject a BIP. Should a BIP become actually and unambiguously adopted
despite not meeting the criteria outlined here, it should still be
updated to Final status."
Does that help?
Thanks,
Luke
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses
2016-02-02 17:38 ` Jorge Timón
@ 2016-02-02 19:41 ` Luke Dashjr
[not found] ` <CAGLBAhdFo2pXcDfvPCTpm7ufQuG8z4mHsdoidGkhB3q5SWLj=A@mail.gmail.com>
0 siblings, 1 reply; 16+ messages in thread
From: Luke Dashjr @ 2016-02-02 19:41 UTC (permalink / raw)
To: Jorge Timón; +Cc: Bitcoin Dev
On Tuesday, February 02, 2016 5:38:59 PM Jorge Timón wrote:
> In the section
> https://github.com/luke-jr/bips/blob/bip-biprevised/bip-biprevised.mediawi
> ki#formally-defining-consensus
>
> Can we please find another term for the "consensus" here (which is
> often confused with "consensus rules", "consensus code" etc)?
> In BIP99 I used the term "uncontroversial", but I'm happy to change it
> to something else if that helps us moving away from consistently using
> the same term for two related but very different concepts.
> "nearly universal acceptance", "ecosystem-harmonious"...seriously,
> almost anything would be better than keep overloading "consensus"...
"Uncontroversial" doesn't really express the correct idea.
There has been a lot of confusion over "consensus rules/code" anyway, so while
we're on the subject of terminology, I would suggest we change *that* use of
"consensus" instead to clear up the confusion. It would probably work quite
well to rename it to "concord rules/code", and leave "consensus" for
describing the actual process by which humans agree on changes to the concord.
Anyone else have any thoughts on this subject?
Luke
(Note Core currently has "consensus" only 249 times, most of which are simply
identifier names, so it would be trivial to make this change.)
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses
[not found] ` <CAGLBAhdFo2pXcDfvPCTpm7ufQuG8z4mHsdoidGkhB3q5SWLj=A@mail.gmail.com>
@ 2016-02-03 0:03 ` Luke Dashjr
2016-02-03 0:59 ` Jorge Timón
0 siblings, 1 reply; 16+ messages in thread
From: Luke Dashjr @ 2016-02-03 0:03 UTC (permalink / raw)
To: Dave Scotese; +Cc: Bitcoin Dev
On Tuesday, February 02, 2016 11:28:40 PM Dave Scotese wrote:
> How about "defining" (rules, code, etc.) Such code and rules define what
> bitcoin is. It does require consensus and it ends up being a concord, but
> all that can come after the fact (just as it did after bitcoin was first
> released to the public).
The difficulty is that this BIP needs to refer to three different context of
consensus:
1. Consensus (stated) among developers for changes in the BIP Process.
2. Economic consensus (potential and stated) to veto a soft-fork by an
intended "firing" of the set of miners if they choose to enforce it.
3. (Actual) consensus in economic adoption of changed rules, to determine the
success of a hard-fork (after the fact).
4. The set of rules currently established as (defining) Bitcoin, enforced by
an (actual) consensus of economically-relevant nodes.
Context 3 can be disambiguated with "adoption consensus", and context 4 with
"consensus rules" and/or "consensus protocol", but I don't see a clear
solution that covers all four contexts, and even sharing the word "consensus"
for them may be confusing.
In addition, usage of the word "consensus" for context 4 has proven confusing
to users. For example, recently users misinterpreted the "Consensus" label
used in context 4 as implying that the idea itself had in fact achieved
consensus among some group of decision-makers (similar to context 1, but not
necessarily the group being "developers").
I don't know a good way to make this completely clear, so suggestions are more
than welcome.
Luke
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses
2016-02-03 0:03 ` Luke Dashjr
@ 2016-02-03 0:59 ` Jorge Timón
0 siblings, 0 replies; 16+ messages in thread
From: Jorge Timón @ 2016-02-03 0:59 UTC (permalink / raw)
To: Luke Dashjr; +Cc: Bitcoin Dev
It is true that are many levels of consensus and that term itself is
not incorrect for any of the meanings.
Maybe we should try to start distinguishing between different types of
"consensus".
In BIP99 the only concepts that are needed are "consensus rules" and
"adoption consensus" (aka "community consensus", "full node runners
consenusus", "monetary users consenusus", "economic
super-ultra-majority", not sure if any of them or all of them, that's
still a placeholder in bip99 for
<everything_thats_needed_for_an_uncontroversial_hardfork_apart_from_the_hardfork_new_rules_being_uncontroversial>
[ie safe deployment requirements for an uncontroversial hardfork, just
like we have for uncontroversial softforks]).
Whatever term and defintion we chose for this concept, it has to be
neutral to whether the consensus rule changes are can be deployed as a
softfork or only as a hardfork [although we have had many
hardfork-to-softfork re-designs in the past and I agree that there
will be more, some people including @petertodd suspect that SF=HF, but
haven't been able to prove it yet], or otherwise we're implicitly
giving miners a power of unilaterally changing some consensus rules
that they don't have, for users can't never be denied from the right
to validate whatever rules they chose, just like an old radio receiver
machine owner cannot be forced to listen any channel in particular.
The "consensus rules" are in some sense the id of a theoretical
communication channel, and should not be confused with a real-life
process for how users should coordinate to "upgrade" to a new channel
(which is what BIP99 is about) or how we can objectively know whether
a proposed changed has had "adoption consensus" or not, which is what
this BIP is about.
But yeah, suggestions totally welcomed for a replacement for "adoption
consensus".
On Tue, Feb 2, 2016 at 8:41 PM, Luke Dashjr <luke@dashjr•org> wrote:
> (Note Core currently has "consensus" only 249 times, most of which are simply
> identifier names, so it would be trivial to make this change.)
I'm afraid this would be horribly expensive in development hours for
not good enough reason and I must nack.
On Wed, Feb 3, 2016 at 1:03 AM, Luke Dashjr <luke@dashjr•org> wrote:
> On Tuesday, February 02, 2016 11:28:40 PM Dave Scotese wrote:
>> How about "defining" (rules, code, etc.) Such code and rules define what
>> bitcoin is. It does require consensus and it ends up being a concord, but
>> all that can come after the fact (just as it did after bitcoin was first
>> released to the public).
>
> The difficulty is that this BIP needs to refer to three different context of
> consensus:
>
> 1. Consensus (stated) among developers for changes in the BIP Process.
> 2. Economic consensus (potential and stated) to veto a soft-fork by an
> intended "firing" of the set of miners if they choose to enforce it.
> 3. (Actual) consensus in economic adoption of changed rules, to determine the
> success of a hard-fork (after the fact).
> 4. The set of rules currently established as (defining) Bitcoin, enforced by
> an (actual) consensus of economically-relevant nodes.
>
> Context 3 can be disambiguated with "adoption consensus", and context 4 with
> "consensus rules" and/or "consensus protocol", but I don't see a clear
> solution that covers all four contexts, and even sharing the word "consensus"
> for them may be confusing.
>
> In addition, usage of the word "consensus" for context 4 has proven confusing
> to users. For example, recently users misinterpreted the "Consensus" label
> used in context 4 as implying that the idea itself had in fact achieved
> consensus among some group of decision-makers (similar to context 1, but not
> necessarily the group being "developers").
>
> I don't know a good way to make this completely clear, so suggestions are more
> than welcome.
>
> Luke
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses
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 15:58 ` Gavin Andresen
@ 2016-02-04 4:15 ` Luke Dashjr
2016-02-04 17:45 ` Ryan Grant
2 siblings, 1 reply; 16+ messages in thread
From: Luke Dashjr @ 2016-02-04 4:15 UTC (permalink / raw)
To: Bitcoin Dev
On Monday, February 01, 2016 10:53:16 PM Luke Dashjr via bitcoin-dev wrote:
> I've completed an initial draft of a BIP that provides clarifications on
> the Status field for BIPs, as well as adding the ability for public
> comments on them, and expanding the list of allowable BIP licenses.
This has moved to:
https://github.com/luke-jr/bips/blob/bip-biprevised/bip-0002.mediawiki
Various changes have been made based on initial input.
Further review and re-review is of course welcome.
Luke
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses
2016-02-04 4:15 ` Luke Dashjr
@ 2016-02-04 17:45 ` Ryan Grant
2016-02-04 21:17 ` Luke Dashjr
0 siblings, 1 reply; 16+ messages in thread
From: Ryan Grant @ 2016-02-04 17:45 UTC (permalink / raw)
To: Luke Dashjr; +Cc: Bitcoin Dev
On Thu, Feb 4, 2016 at 12:15 AM, Luke Dashjr via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Various changes have been made based on initial input.
> Further review and re-review is of course welcome.
These recent edits definitely guide us towards less hard feelings when
comments are offered, without excessive policy structure.
[BIP 2:]
> A process BIP may change status from Draft to Active when it
> achieves rough consensus on the mailing list.
Is this mix of wiki and mailing list intentional? If so, the wiki
talk page is meant to be a self-curated permanent record of support
and dissent, but second-order reply commentary might fall either on
the wiki or the mailing list?
Mediawiki offers watchlists on a polling model, and there is some
email support [1], but it would be nice of a BIP author to at least
gather new/edited comment titles and report them to bitcoin-dev once a
week, during review. Someone has to stare at the diffs.
[1] https://www.mediawiki.org/wiki/Manual:Page_change_notification
BIP 2 should ask that all current and future forums that BIP authors
might choose for review have indisputable records of moderation and
user edits.
Is dump.bitcoin.it a sufficient public record of contentious
moderation or user cross-comment editing? It seems like as long as
the wiki as a whole is verifiable, it would suffice.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses
2016-02-04 17:45 ` Ryan Grant
@ 2016-02-04 21:17 ` Luke Dashjr
2016-02-05 0:09 ` Ryan Grant
0 siblings, 1 reply; 16+ messages in thread
From: Luke Dashjr @ 2016-02-04 21:17 UTC (permalink / raw)
To: Ryan Grant; +Cc: Bitcoin Dev
On Thursday, February 04, 2016 5:45:38 PM Ryan Grant wrote:
> [BIP 2:]
> > A process BIP may change status from Draft to Active when it
> > achieves rough consensus on the mailing list.
>
> Is this mix of wiki and mailing list intentional? If so, the wiki
> talk page is meant to be a self-curated permanent record of support
> and dissent, but second-order reply commentary might fall either on
> the wiki or the mailing list?
The wiki page is meant to be a place to leave comments recommending or
discouraging adoption of a completed BIP, after discussion is over. For
example, many people seem to think BIP 38 is a good idea simply because it is
a Final BIP, whereas in general we would want to discourage using it since it
cannot really be used safely.
All review itself ought to remain on the ML.
> BIP 2 should ask that all current and future forums that BIP authors
> might choose for review have indisputable records of moderation and
> user edits.
Is this necessary considering the author-chosen forum may only be *in addition
to* the Bitcoin Wiki?
> Is dump.bitcoin.it a sufficient public record of contentious
> moderation or user cross-comment editing? It seems like as long as
> the wiki as a whole is verifiable, it would suffice.
It should be everything except accounts/passwords.
Luke
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses
2016-02-04 21:17 ` Luke Dashjr
@ 2016-02-05 0:09 ` Ryan Grant
0 siblings, 0 replies; 16+ messages in thread
From: Ryan Grant @ 2016-02-05 0:09 UTC (permalink / raw)
To: Luke Dashjr; +Cc: Bitcoin Dev
On Thu, Feb 4, 2016 at 5:17 PM, Luke Dashjr <luke@dashjr•org> wrote:
> All review itself ought to remain on the ML.
> the author-chosen forum may only be *in addition
> to* the Bitcoin Wiki?
Ahh, much better. Thank you.
FWIW, this is the phrase that confused me:
[BIP 2:] If a BIP is not yet completed, reviewers should [...]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses
2016-02-02 15:58 ` Gavin Andresen
2016-02-02 17:38 ` Jorge Timón
2016-02-02 19:08 ` Luke Dashjr
@ 2016-03-10 0:37 ` Mustafa Al-Bassam
2 siblings, 0 replies; 16+ messages in thread
From: Mustafa Al-Bassam @ 2016-03-10 0:37 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1811 bytes --]
It would be nice to decouple the venue, but even BIP 1 gives that
control to whoever controls the mailing list: "Following a discussion,
the proposal should be sent to the bitcoin-dev list and the BIP editor
with the draft BIP." (BIP 1)
A neater way to do it might be to replace references to the mailing list
with "public discussion medium" where "medium" can be defined as
something like any discussion forum frequented by the wider development
community, like the pull requests section of the BIP repo, conferences, etc.
On 02/02/16 15:58, Gavin Andresen via bitcoin-dev wrote:
> On Mon, Feb 1, 2016 at 5:53 PM, Luke Dashjr via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org
> <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>
> I've completed an initial draft of a BIP that provides
> clarifications on the
> Status field for BIPs, as well as adding the ability for public
> comments on
> them, and expanding the list of allowable BIP licenses.
>
> https://github.com/luke-jr/bips/blob/bip-biprevised/bip-biprevised.mediawiki
>
> I plan to open discussion of making this BIP an Active status
> (along with BIP
> 123) a month after initial revisions have completed. Please
> provide any
> objections now, so I can try to address them now and enable
> consensus to be
> reached.
>
>
>
> I like the more concrete definitions of the various statuses.
>
> I don't like the definition of "consensus". I think the definition
> described gives too much centralized control to whoever controls the
> mailing list and the wiki.
>
> --
> --
> Gavin Andresen
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 3986 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [bitcoin-dev] BIP Process: Status, comments, and copyright licenses
@ 2016-02-02 6:35 Ryan Grant
0 siblings, 0 replies; 16+ messages in thread
From: Ryan Grant @ 2016-02-02 6:35 UTC (permalink / raw)
To: Luke Dashjr, Bitcoin Dev
On Mon, Feb 1, 2016 at 6:53 PM, Luke Dashjr via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Please provide any
> objections now, so I can try to address them now and enable consensus to be
> reached.
For section "Formally defining consensus",
Where objections were not deemed substantiated by the community, clear
reasoning must be offered.
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2016-03-10 0:45 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox