--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/9288df7b-f2e9-4106-b843-c1ff8f8a62a3%40dashjr.org.
I do think it would be best to have non-devs contribute by triaging what doesn't require devskills.
Assigning BIP numbers itself is easy enough. The hard part is evaluating if the new proposal meets the criteria - which definitely needs dev skills (mainly for technical soundness). So IMO we should move forward with more editors ASAP without waiting for a new way to coordinate the numbering (we can deal with that later/in parallel to solving the immediate need).
--
You received this message because you are subscribed to a topic in the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoindev/cuMZ77KEQAA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bitcoindev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZgWRu32FXzqqg69V%40console.
You received this message because you are subscribed to a topic in the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoindev/cuMZ77KEQAA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bitcoindev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/6806b22d-043d-4201-841a-95e17cd8d542%40mattcorallo.com.
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/9baa15e4-062d-478f-8c87-8ff19ab79989%40murch.one.
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/9a3470ba-72dd-4466-a014-d3dede648e6dn%40googlegroups.com.
Thank you for splitting off this discussion. I believe that lots of
commentators who see problems with the BIPs process fail to distinguish
between the editor being overloaded, and unclarity or disagreement about
what the editor's job is supposed to be in the first place.
In particular, I've seen some comments akin to "assigning numbers
shouldn't take that much work", while the BIP2 sections you highlight do
show that the process does involve a lot more than that. Discussion about
what the process is supposed to be should be separate from a discussion
about who will facilitate that process.
More comments inline below.
BIP2, Section "BIP workflow" says this:
"The BIP editors will not unreasonably reject a BIP. Reasons for
rejecting BIPs include duplication of effort, disregard for formatting
rules, being too unfocused or too broad, being technically unsound, not
providing proper motivation or addressing backwards compatibility, or
not in keeping with the Bitcoin philosophy. For a BIP to be accepted it
must meet certain minimum criteria. It must be a clear and complete
description of the proposed enhancement. The enhancement must represent
a net improvement. The proposed implementation, if applicable, must be
solid and must not complicate the protocol unduly."This is a lot of criteria for a simple editorial rule, hm? How could
any editor judge if an enhancement represents a net improvement without
opining on its merit? What's the Bitcoin philosophy?
Good point, this does seem to imply some value judgements. If we're open to making changes to what the criteria for a BIP are supposed to be, I think it ought to include:
By the way, Section "BIP Editor Responsibilities & Workflow" says this:
"For each new BIP that comes in an editor does the following:
- Read the BIP to check if it is ready: sound and complete. The ideas
must make technical sense, even if they don't seem likely to be
accepted.
- [...]"Note how this is is (seemingly?) in conflict with the paragraph cited
further above. What is "acceptance"? Acceptance by the editor, by the
community (whoever that is), or by anyone else?
I don't see a problem here; my interpretation is that this is exactly about excluding certain value judgements from what the editor is supposed to do: they must judge soundness and completeness, without trying to guess whether the community is likely to accept the idea. "sound and complete" is perhaps too vague as a criterion, but I'm in support of explicitly excluding guessing of acceptance.
BIP2 has other problems (a lot of which date back to BIP1):
* It recommends licensing BIPs under BSD-2 or BSD-3, which are
software licenses. It's not even clear if they're applicable toplain text. (The CC0 recommendation makes much more sense.)
No strong opinion about this, but that sounds reasonable.
* The Comments-URI thing is outdated and everyone seems to ignore it.
Comments-Summary is even weirder.
Agreed. It's unused, and sometimes misinterpreted. I think we should get rid of it.
* "Informational BIPs do not necessarily represent a Bitcoin community
consensus or recommendation". Aha, does this imply that Standards
Track BIPs need to represent a Bitcoin community consensus orrecommendation?
Indeed. I don't think BIPs should be representing community consensus or recommendations. But perhaps they can document individual pieces of evidence of acceptance; see further?
* Ever tried to write pseudocode or LaTeX in mediawiki format? It's
more than annoying, believe me.
I'd like permitting BIPs to be written in markdown.
Moreover, the entire "BIP status field" section is an attempt at
formalizing and describing the process of changing Bitcoin. That leads
to statements like these that specify when a BIP should be "Final"* "A soft-fork BIP strictly requires a clear miner majority expressed
by blockchain voting (eg, using BIP 9)." That statement is highly
controversial. The point is that it simply doesn't belong in BIP2.
* "API/RPC and application layer BIPs must be implemented by at least
two independent and compatible software applications." same here
* Peer services BIPs should be observed to be adopted by at least 1%of public listening nodes for one month.
Some forms of Status are useful I think, but they ought to reflect the author's intent, not the community's perception. E.g. "Draft", "Proposed", and "Withdrawn" make sense to me for any kind of standard. In Draft stage more substantial changes could be permitted, but would convey the idea isn't yet intended for adoption. Of course, the BIP1 status fields weren't really used, and the BIP2 status fields don't seem to be doing much better. If we assume that BIP3 status fields aren't going to be used either this is all for nought, but perhaps it's still worth trying with a significantly simplified assortment of statuses.
Things like "Active / Final" and "Rejected" relate to community acceptance, and I agree those don't belong in BIPs. Instead, could we perhaps have a field that indicates objective evidence of acceptance, such as listing which software projects have implemented/adopted it?
As far as judging consensus goes, perhaps actual consensus changes are an exception? I feel that for those, an "Accepted" status may actually make sense, because they actually require the ecosystem to have agreement about. But even then, it could be restricted to be an after-the-fact piece of evidence (whatever its activation rules are, they are met), rather than a judgement of community perception.
Regarding the "at least two independent and compatible software applications", I don't think this is a bad principle: good standards should be implementable by many, and having multiple implementations is an objective way of assessing that. I'm not sure that means being a requirement for its status, but at least an intent to have multiple implementations is a useful condition for the "Need for standardization" rule I suggest above.
The problems are similar to the Comments-Summary field whose purpose is
to represent a community judgment of the BIP. It can have these values:
* No comments yet.
* Unanimously Recommended for implementation
* Unanimously Discourage for implementation
* Mostly Recommended for implementation, with some Discouragement
* Mostly Discouraged for implementation, with some RecommendationThere's a reason why noone really uses this. Like the Status field, it
requires that someone (the editor? BIP2 doesn't specify this) makes a
judgement that looks somewhat authoritative, because it will end up inthe BIP header/metadata.
Agreed.
I think we should simply drop anything that requires an examination of
the meat of the BIP, e.g., the Status and Comments-* fields, and the
requirement to check the meat of a BIP. Instead, we should work on a
new process BIP that merely describes a simple process of publishing
BIPs, in which the editors focus on purely formal and editorial issues
(e.g., formatting, license, readability, filtering spam, ...). It's
great when they guide BIP authors by providing feedback on the
presentation of an idea, or even on the idea itself, but they shouldn't
be required to make decisions based on the technical or philosophicalmerit of a BIP
I think my view is somewhat more restrictive than yours, e.g. that BIPs ought to satisfy some scope and need for standardization criteria, but I agree that as written in BIP2 today, Editors have too many judgement calls to make.
>> >> On Friday, March 29, 2024 at 1:47:41 AM UTC+5:30 Matt Corallo wrote:
>> >>>
>> >>> Please provide justification rather than simply saying "I like Bob!".
>> >>>
>> >>> Matt
>> >>>
>> >>> On 3/28/24 12:09 PM, /dev /fd0 wrote:
>> >>> > I support Jon Atack and Roasbeef from this list.
>> >>> >
>> >>> > On Thursday, March 28, 2024 at 6:57:53 PM UTC+5:30 Murch wrote:
>> >>> >
>> >>> > I just went through the thread, previously mentioned were:
>> >>> >
>> >>> > - Kanzure
>> >>> > - Ruben Somsen
>> >>> > - Greg Tonoski
>> >>> > - Jon Atack
>> >>> > - Roasbeef
>> >>> > - Seccour
>> >>> >
>> >>> > And Matt just suggested me for the role. Hope I didn’t overlook anyone.
>> >>> >
>> >>> > On 3/27/24 19:39, John C. Vernaleo wrote:
>> >>> > > That said, I would find it helpful if someone could go through the
>> >>> > > thread and list all the people who've been proposed so people know who
>> >>> > > they should be thinking about.
>> >>> >
>> >>> > --
>> >>> > You received this message because you are subscribed to the Google Groups "Bitcoin Development
>> >>> > Mailing List" group.
>> >>> > To unsubscribe from this group and stop receiving emails from it, send an email to
>> >>> > bitcoindev+...@googlegroups.com <mailto:bitcoindev+...@googlegroups.com>.
>> >>> > To view this discussion on the web visit
>> >>> > https://groups.google.com/d/msgid/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn%40googlegroups.com?utm_medium=email&utm_source=footer>.
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.
>> > To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/f8fa1a55-644f-4cf1-b8c1-4fdef22d1869n%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4ca0-a441-aebcfc7b0bben%40googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4db8-b880-3c06ebc47cd1%40achow101.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4903-9524-dd8ef98c1c8b%40achow101.com.
On 04/20/2024 04:46 PM, Steve Lee wrote:
> Wasn't there evidence provided that Kanzure does not want this
> responsibility without being paid?
I am not aware of that, and it hasn't come up when I've talked to him
about being a BIPs editor.
> I'm confused by this process that we don't even ask the people if they
> want the responsibility? I think only Laolu has chimed in to commit to it?
Personally, I've spoken to all 5 privately and they've all confirmed to
me that they are willing to be BIPs editors. Jonatack[1] and Murch[2]
have also replied to this thread about this.
You received this message because you are subscribed to a topic in the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoindev/cuMZ77KEQAA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bitcoindev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/84bb3ca1-a18e-48c8-a934-6fcef5470a36%40achow101.com.