Jeff Garzik [ARCHIVE] on Nostr: š Original date posted:2013-10-21 š Original message:Added: I'm happy with ...
š
Original date posted:2013-10-21
š Original message:Added: I'm happy with gmaxwell as BIP editor as well, as he is
apparently the current BIP-number-assigner-in-chief. :)
The goal is to improve the process, hash-seal our specs, and create an
easy way for anyone with at least an email address to participate.
On Mon, Oct 21, 2013 at 10:30 AM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> This summarizes some rambling on IRC about revising the BIPS process.
>
> Right now, the BIPS process is a bit haphazard. Previously, BIPS were
> in a git repo, and the BIPS on the wiki were locked against editing.
> The BIPS editor at the time started off well, but was eventually
> M.I.A. So the BIPS "home" moved de facto to where everyone was
> reading them anyway, the wiki. They were made editable, and it became
> easier to Just Pick A Number And Write One. However, this inevitably
> became a bit disorganized. Further, there was a recent incident --
> easily reverted -- where someone hopped on the wiki and started
> arbitrarily editing an existing standard.
>
> BIPs need to move back to git, in my opinion. Standards should be
> hash-sealed against corruption. Anything less would be uncivilized,
> and un-bitcoin. However, many on IRC pointed out requiring a git pull
> request might be a burdensome process, and discourage some
> contributors. The following is a sketch of an improved process.
>
> 1) BIP Draft.
>
> Modelled after IETF drafts. Anybody may submit a BIP draft, as long
> as it meets two very loose requirements:
> * At least somewhat related to bitcoin. Note, I did not say "crypto-currency".
> * Formatted similarly to existing BIPs (i.e. markdown, or whatever the
> community prefers)
>
> BIP drafts may be submitted via git pull request, or by emailing an
> attachment to bips.editor at bitcoin.org. This mirrors the Linux kernel
> change submission process: git is preferred, but there is always a
> non-git method for folks who cannot or do not wish to use git or
> github.
>
> BIP drafts are stored in git://github.com/bitcoin/bips.git/drafts/ and
> are not automatically assigned a BIPS number.
>
> 2) Time passes. Software for BIP drafts is developed, tested,
> published, and publicly discussed in a typical open source manner.
>
> 3) If interest and use cases remain strong, a BIP number may be
> requested, and the BIP draft is moved to
> git://github.com/bitcoin/bips.git main directory.
>
> 4) If there is general consensus that the BIP should be adopted, the
> BIP status is changed to "accepted."
>
> There are no specified time limits. Sometimes consensus about a BIP
> is reached in days, sometimes 12+ months or more. It varies widely
> depending on the feature's complexity and impact.
>
> As with the IETF, it will be q
>
> --
> Jeff Garzik
> Senior Software Engineer and open source evangelist
> BitPay, Inc. https://bitpay.com/
--
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc. https://bitpay.com/
š Original message:Added: I'm happy with gmaxwell as BIP editor as well, as he is
apparently the current BIP-number-assigner-in-chief. :)
The goal is to improve the process, hash-seal our specs, and create an
easy way for anyone with at least an email address to participate.
On Mon, Oct 21, 2013 at 10:30 AM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> This summarizes some rambling on IRC about revising the BIPS process.
>
> Right now, the BIPS process is a bit haphazard. Previously, BIPS were
> in a git repo, and the BIPS on the wiki were locked against editing.
> The BIPS editor at the time started off well, but was eventually
> M.I.A. So the BIPS "home" moved de facto to where everyone was
> reading them anyway, the wiki. They were made editable, and it became
> easier to Just Pick A Number And Write One. However, this inevitably
> became a bit disorganized. Further, there was a recent incident --
> easily reverted -- where someone hopped on the wiki and started
> arbitrarily editing an existing standard.
>
> BIPs need to move back to git, in my opinion. Standards should be
> hash-sealed against corruption. Anything less would be uncivilized,
> and un-bitcoin. However, many on IRC pointed out requiring a git pull
> request might be a burdensome process, and discourage some
> contributors. The following is a sketch of an improved process.
>
> 1) BIP Draft.
>
> Modelled after IETF drafts. Anybody may submit a BIP draft, as long
> as it meets two very loose requirements:
> * At least somewhat related to bitcoin. Note, I did not say "crypto-currency".
> * Formatted similarly to existing BIPs (i.e. markdown, or whatever the
> community prefers)
>
> BIP drafts may be submitted via git pull request, or by emailing an
> attachment to bips.editor at bitcoin.org. This mirrors the Linux kernel
> change submission process: git is preferred, but there is always a
> non-git method for folks who cannot or do not wish to use git or
> github.
>
> BIP drafts are stored in git://github.com/bitcoin/bips.git/drafts/ and
> are not automatically assigned a BIPS number.
>
> 2) Time passes. Software for BIP drafts is developed, tested,
> published, and publicly discussed in a typical open source manner.
>
> 3) If interest and use cases remain strong, a BIP number may be
> requested, and the BIP draft is moved to
> git://github.com/bitcoin/bips.git main directory.
>
> 4) If there is general consensus that the BIP should be adopted, the
> BIP status is changed to "accepted."
>
> There are no specified time limits. Sometimes consensus about a BIP
> is reached in days, sometimes 12+ months or more. It varies widely
> depending on the feature's complexity and impact.
>
> As with the IETF, it will be q
>
> --
> Jeff Garzik
> Senior Software Engineer and open source evangelist
> BitPay, Inc. https://bitpay.com/
--
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc. https://bitpay.com/