BIP-0002: Update Rejection criteria to require there to be an actual … #1016

pull kallewoof wants to merge 1 commits into bitcoin:master from kallewoof:202010-rejection-criteria changing 1 files +1 −1
  1. kallewoof commented at 4:19 am on October 16, 2020: member

    …concern

    Right now, BIPs may be Rejected simply due to the passing of time. The intent was to close BIPs with outstanding issues that were not adequately addressed within a given amount of time. This changes the wording to reflect this criteria.

    Ping @maaku, @harding, @michaelfolkson.

    Alternative to #1012.

  2. kallewoof commented at 4:19 am on October 16, 2020: member
    Also ping @gmaxwell.
  3. kallewoof cross-referenced this on Oct 16, 2020 from issue bip-0002: allow anyone to inactivate, not reject by kallewoof
  4. harding commented at 10:26 am on October 16, 2020: contributor

    ACK. I think is preferable over #1012 as it limits status transitions to those we can all (or mostly) agree upon. It also looks to me like just a clarification to BIP2, so (IMO) it eliminates the issue about whether or not BIP2 should be materially edited—we’ve been accepting small clarifications to accepted BIPs since these documents were hosted on the wiki.

    I do continue to agree with several of @gmaxwell’s points from the previous conversation that it’s useful to communicate to readers how much community acceptance there is of a BIP—but I think that can be done using the existing BIP2 Comments-Summary field. I’ll try to make more of an effort to curate existing BIP feedback on the comments pages so that the BIPs editors can produce those summaries.

  5. michaelfolkson commented at 11:28 am on October 16, 2020: contributor
    Approach ACK too, makes sense. I am happy with either this or #1012
  6. michaelfolkson commented at 10:49 pm on November 7, 2020: contributor
    Are you happy with this @luke-jr?
  7. luke-jr commented at 4:02 am on November 8, 2020: member
    It seems kind of poorly defined, and will likely force the editor to make judgement calls :/
  8. kallewoof commented at 1:02 am on November 9, 2020: member
    It seems pretty straightforward to me. If someone, somewhere, has raised an argument or concern or similar against the proposal, and the author hasn’t responded, and 3 years have passed, it means the proposal should be rejected based on the fact the author did not find an answer in that timespan.
  9. harding commented at 1:40 pm on November 9, 2020: contributor

    @luke-jr

    It seems kind of poorly defined

    Can you suggest an alternative phrasing with better definition?

  10. luke-jr commented at 3:57 pm on November 9, 2020: member
    Maybe remove “adequately”?
  11. BIP-0002: Update Rejection criteria to require there to be an actual concern
    Right now, BIPs may be Rejected simply due to the passing of time. The intent was to close BIPs with outstanding issues that were not adequately addressed within a given amount of time. This changes the wording to reflect this criteria.
    6b65547aab
  12. kallewoof commented at 4:01 am on November 10, 2020: member
    Removed adequately.
  13. kallewoof force-pushed on Nov 10, 2020
  14. christianrolandso approved
  15. michaelfolkson commented at 9:06 am on November 16, 2020: contributor
    ACK
  16. michaelfolkson cross-referenced this on Nov 16, 2020 from issue Reject 199 (expired) by ysangkok
  17. michaelfolkson cross-referenced this on Nov 16, 2020 from issue Reject 116 (expired) by ysangkok
  18. michaelfolkson cross-referenced this on Nov 16, 2020 from issue Reject 98 (expired) by ysangkok
  19. ysangkok commented at 8:27 pm on November 16, 2020: contributor
    Given that BIPs already contains summaries of comments to BIPs, why not make rejection dependent on that? For the purpose of this PR, it seems inconsistent that BIP-0002 allows rejection when the BIP header says that there have been no comments.
  20. michaelfolkson commented at 0:09 am on November 17, 2020: contributor

    This gets resolved either by making a change to the Rejection criteria such as the one in this PR (which is deliberately minimal, ACKed by @harding with @luke-jr feedback addressed) or by stress testing the process of moving out of Rejected and back into Draft.

    If people think it is important not to change the Rejection criteria or that we should discuss for weeks/months what the change should be then we can do the latter instead.

    In that case we would need the BIP champion to provide “revisions that meaningfully address public criticism of the proposal”. This will take time (for the BIP champion and reviewers). The only motivation I can see for doing this is that “Rejected” BIPs somehow provide a defense against bad ideas being implemented in Bitcoin.

  21. ysangkok commented at 10:02 pm on November 18, 2020: contributor
    @michaelfolkson You mention that the feedback from Luke was addressed. I don’t see how. The comment was that the editor will have to make judgement calls. Obviously, the editor will always have to do that, but to me, the question is to what degree. Don’t you think that “if they have not made progress in three years” is easier to judge than “if there is outstanding criticism […] or other concerns” ?
  22. michaelfolkson commented at 10:30 pm on November 18, 2020: contributor

    Three years is very easy to judge. What isn’t easy to judge is how to “meaningfully address public criticism of the proposal” to get out of Rejected status and back to Draft status.

    If there isn’t consensus to allow a BIP to move back out of Rejected status to Draft status it stays Rejected. Maybe you think that’s a good thing. I just think it is infuriating for the BIP authors and poses very little upside.

  23. kallewoof commented at 3:23 am on November 19, 2020: member

    You mention that the feedback from Luke was addressed. I don’t see how.

    Luke was concerned over the word “adequately”. The word was removed.

  24. michaelfolkson commented at 12:44 pm on December 28, 2020: contributor

    To attempt to move this along. As I understand @ysangkok and @luke-jr are of the opinion that the “three year” rule should stay, certain BIPs that have passed the “three years” should be Rejected and the authors of those BIPs should then begin the process of attempting to get their Rejected BIPs back to Draft status. Is that a correct summary of your opinions?

    To reiterate, there will be judgement calls. They can’t be avoided. Whether it is a judgement call to Reject a BIP or a judgement call to move a Rejected BIP back to Draft there is judgement required.

  25. kallewoof commented at 12:55 pm on December 28, 2020: member

    To attempt to move this along. As I understand @ysangkok and @luke-jr are of the opinion that the “three year” rule should stay, certain BIPs that have passed the “three years” should be Rejected and the authors of those BIPs should then begin the process of attempting to get their Rejected BIPs back to Draft status. Is that a correct summary of your opinions?

    That makes no sense. The rejections were invalid to begin with. This PR is intended to address that.

  26. kallewoof commented at 12:56 pm on December 28, 2020: member
    I also don’t know what you are waiting for, @luke-jr. I’ve already RFC on the bitcoin mailing list, and since nobody has objected, and since you yourself have not raised any concerns, this is ready to be merged.
  27. michaelfolkson commented at 3:44 pm on December 28, 2020: contributor

    The rejections were invalid to begin with.

    Technically the rejections weren’t invalid at the time. The three year rule applied and hadn’t been changed. But if @luke-jr (as the BIP 2 author) wants to keep that three year rule he needs to explicitly say that he does. And then we have to proceed from there. At the moment this is just stuck in a logjam.

  28. michaelfolkson cross-referenced this on Feb 4, 2021 from issue Reject 150 (expired) by ysangkok
  29. ysangkok commented at 9:20 pm on February 5, 2021: contributor

    @michaelfolkson

    if @luke-jr (as the BIP 2 author) wants to keep that three year rule he needs to explicitly say that he does

    Why is Luke obligated to do this? Shouldn’t it be the obligation of Kalle to show consensus for the changes within this change? Luke may be a committer, but I don’t understand why this implies that he has to reject a proposal before one can infer that there is insufficient consensus for it.

    At the moment this is just stuck in a logjam.

    If this is the case, I don’t think it should mean that existing BIP-0002 rules stop applying.

  30. michaelfolkson commented at 10:52 pm on February 5, 2021: contributor
    I’m personally not prioritizing this until Taproot activation parameters are finalized. Other than to say in the absence of a decision from Luke (the BIP 2 author) this will need to be resolved via the mailing list and in discussion with the rest of the BIP author community (which is fine, seems unavoidable at this stage). I suspect the authors of BIPs will engage in that discussion more positively if they aren’t fighting to get their BIP out of Rejected status when that process has not been defined and is unclear.
  31. maaku commented at 10:59 pm on February 5, 2021: contributor

    How do you show consensus? That’s proving a negative, a lack of criticism.

    On Feb 5, 2021, at 1:20 PM, Janus Troelsen notifications@github.com wrote:

     @michaelfolkson

    if @luke-jr (as the BIP 2 author) wants to keep that three year rule he needs to explicitly say that he does

    Why is Luke obligated to do this? Shouldn’t it be the obligation of Kalle to show consensus for the changes within this change? Luke may be a committer, but I don’t understand why this implies that he has to reject a proposal before one can infer that there is insufficient consensus for it.

    At the moment this is just stuck in a logjam.

    If this is the case, I don’t think it should mean that existing BIP-0002 rules stop applying.

    — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

  32. kallewoof commented at 2:45 am on February 6, 2021: member
    I’ve already presented this on the ML and requested feedback from people, in particular criticism. Since no such feedback was given, and since several BIP authors have expressed their dissatisfaction with the current haphazard rejection-after-3-year approach, the ball is literally in @luke-jr’s hands. There are several proposals to choose from (a new BIP vs tweaking the BIP-2 wording).
  33. gmaxwell commented at 9:27 pm on April 25, 2021: contributor
    I think this proposal is problematic and #1012 is much better.
  34. kallewoof commented at 2:12 pm on April 27, 2021: member
    I think this is superseded by #1015 or #1012. The former in particular seems to be gaining momentum as general BIP process changes are being fleshed out, but either way I’m closing this one for now.
  35. kallewoof closed this on Apr 27, 2021

  36. kallewoof deleted the branch on Apr 27, 2021

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-10-30 01:10 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me