Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2016-02-02 📝 Original message:On Tuesday, February 02, ...
📅 Original date posted:2016-02-02
📝 Original message: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
📝 Original message: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