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 _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
