MIME-Version: 1.0
References: <MjZEVeZ--3-2@tutanota.de>
 <CAFvNmHRt2L+D1jkVJmUsiZ8Fpeqqioygk+eZkP7+8r2p3Dx6_Q@mail.gmail.com>
 <MjZmMzE--3-2@tutanota.de>
In-Reply-To: <MjZmMzE--3-2@tutanota.de>
From: Michael Folkson <michaelfolkson@gmail.com>
Date: Tue, 14 Sep 2021 16:43:59 +0100
Message-ID: <CAFvNmHRV1sk5o9bLAxDw4qcarhG5zymrt9Oo4_emKJprtYrtMA@mail.gmail.com>
To: Prayank <prayank@tutanota.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP process meeting - Tuesday September 14th
 23:00 UTC on #bitcoin-dev Libera IRC
Precedence: list

>> I can only speak for myself here but I am not particularly concerned abo=
ut this perception of authority.

> This perception affects Bitcoin.

Personally I would rather have an optimal process that provides
clarity and helps us build better software than be sensitive to
inaccurate perceptions that hinder that ultimate goal.

> Bitcoin Core is an implementation (used by most of the nodes right now). =
BIPs are proposals for Bitcoin.

Indeed, thanks for pointing this out. I take it as a given that
everyone knows this but yeah when making such a comparison it is good
to make this clear.

> Using same organization on GitHub and such comparisons can be misleading =
for many.

I think there's an argument that BIPs could be under a different
GitHub organization but it would be pretty low on my list or
priorities. There is a clear divide between the group of Core
maintainers and the group of BIP editors and in the absence of a
reason to change that I would rather maintain the status quo.

> I don't think we need ACKs/NACKs in BIPs repository and I feel weird to b=
e a part of discussions, ACKing this pull request: https://github.com/bitco=
in/bips/pull/1104.

With BIP champions having more latitude in getting their BIP PR merged
than they would for example getting their Core PR merged I agree
ACK/NACKs on BIP PRs are less relevant. However, I still think some
BIP champions would like to have their changes reviewed especially by
subject matter experts. And if there are strong disagreements over the
changes made an alternative BIP is always an option. I don't see the
harm in having discussion with reviewers on BIP PRs and reviewers
registering an ACK/NACK as long as we are all clear on what the BIP
process is.

> Not sure any Bitcoin project needs a pull request merged in this reposito=
ry to implement a proposal.

I agree it is optional for some/many Bitcoin projects whether they are
BIPed or not. Would you be comfortable with a soft fork/consensus code
change going into Bitcoin Core without a BIP? I personally wouldn't.

We should probably leave it at that to ensure we are not spamming the
email list but hope to see you at the meeting later :)

On Tue, Sep 14, 2021 at 3:50 PM Prayank <prayank@tutanota.de> wrote:
>
> > A mailing list post is static and a BIP will go normally go through mul=
tiple edits and revisions so you do need to take advantage of the Git versi=
on control system. It gets quite unwieldy to attempt to do that via a maili=
ng list with every minor suggested edit getting sent to all subscribers.
>
> Mailing list post will have the link to BIP documentation. Post itself do=
esn't need to be updated but same link can be used to share updated informa=
tion. Example: https://gist.github.com/prayank23/95b4804777fefd015d7cc4f847=
675d7f (Image can be changed in gist when required or add new information)
>
> Mailing list post will help in reading discussions related to proposal.
>
> >Also allowing the entire global population
> (billions of people) to be able to create a directory doesn't sound
> like a good idea to me :)
>
> There is nothing to allow/disallow. That's the whole point. People are fr=
ee to save links and organize things which can be called a BIP directory.
>
> > I can only speak for myself here but I am not particularly concerned ab=
out this perception of authority.
>
> This perception affects Bitcoin.
>
> > In the same way as there are limits on the ability of Core maintainers =
to unilaterally merge in contentious code changes there are similar limits =
on the ability of BIP editors. Ultimately anyone merging a PR has to consid=
er process/consensus and concerns can (and have been in the past) be raised=
 on this mailing list or elsewhere.
>
> Bitcoin Core is an implementation (used by most of the nodes right now). =
BIPs are proposals for Bitcoin. Using same organization on GitHub and such =
comparisons can be misleading for many. I don't think we need ACKs/NACKs in=
 BIPs repository and I feel weird to be a part of discussions, ACKing this =
pull request: https://github.com/bitcoin/bips/pull/1104. Not sure any Bitco=
in project needs a pull request merged in this repository to implement a pr=
oposal.
>
> > I'm not sure where you are suggesting a bot should be.
>
> A bot similar to DrahtBot in Bitcoin Core repository.
>
> Few other developers had suggested similar thing earlier:
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018859=
.html
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018868=
.html
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018869=
.html
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018871=
.html
>
> --
> Prayank
>
> A3B1 E430 2298 178F
>
>
>
> Sep 14, 2021, 19:37 by michaelfolkson@gmail.com:
>
> Hey Prayank
>
> Thanks for the suggestions.
>
> bitcoin-dev mailing list link can be considered a BIP and saved in a BIP =
directory. Anyone can create such directories. So BIP is nothing but a prop=
osal shared on bitcoin-dev mailing list.
>
>
> A mailing list post is static and a BIP will go normally go through
> multiple edits and revisions so you do need to take advantage of the
> Git version control system. It gets quite unwieldy to attempt to do
> that via a mailing list with every minor suggested edit getting sent
> to all subscribers. Also allowing the entire global population
> (billions of people) to be able to create a directory doesn't sound
> like a good idea to me :)
>
> This will avoid the 'bitcoin/bips' repository being considered as some BI=
P authority that approves BIPs and proposals can improve Bitcoin without us=
ing the repository. Repository will only be helpful in documenting BIP corr=
ectly.
>
>
> I can only speak for myself here but I am not particularly concerned
> about this perception of authority. We need a central repo that we can
> all refer to (rather than BIPs being distributed across a large number
> of repos) and that central repo needs to managed and maintained by
> somebody (in this case the two BIP editors Kalle and Luke). In the
> same way as there are limits on the ability of Core maintainers to
> unilaterally merge in contentious code changes there are similar
> limits on the ability of BIP editors. Ultimately anyone merging a PR
> has to consider process/consensus and concerns can (and have been in
> the past) be raised on this mailing list or elsewhere.
>
> 2. Bot in `bitcoin/bips` repository that notifies about pull requests bas=
ed on different things. This will help maintainer(s) and contributors.
>
>
> I'm not sure where you are suggesting a bot should be. On IRC? There
> is a BIP merges bot on Mastodon[0] that I'm aware of and obviously you
> can subscribe to GitHub repo notification emails.
>
> 3. BIP Gallery: I tried sharing things in a different way so that newbies=
 can understand importance of BIPs in Bitcoin and relate to it: https://pra=
yank23.github.io/BIPsGallery/ however couldn't complete it with all the BIP=
s because not many people considered it helpful. There were few suggestions=
 to improve it by adding some text for each BIP and better image gallery. M=
aybe someone else can create a better project.
>
>
> This looks cool. I think we can definitely do better in encouraging
> more people to engage with the BIP process especially as the ideas
> start flowing in post Taproot activation brainstorming what should be
> in the "next soft fork" (trademark!). Some of the BIPs (e.g. the
> Taproot BIPs 340-342) are quite technically dense so someone on IRC
> suggested making greater use of informational BIPs to supplement the
> standard BIPs for new implementers or even casual readers.
>
> [0] https://x0f.org/@bipmerges
>
> On Tue, Sep 14, 2021 at 1:17 PM Prayank <prayank@tutanota.de> wrote:
>
>
> Hi Michael,
>
> Thanks for sharing the details about the meeting.
>
> Wishlist has some interesting points. I would like to suggest few things:
>
> 1.BIP process:
>
> A. Plan and document a proposal
>
> B. Open PR in https://github.com/bitcoin/bips and edit everything properl=
y
>
> C. BIP is assigned a number and merged
>
> D. Share the proposal on bitcoin dev mailing list
>
> bitcoin-dev mailing list link can be considered a BIP and saved in a BIP =
directory. Anyone can create such directories. So BIP is nothing but a prop=
osal shared on bitcoin-dev mailing list.
>
> Who implements the BIP? When is it implemented? How is it implemented? Op=
inions on proposal etc. will be different for each BIP. This will avoid the=
 'bitcoin/bips' repository being considered as some BIP authority that appr=
oves BIPs and proposals can improve Bitcoin without using the repository. R=
epository will only be helpful in documenting BIP correctly.
>
> 2. Bot in `bitcoin/bips` repository that notifies about pull requests bas=
ed on different things. This will help maintainer(s) and contributors.
>
> 3. BIP Gallery: I tried sharing things in a different way so that newbies=
 can understand importance of BIPs in Bitcoin and relate to it: https://pra=
yank23.github.io/BIPsGallery/ however couldn't complete it with all the BIP=
s because not many people considered it helpful. There were few suggestions=
 to improve it by adding some text for each BIP and better image gallery. M=
aybe someone else can create a better project.
>
>
> --
> Prayank
>
> A3B1 E430 2298 178F
>
>
>
>
> --
> Michael Folkson
> Email: michaelfolkson@gmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
>


--=20
Michael Folkson
Email: michaelfolkson@gmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3