* [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-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-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 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 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
[parent not found: <CAGLBAhdFo2pXcDfvPCTpm7ufQuG8z4mHsdoidGkhB3q5SWLj=A@mail.gmail.com>]
* 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-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 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-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 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 threadend 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