Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 87FF2C000D for ; Tue, 14 Sep 2021 14:50:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 6ADF680D93 for ; Tue, 14 Sep 2021 14:50:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=tutanota.de Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlTjrCWRcKJd for ; Tue, 14 Sep 2021 14:50:18 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) by smtp1.osuosl.org (Postfix) with ESMTPS id 9AF3380D7B for ; Tue, 14 Sep 2021 14:50:18 +0000 (UTC) Received: from w3.tutanota.de (unknown [192.168.1.164]) by w1.tutanota.de (Postfix) with ESMTP id 90BC5FBF6BA; Tue, 14 Sep 2021 14:50:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1631631016; s=s1; d=tutanota.de; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=y2ibHQ6LdZ9Ak2DscsNQpacuNDtFcxUIZYpuW4J0X/k=; b=yfYrZkNfJDB3i0c9EOWe6XSywYaiSvbEaPLled0i4t5fmCWvoQOETqdWwssxTr+m ikBQAH4yWfN5FKZHiXBQ7JpN0wSXwpVsUosADOTR0q+2S5+KuL/m4wX2Hky7Z1Ge42/ oWS2VZI57MgovtZINiPdAD5UXXCsxPpB9xVbykyWNTpKry036ZDp9QyAKK+C6NIT6kv MkS9jeD9zlo3PmJMz1Mn2uI0hhb7gfzxMeyNfd0tsBRSww9vFOwi2A7FcCuTIg4FGvM ynpMGXDviKvflwu6egAs1TNm2CtVSpLrtgI3NGEZHoEo5ynLTDHSUVuVEcprb1nAUPu 6yltQTA9/A== Date: Tue, 14 Sep 2021 16:50:16 +0200 (CEST) From: Prayank To: Michael Folkson Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_677481_1569232663.1631631016567" X-Mailman-Approved-At: Tue, 14 Sep 2021 14:57:13 +0000 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] BIP process meeting - Tuesday September 14th 23:00 UTC on #bitcoin-dev Libera IRC X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2021 14:50:20 -0000 ------=_Part_677481_1569232663.1631631016567 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > A mailing list post is static and a BIP will go normally go through multi= ple 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. Mailing list post will have the link to BIP documentation. Post itself doe= sn't need to be updated but same link can be used to share updated informat= ion. Example: https://gist.github.com/prayank23/95b4804777fefd015d7cc4f8476= 75d7f=C2=A0(Image can be changed in gist when required or add new informati= on) 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 free= 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 abou= t this perception of authority.=20 This perception affects Bitcoin.=20 > 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 o= n this mailing list or elsewhere. Bitcoin Core is an implementation (used by most of the nodes right now). BI= Ps are proposals for Bitcoin. Using same organization on GitHub and such co= mparisons can be misleading for many. I don't think we need ACKs/NACKs in B= IPs repository and I feel weird to be a part of discussions, ACKing this pu= ll request:=C2=A0https://github.com/bitcoin/bips/pull/1104. Not sure any Bi= tcoin project needs a pull request merged in this repository to implement a= proposal. >=C2=A0I'm not sure where you are suggesting a bot should be. A bot similar to DrahtBot in Bitcoin Core repository.=C2=A0 Few other developers had suggested similar thing earlier: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018859.h= tml https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018868.h= tml https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018869.h= tml https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018871.h= tml --=20 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 pro= posal 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 B= IP authority that approves BIPs and proposals can improve Bitcoin without u= sing the repository. Repository will only be helpful in documenting BIP cor= rectly. >> > > 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 ba= sed 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 newbie= s can understand importance of BIPs in Bitcoin and relate to it: https://pr= ayank23.github.io/BIPsGallery/ however couldn't complete it with all the BI= Ps because not many people considered it helpful. There were few suggestion= s to improve it by adding some text for each BIP and better image gallery. = Maybe 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 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 proper= ly >> >> 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 pro= posal shared on bitcoin-dev mailing list. >> >> Who implements the BIP? When is it implemented? How is it implemented? O= pinions on proposal etc. will be different for each BIP. This will avoid th= e 'bitcoin/bips' repository being considered as some BIP authority that app= roves BIPs and proposals can improve Bitcoin without using the repository. = Repository will only be helpful in documenting BIP correctly. >> >> 2. Bot in `bitcoin/bips` repository that notifies about pull requests ba= sed on different things. This will help maintainer(s) and contributors. >> >> 3. BIP Gallery: I tried sharing things in a different way so that newbie= s can understand importance of BIPs in Bitcoin and relate to it: https://pr= ayank23.github.io/BIPsGallery/ however couldn't complete it with all the BI= Ps because not many people considered it helpful. There were few suggestion= s to improve it by adding some text for each BIP and better image gallery. = Maybe someone else can create a better project. >> >> >> -- >> Prayank >> >> A3B1 E430 2298 178F >> > > > > --=20 > Michael Folkson > Email: michaelfolkson@gmail.com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > ------=_Part_677481_1569232663.1631631016567 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> A mailing list post is static and a BIP will go normally go throu= gh 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 subscribe= rs.

Mailing list po= st will have the link to BIP documentation. Post itself doesn't need to be = updated but same link can be used to share updated information. Example: ht= tps://gist.github.com/prayank23/95b4804777fefd015d7cc4f847675d7f (Imag= e can be changed in gist when required or add new information)

Mailing list post will help in readi= ng 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 free to save links and organize things= which can be called a BIP directory.

=
> I can only speak for myself here but I am not partic= ularly concerned about this perception of authority.

This perception affects Bitcoin.

> In the same way as the= re are limits on the ability of Core maintainers to unilaterally merge in c= ontentious code changes there are similar limits on the ability of BIP edit= ors. Ultimately anyone merging a PR has to consider process/consensus and c= oncerns can (and have been in the past) be raised on this mailing list or e= lsewhere.

Bitcoin Co= re is an implementation (used by most of the nodes right now). BIPs are pro= posals 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 reposi= tory and I feel weird to be a part of discussions, ACKing this pull request= : https://github.com/bitcoin/bips/pull/1104. Not sure any Bitcoin proj= ect needs a pull request merged in this repository to implement a proposal.=

> I'm not sure where you are sug= gesting a bot should be.

A bot similar to DrahtBot in Bitcoin Core r= epository. 

Few oth= er 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

h= ttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018869.ht= ml

https://lists.lin= uxfoundation.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 t= he
Git version control system. It gets quite unwieldy to atte= mpt to do
that via a mailing list with every minor suggested = edit getting sent
to all subscribers. Also allowing the entir= e 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 BIP authority that approves BIPs and proposals can improve Bitcoin= without using the repository. Repository will only be helpful in documenti= ng BIP correctly.

I can only speak for = myself here but I am not particularly concerned
about this pe= rception 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 main= tainers to
unilaterally merge in contentious code changes the= re are similar
limits on the ability of BIP editors. Ultimate= ly anyone merging a PR
has to consider process/consensus and = concerns can (and have been in
the past) be raised on this ma= iling list or elsewhere.
2. Bot in `bitcoin/bips` repo= sitory that notifies about pull requests based on different things. This wi= ll 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://prayank23.github.io/BIPsGallery/ however couldn't complete it wit= h all the BIPs because not many people considered it helpful. There were fe= w suggestions to improve it by adding some text for each BIP and better ima= ge gallery. Maybe someone else can create a better project.

This looks cool. I think we can definitely do better i= n encouraging
more people to engage with the BIP process espe= cially as the ideas
start flowing in post Taproot activation = brainstorming what should be
in the "next soft fork" (tradema= rk!). Some of the BIPs (e.g. the
Taproot BIPs 340-342) are qu= ite technically dense so someone on IRC
suggested making grea= ter 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 f= or sharing the details about the meeting.

Wish= list 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 properly

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 B= IP directory. Anyone can create such directories. So BIP is nothing but a p= roposal shared on bitcoin-dev mailing list.

Wh= o implements the BIP? When is it implemented? How is it implemented? Opinio= ns on proposal etc. will be different for each BIP. This will avoid the 'bi= tcoin/bips' repository being considered as some BIP authority that approves= BIPs and proposals can improve Bitcoin without using the repository. Repos= itory will only be helpful in documenting BIP correctly.

=
2. Bot in `bitcoin/bips` repository that notifies about pull req= uests based on different things. This will help maintainer(s) and contribut= ors.

3. BIP Gallery: I tried sharing things in= a different way so that newbies can understand importance of BIPs in Bitco= in and relate to it: https://prayank23.github.io/BIPsGallery/ however could= n't complete it with all the BIPs because not many people considered it hel= pful. There were few suggestions to improve it by adding some text for each= BIP and better image gallery. Maybe someone else can create a better proje= ct.


--
Prayank

A3B1 E430 2298 178F
<= br>


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

------=_Part_677481_1569232663.1631631016567--