public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: John Newbery <john@johnnewbery.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Reminder on the Purpose of BIPs
Date: Tue, 27 Apr 2021 12:33:48 +0100	[thread overview]
Message-ID: <CAFmfg2uDiEAFHom8Bh4mjr_in3dpk++j+yfgHY3+gStU1Bii5A@mail.gmail.com> (raw)
In-Reply-To: <20210426194309.2k5exujz23vjrgwc@ganymede>

[-- Attachment #1: Type: text/plain, Size: 4248 bytes --]

ACK. These seem like very reasonable next steps.

On Mon, Apr 26, 2021 at 8:43 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sun, Apr 25, 2021 at 05:31:50PM -0400, Matt Corallo via bitcoin-dev
> wrote:
> > In general, I think its time we all agree the BIP process has simply
> failed
> > and move on. Luckily its not really all that critical and proposed
> protocol
> > documents can be placed nearly anywhere with the same effect.
>
> I recommend:
>
> 1. We add additional BIP editors, starting with Kalle Alm (if there are
>    no continuing significant objections).
>
> 2. We seek Luke Dashjr's resignation as BIPs editor.
>
> 3. We begin treating protocol documents outside the BIPs repository as
>    first-class BIP documentation.
>
> The first recommendation permits continued maintenance of existing BIPs
> plus gives the additional maintainers an opportunity to rebuild the
> credibility of the repository.
>
> The second recommendation addresses the dissatisfaction of many BIP
> authors and potential authors with the current editor, which I think
> will discourage many of them from making additional significant
> contributions to the repository.  It also seems to me to be a better use
> of Luke's talents and interests for him to focus on protocol research
> and review rather than procedurally checking whether a bunch of
> documents are well formed.
>
> The third recommendation provides an escape hatch for anyone, such as
> Matt, who currently thinks the process has failed, or for anyone who
> comes to that same conclusion in the future under a different editing
> team.  My specific recommendations there are:
>
> a. Anyone writing protocol documentation in the spirit of the BIP
>    process can post their idea to this mailing list like we've always
>    done and, when they've finished collecting initial feedback, they can
>    assign themselves a unique decentralized identifier starting with
>    "bip-".  They may also define a shorter alias that they encourage
>    people to use in cases where the correct document can be inferred
>    from context.  E.g.,
>
>       bip-wuille-taproot (bip-taproot)
>       bip-towns-versionbits-min-activation-height (bip-vbmah)
>       bip-todd-harding-opt-in-replace-by-fee (bip-opt-in-rbf)
>
> b. The author then publishes the document to any place they'd like,
> although
>    they are strongly encouraged to make any document source available
>    under an open license to ensure others can create their own
>    modifications.
>
> c. Implementations of BIPs, whether original repository BIPs or
>    decentralized BIPs, link to the BIPs they implement to ensure
>    researchers and developers can find the relevant protocol
>    documentation.  E.g.,
>
> https://github.com/bitcoin/bitcoin/blob/fe5e495c31de47b0ec732b943db11fe345d874af/doc/bips.md
>
>      (It may also be advisable for implementations to mirror copies of
>      the BIPs they implement so later modifications to the document
>      don't confuse anyone.  For this reason, extremely liberal
>      licensing of BIP documents is encouraged.)
>
> d. To help maintain quality and consistency between documentation, the
>    BIP editors provide a BIP document template, guidelines similar to
>    the existing BIP2, and an easy-to-run format linter.
>
> I think this decentralized BIPs alternative also helps address some
> longstanding problems with the BIPs system: that many casual Bitcoin
> users and developers think of documents in the BIPs repo as
> authoritative and that there are some development teams (such as for LN)
> that have already abandoned the BIPs process because, in part, they want
> complete control over their own documentation.
>
> The recommendations above were developed based on conversations I had
> with a few stakeholders in the BIPs process, but I did not attempt a
> comprehensive survey and I certainly don't claim to speak for anyone
> else.  I hope the recommendations are satisfactory and I look forward to
> your feedback.
>
> Thanks,
>
> -Dave
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 5274 bytes --]

  parent reply	other threads:[~2021-04-27 11:34 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-23  2:09 [bitcoin-dev] Proposed BIP editor: Kalle Alm Luke Dashjr
2021-04-23  3:36 ` Jeremy
2021-04-23  7:49   ` John Newbery
2021-04-23  7:50 ` Pindar Wong
2021-04-23  9:11   ` Eric Martindale
2021-04-23 15:34 ` Antoine Riard
2021-04-24 10:16   ` nopara73
2021-04-25 20:29   ` [bitcoin-dev] Reminder on the Purpose of BIPs Matt Corallo
2021-04-25 21:00     ` Luke Dashjr
2021-04-25 21:14       ` Matt Corallo
2021-04-25 21:22         ` Luke Dashjr
2021-04-25 21:31           ` Matt Corallo
2021-04-26 19:43             ` David A. Harding
2021-04-26 20:04               ` Greg Maxwell
2021-04-27 19:43                 ` Melvin Carvalho
2021-04-27  9:04               ` W. J. van der Laan
2021-04-27 11:49                 ` Erik Aronesty
2021-04-27 11:33               ` John Newbery [this message]
2021-04-27 12:16       ` Jorge Timón
2021-04-26 15:02 ` [bitcoin-dev] Proposed BIP editor: Kalle Alm Sjors Provoost
2021-04-26 16:56   ` James O'Beirne
2021-04-26 18:13 ` W. J. van der Laan
2021-09-15  9:50 [bitcoin-dev] Reminder on the Purpose of BIPs Prayank

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFmfg2uDiEAFHom8Bh4mjr_in3dpk++j+yfgHY3+gStU1Bii5A@mail.gmail.com \
    --to=john@johnnewbery.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox