From: "David A. Harding" <dave@dtrt.org>
To: Matt Corallo <lf-lists@mattcorallo.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Reminder on the Purpose of BIPs
Date: Mon, 26 Apr 2021 09:43:09 -1000 [thread overview]
Message-ID: <20210426194309.2k5exujz23vjrgwc@ganymede> (raw)
In-Reply-To: <248f871e-1b83-8c7c-678b-3ed0585a6357@mattcorallo.com>
[-- Attachment #1: Type: text/plain, Size: 3832 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-04-26 19:44 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 [this message]
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
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=20210426194309.2k5exujz23vjrgwc@ganymede \
--to=dave@dtrt.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=lf-lists@mattcorallo.com \
/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