2021-09-14-bips-meeting-log

[00:00:19]  <michaelfolkson> #startmeeting
[00:00:45]  <michaelfolkson> Ok... BIP process meeting. Feel free to say hi (even if you just plan to lurk)
[00:00:50]  <harding> Hi
[00:00:52]  <Alexandre_Chery> Hi.
[00:01:07]  <michaelfolkson> I'll post some links for context
[00:01:16]  <luke-jr> hi
[00:01:29]  <prayank> hi
[00:02:14]  <michaelfolkson> This is the current BIP process https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki
[00:02:36]  <kallewoof> Hi
[00:02:36]  <michaelfolkson> Kalle has suggested a revision in the past https://github.com/bitcoin/bips/pull/1015
[00:03:11]  <michaelfolkson> And then we have a process wishlist with some ideas on it https://github.com/bitcoin/bips/wiki/BIP-Process-wishlist
[00:03:27]  <michaelfolkson> So does anyone want to start with anything in particular?
[00:03:50]  <harding> I'd like to see luke-jr removed as BIPs editor due to his previous abuse of authority.
[00:04:00]  <luke-jr> that is a lie
[00:04:12]  <luke-jr> I'd like to see harding stop spreading FUD
[00:04:18] michaelfolkson facepalms
[00:04:37]  <michaelfolkson> Ok we can have a couple of minutes on this
[00:04:53]  <harding> luke-jr: it's a truth that's self evident by anyone looking at the record of your conduct.
[00:05:00]  <michaelfolkson> harding: Why do you think it was an abuse of authority?
[00:05:01]  <luke-jr> harding: lair
[00:05:02]  <luke-jr> liar
[00:05:11]  <prayank> Don't remove anyone. Instead make this repository not look like authority with some changes in process.
[00:05:25]  <luke-jr> prayank: the process already doesn't look like authority
[00:05:47]  <prayank> The readme itself says "approval"
[00:06:04]  <michaelfolkson> harding: I get there were disagreements between a number of us. But abuse of authority is very strong for a delayed merge
[00:06:06]  <prayank> Nobody needs approval for proposing improvement
[00:06:09]  <harding> michaelfolkson: he had ample opportunity to merge a PR that met all the of the criteria defined in the existing BIPs process and instead stalled and wasted the time of dozens of highly valuable contributors.
[00:06:13]  <luke-jr> prayank: fair point
[00:06:42]  <luke-jr> harding: I treated it the same as any other PR, despite its dishonest intent
[00:07:16]  <michaelfolkson> harding: This isn't low hanging fruit at all but do you think a BIP editor should merge any activation parameters a BIP champion adds? Ignoring this specific scenario
[00:07:31]  <harding> michaelfolkson: people are given authority to merge PRs in a community project as a way of helping the community, instead he wasted the community's time (and to an excessive degree).
[00:07:49]  <luke-jr> harding: you chose to waste your time wasting my time
[00:07:55]  <luke-jr> I didn't make you do anything
[00:08:12]  <harding> michaelfolkson: yes, that's what the process says.  If it's your BIP, you control the text as long as its reasonably related to Bitcoin technology.
[00:08:21]  <michaelfolkson> harding: But answer my specific question. A BIP editor should merge whatever activation parameters BIP champions tell them to? Ignoring this scenario, thinking about the future
[00:08:32]  <luke-jr> (and while you have funding for your time, I mostly don't)
[00:08:37]  <harding> luke-jr: you chose to spend hours arguing with other people when it took you less than 15 minutes to merge the PR.
[00:09:00]  <michaelfolkson> If that is the process we should change the process. It makes no sense for a BIP champion to unilaterally decide the activation parameters
[00:09:02]  <harding> luke-jr: I have no funding for my time.  My total income from Bitcoin work over the past seven years has been less than $5,000.
[00:09:04]  <luke-jr> harding: nonsense
[00:09:22]  <luke-jr> harding: ok, my bad, but still doesn't justify your trolling
[00:09:32]  <michaelfolkson> I'd rather just not include the activation parameters in future for a soft fork BIP
[00:10:04]  <michaelfolkson> It makes no sense to me that a BIP champion can ignore the community and add whatever activation parameters they want (again ignoring this specific scenario)
[00:10:05]  <luke-jr> michaelfolkson: well, ideally it should still be documented in the BIP, just not contrary to community sentiment
[00:10:16]  <harding> luke-jr: nor does your weird opinions justify you holding up the merge of a useful PR.
[00:10:29]  <harding> luke-jr: please resign.
[00:10:52]  <luke-jr> harding: if you continue to push this lie, I am going to have to just assume you're a bad actor
[00:11:21]  <michaelfolkson> harding: We should move on soon. But do you not think luke-jr has done a good job over multiple years as BIP editor? Even if you think he made a mistake this time?
[00:11:21]  <harding> luke-jr: you already called me that during the taproot activation debate, calling me it twice has no further effect.
[00:11:38]  <luke-jr> harding: so stop being malicious
[00:12:29]  <harding> michaelfolkson: I think he's done a job, and perhaps he's done it better than I would've (I'm a terrible maintainer), but if he's unwilling to admit that he deliberately delayed the merge of a PR and that he abused his authority, I don't believe he should continue to be invested with that authority.
[00:13:43]  <michaelfolkson> harding: My personal view is that he was in a difficult spot. He didn't think Core or the BIP champions should determine the activation parameters over what he saw was community consensus
[00:13:45]  <harding> luke-jr: inisting that you support BIP authors instead of placing your will above them is not malicious.
[00:14:07]  <harding> luke-jr: do you actually think what michaelfolkson thinks you tihnk?
[00:14:49]  <harding> luke-jr: it was my understanding that you believed sipa had the right to modify his BIP.
[00:14:50]  <luke-jr> Indeed, I do think it was completely inapprorpiate to make that modification to the BIP, though that is independent of my role as BIP editor
[00:15:00]  <luke-jr> right to, yes - but it was inappropriate
[00:15:13]  <harding> Ok.
[00:15:26]  <michaelfolkson> And rushing it through when you are unsure what to do never makes sense. Especially when you are being hounded
[00:15:30]  <harding> (That's what I thought.)
[00:15:59]  <harding> michaelfolkson: taking a month to merge a PR he actually claims to have only spent 15 minutes to evaluate is not rushed.
[00:16:34]  <luke-jr> I didn't make the 15 minute claim, you did?
[00:16:44]  <luke-jr> and there were many PRs to review prior to it
[00:16:55]  <michaelfolkson> I do think both of you should tone it down though. "Liar" and "abuse of authority" seem unnecessary to me
[00:17:05]  <harding> luke-jr: you posted the time in #bitcoin-core-dev when you started to review that particular PR, and we have the time when you actually merged it.  IIRC, it was about 15 minutes.
[00:17:30]  <luke-jr> michaelfolkson: well, it is a lie, and he persists in pushing it.
[00:17:35]  <harding> michaelfolkson: I continue to insist that he abused his authority and that he should be removed as a BIPs editor.
[00:18:18]  <michaelfolkson> Well if luke-jr wants to remain a BIP editor, I think it is better if you bring that up with the mailing list harding
[00:18:26]  <harding> michaelfolkson: I already have.
[00:18:39]  <harding> But I'll continue to bring it up in every appropriate venue for years, if need be.
[00:18:57]  <michaelfolkson> It wasn't on the agenda today and we're already 20 minutes in to a meeting I asked kallewoof and others to attend
[00:19:02]  <kallewoof> personally i think luke-jr was hesitant to merge that change because in his opinion there was still a discussion to be had about the approach.
[00:19:03]  <luke-jr> harding: that's called harassment
[00:19:45]  <kallewoof> and, personally i reviewed the change and decided that it was ready to be merged. i didn't have the power TO merge, but still
[00:19:51]  <harding> luke-jr: no, using appropriate venues to call out misbehavior is not harassment.
[00:20:20]  <michaelfolkson> Ok let's move onto the agenda please.
[00:20:21]  <luke-jr> harding: there was no misbehaviour on my part, only yours and others
[00:20:26]  <luke-jr> michaelfolkson: +1
[00:20:35]  <harding> kallewoof: with respect, that's not why luke-jr said he wasn't merging at the time.
[00:20:50]  <harding> Thank you every one for your time.
[00:20:54] harding lurking now
[00:20:57]  <kallewoof> harding: yeah. just saying, if he AND i were editors back then, I would've merged.
[00:21:14] luke-jr glad we have at least a second editor to share the workload
[00:21:19]  <michaelfolkson> Cool, thanks harding. You're welcome to jump in on any future topics
[00:21:38]  <luke-jr> speaking of which, it might be nice to get a third - someone more familiar with Lightning
[00:22:36]  <michaelfolkson> Yeah t-bast is a great writer, I don't know if he'd want to do it though. Most of the devs are busy with the BOLTs
[00:22:59]  <michaelfolkson> So the process wishlist https://github.com/bitcoin/bips/wiki/BIP-Process-wishlist
[00:23:09]  <michaelfolkson> Anyone want to pick one?
[00:23:41]  <michaelfolkson> I think the "==Revisit the requirement for BIP champions to ACK spelling changes==" is low hanging fruit
[00:23:51]  <prayank> Auto rejection or any rejection makes no sense
[00:24:03]  <michaelfolkson> prayank: What are you referring to?
[00:24:09]  <prayank> One of the things mentioned in that list
[00:24:10]  <kallewoof> agreed
[00:24:16]  <luke-jr> ==Cleanup auto-Rejection==
[00:24:20]  <kallewoof> he's talking about the 'reject after 3 years'
[00:24:21]  <michaelfolkson> Oh right
[00:24:51]  <michaelfolkson> Yeah I think luke-jr was one of the ones unsure on this. Latest thoughts luke-jr?
[00:25:15]  <prayank> I think author of BIP 47 had some issues with process which are related to this discussion:
[00:25:18]  <prayank> https://github.com/bitcoin/bips/pull/790#issuecomment-515145038
[00:25:21]  <luke-jr> remind me why I was unsure? :P
[00:25:41]  <michaelfolkson> Maybe it was just a reluctance to change the BIP process at that time
[00:26:07]  <michaelfolkson> I agree with kallewoof (and prayank) on this that the 3 year rule doesn't have much upside
[00:26:15]  <luke-jr> well, a BIP 3 just for the one thing didn't make sense - but neither did revising BIP 2
[00:26:21]  <michaelfolkson> Right
[00:26:34]  <luke-jr> I can't think of any problems with having a new status in general though
[00:27:24]  <michaelfolkson> Ok so tentatively we can add this to one of the changes for the proposed BIP 3
[00:28:06]  <michaelfolkson> I'm just reminding myself of where we landed previously
[00:28:23]  <michaelfolkson> There were 2 alternative PRs that kallewoof opened
[00:29:07]  <michaelfolkson> So are we happy with BIPs being in a proposed state potentially ad infinitum?
[00:29:18]  <michaelfolkson> Should we increase the 3 years or get rid of it entirely?
[00:29:24]  <luke-jr> I think *some* separate state makes sense
[00:29:30]  <luke-jr> Stale or Inactive or such
[00:29:46]  <michaelfolkson> Ok after say 3 years?
[00:29:51]  <kallewoof> Gmax wanted a way to convey to devs out in the universe that "this thing isn't actually used"
[00:29:58]  <kallewoof> I think "inactive" is fine.
[00:30:13]  <michaelfolkson> And any activity from the BIP champion and it leaves the Inactive state?
[00:30:22]  <luke-jr> kallewoof: if it IS actually used, it should be Final :p
[00:30:49]  <kallewoof> luke-jr: there are criteria beyond it being used. like, it has to be used by multiple pieces of software, in the case of 'application', for example
[00:31:52]  <luke-jr> true
[00:32:11]  <michaelfolkson> So I think #1012 could potentially be merged into a proposed BIP 3
[00:32:43]  <michaelfolkson> OK cool. Shall we move on to another one?
[00:33:08]  <michaelfolkson> ==Revisit the requirement for BIP champions to ACK spelling changes== seems low hanging fruit
[00:33:47]  <kallewoof> Anything that does not change the meaning (semantics) of a BIP should be auto-approved by default, IMO
[00:34:02]  <kallewoof> It's just wasting time asking sipa to review a typo change
[00:34:17]  <luke-jr> with an explicit caveat that the author can revert it
[00:34:18]  <kallewoof> s/change/fix
[00:34:37]  <michaelfolkson> Yeah agreed
[00:34:49]  <luke-jr> where the line is drawn may be unclear unless we're specific tho
[00:35:01]  <kallewoof> BIP editors should be encumbered with the task of determining if a change requires a judgement call.
[00:35:08]  <michaelfolkson> Though a PR that does spelling changes across multiple BIPs should be closed imo. 
[00:35:34]  <kallewoof> Yeah. PRs should be BIP specific.
[00:35:40]  <luke-jr> kallewoof: that might put too much authority in the role; explicitness is good
[00:36:15]  <michaelfolkson> I do think there can be edge cases where it looks like a simple spelling change but ends up not being. As you've both said it can be reverted easily enough
[00:36:53]  <michaelfolkson> I doubt those edge cases will happen that often. It would mean one of you/both of you really not  understanding the wording of the BIP
[00:37:07]  <kallewoof> luke-jr: if authors can explicitly undo stuff, it should be okay i think.
[00:37:30]  <luke-jr> kallewoof: maybe, but authors shoudln't need to watch their BIPs for foreign edits either XD
[00:38:09]  <michaelfolkson> There's no time limit on the reversion. And they can be cc'd before the merge
[00:38:36]  <kallewoof> CC'ing is a good point yep. "This is a typo fix. Merging @<Author>"
[00:38:52]  <michaelfolkson> If they don't care they can ignore it
[00:39:21]  <luke-jr> michaelfolkson: true
[00:40:01]  <michaelfolkson> Next topic?
[00:40:24]  <michaelfolkson> I feel like ==Clarify author reassignment== is low hanging fruit too
[00:40:38]  <michaelfolkson> Oh maybe not
[00:40:56]  <michaelfolkson> So a BIP champion can already re-assign a BIP to another BIP champion right?
[00:41:11]  <luke-jr> yes, and a BIP editor can reassign a BIP if the champion doesn't respond
[00:41:18]  <luke-jr> but … who wants BIP 10x? :P
[00:41:40]  <michaelfolkson> This point is when the champion has disappeared and doesn't respond
[00:41:57]  <luke-jr> editors doing trivial changes may make this irrelevant
[00:42:41]  <kallewoof> If an author goes unresponsive or states a desire to not be responsible for their BIP(s) anymore, we should just make them author-less. No more changes. If someone wants to champion/change them later, we can re-assign them at that point.
[00:43:44]  <kallewoof> In that vein, author and champion should perhaps be separated.
[00:43:51]  <luke-jr> I think it was mainly an issue with trivial changes
[00:43:54]  <luke-jr> kallewoof: agree
[00:44:18]  <luke-jr> though Author perhaps is a pain to maintain - maybe should just tell people to read the git log :P
[00:44:26]  <kallewoof> Advocate may be a better word than champion but I'm not a native speaker so i coudl be off on that one.
[00:44:48]  <luke-jr> Maintainer?
[00:45:02]  <michaelfolkson> BIP 2 says champion. That's why I'm using that word :)
[00:45:14]  <luke-jr> yes, but we can change it for BIP 3 so it's clearer
[00:45:17]  <kallewoof> Maintainer could be misleading, if you are ONLY handling the BIP and not the implementations.
[00:45:41]  <kallewoof> Champion works, it just sounds like you're going to whip out a sword.
[00:45:48]  <prayank> Yes champion sounds weird. Although English is not my first language so I can be wrong.
[00:46:10]  <michaelfolkson> I think advocate is a better word, agreed
[00:46:21] luke-jr grabs a thesaurus
[00:47:02]  <luke-jr> wow, English is failing
[00:47:05]  <michaelfolkson> Author and Advocate. The same person/people unless the author doesn't want to advocate for it anymore
[00:47:23]  <kallewoof> SGTM
[00:47:39]  <michaelfolkson> The author should always be on the BIP even if they've left. They've done the original work/drafting
[00:47:45]  <luke-jr> absent a better word, ok
[00:47:46]  <kallewoof> So maybe add advocate row whenever a BIP author abandons it, and leave it implicit otherwise
[00:48:22]  <michaelfolkson> +1
[00:48:35]  <luke-jr> Organiser could work, not sure it's much better
[00:48:51]  <michaelfolkson> Nah sounds like a meeting/event
[00:49:12]  <kallewoof> luke-jr: If you tell us what you're opposed to about 'advocate' we can think together.
[00:49:31]  <luke-jr> kallewoof: well, arguably lots of people are advocates for (eg) Taproot :p
[00:49:53]  <michaelfolkson> And lots of people champion Taproot
[00:50:13]  <luke-jr> I'd suggest "editor", but that's begging for confusion XD
[00:50:16]  <michaelfolkson> It is just a defined role in the BIP process. It doesn't mean you can't advocate or champion Taproot outside the BIP process
[00:50:36]  <michaelfolkson> Definitely not editor lol
[00:51:10]  <michaelfolkson> Ok let's move on. If you dig something up from your thesaurus luke-jr later on we can consider it
[00:51:25]  <michaelfolkson> ==Drop BIP Comments==
[00:51:39]  <michaelfolkson> This seems a no brainer right? No one uses BIP comments?
[00:51:41]  <kallewoof> +-0
[00:51:50]  <luke-jr> there's a few, but they're largely ignored
[00:52:00]  <luke-jr> and certain BIP authors appear to be pissed off by them
[00:52:24]  <luke-jr> actually, along the right side of https://github.com/bitcoin/bips/wiki/BIP-Process-wishlist you can see them all
[00:52:38]  <michaelfolkson> The motivation for this is that we are concerned BIP authors have too much latitude to write rubbish in their BIPs? It is a way to register disapproval?
[00:52:50]  <luke-jr> basically
[00:53:01]  <luke-jr> I think the motivator was BIP 38
[00:53:16]  <michaelfolkson> I get the motivation then though this doesn't appear to be a good solution
[00:53:31]  <kallewoof> mailing list seems like the obvious superious answer.
[00:53:50]  <kallewoof> *superior
[00:54:04]  <luke-jr> kallewoof: but that doesn't document it for people looking at BIPs
[00:54:10]  <luke-jr> it's a one-time thing
[00:54:24]  <luke-jr> whoever is subscribed sees it, and then never again unless someone links teh archive
[00:54:26]  <kallewoof> if it doesn't change the BIP does it need to be documented?
[00:54:42]  <luke-jr> [23:29:51] <kallewoof> Gmax wanted a way to convey to devs out in the universe that "this thing isn't actually used"
[00:54:45]  <luke-jr> similar
[00:54:57]  <luke-jr> "this BIP is stupid, don't implement or expect others to do so"
[00:55:03]  <kallewoof> the whole purpose of BIPs is to have a universal truth. at least for that specific proposal.
[00:55:14]  <luke-jr> another issue is this is obviously DoSable with bogus reviews
[00:55:35]  <kallewoof> right, yeah. but if no one is reading the comments, that isn't really being conveyed very well. the 'rejected' status also exists for that reason, right?
[00:55:50]  <kallewoof> after assigning a number a BIP has already passed the 'discussed on ML' criteria.
[00:56:00]  <michaelfolkson> Could links to bitcoin-dev mailing list posts be included at the bottom of the BIP if the editors were concerned about the direction of the BIP?
[00:56:45]  <kallewoof> For controversial stuff, giving BIP editors the authority to add "See-also: <archive link>" to a BIP without author approval should be okay, I think.
[00:57:12]  <kallewoof> But that's treading into weird turf, cause right now author can change anything in their BIP for any reason, including removing aforementioned link(s).
[00:57:35]  <michaelfolkson> I don't like that personally. I think it is too much latitude. 
[00:58:10]  <luke-jr> kallewoof: a BIP can be Final and implemented by lame software, but still a bad idea
[00:58:48]  <kallewoof> I honestly don't think anyone exclusively looks at the BIPs and decides what to do with their software.
[00:58:50]  <luke-jr> kallewoof: authors can't mess with the correct status/etc
[00:59:04]  <kallewoof> luke-jr: true, sure.
[00:59:30]  <luke-jr> well, there's people like harding trying to pass "it's a BIP" off as some kind of approval/decision-making/"this is how it is"
[00:59:57]  <michaelfolkson> It isn't clear to a lot of people I think
[01:00:01]  <harding> luke-jr: citation need.
[01:00:10]  <prayank> IMO BIP repository should just do the following things: 1. Check basic format, things mentioned in BIP should not be technically incorrect etc. 2. Assign a number 3. Merge 4. Update it author or someone else wants to change something tagging everyone involved in BIP earlier
[01:00:10]  <kallewoof> lol
[01:00:21]  <michaelfolkson> That is one of the motivations for improving the process
[01:00:39]  <luke-jr> harding: that was the impression I got about you pushing me to prioritise that PR so you could reference it as some kind of final decision in DevOps
[01:00:57]  <michaelfolkson> prayank: " should not be technically incorrect" isn't always easy to judge :)
[01:01:43]  <kallewoof> 1 should be "discussed on ML", but if someone proposes something idiotic, people tend to ignore it, so there is some amount of judgement necessary. But yeah, agree.
[01:02:07]  <luke-jr> kallewoof: even if people object/oppose it on the ML, that's not grounds to reject the BIP submission
[01:02:12]  <kallewoof> Thunderous silence, as gmax put it.
[01:02:32]  <kallewoof> luke-jr: Well, BIP 2 says it should be discussed on the mailing list before being given a #.
[01:02:37]  <prayank> michaelfolkson: Right. If its controversial. Merge whatever author wants to update. Add a link to conversation that one of the things mentioned in BIP has different opinions.
[01:02:46]  <luke-jr> yeah, discussed; conclusion of said discussion doesn't matter much
[01:03:15]  <harding> luke-jr: we mention merged PRs in the BIPs repository in Optech, including BIPs and changes I don't agree with, because the goal is communication.  Knowing the decision of the BIP341 authors about activation parameters is useful communication.
[01:03:16]  <luke-jr> if the author wants to propose something everyone else hates, they can do it
[01:03:46]  <michaelfolkson> I don't want to drag the luke-jr/harding spat up again but I think harding just wanted to include a link in Optech. He understands that the current BIP process allows champions to merge in whatever activation parameters they like (not a good idea imo)
[01:04:08]  <kallewoof> Right. The point is, if the author goes in a different direction, a new alternative BIP can be proposed. It's a proposal after all.
[01:04:14]  <prayank> BIPs should not be very important. Implementations of BIPs and documentation of implementations should be important.
[01:04:17]  <luke-jr> harding: BIP authors don't decide activation parameters, though.
[01:04:17]  <harding> luke-jr: can I go back to lurking now?
[01:04:21]  <luke-jr> harding: sure
[01:04:29]  <prayank> Anyone should be able to propose things
[01:04:44]  <kallewoof> prayank: the problem is, a lot of really nonsensical stuff is being proposed
[01:04:55]  <kallewoof> if we gave everything a BIP # we would be in the 5-digit range by now
[01:05:13]  <michaelfolkson> And people (not harding but others) do look to BIPs as authoritative docs
[01:05:22]  <kallewoof> maybe that's ok. I personally like the filtering
[01:06:18]  <michaelfolkson> prayank: I think it is especially important for soft forks, consensus changes. The BIP process should be stronger on this imo
[01:06:46]  <prayank> kallewoof: I understand. And expect them considering the type of conversations I have seen in last few years on different platforms. But we can't restrict people. Let's start creating mirrors of this repository and people can follow whatever directory works for them. Ultimately proposals should not be considered as some standards being approved.
[01:06:54]  <luke-jr> how do we reduce the incorrect assumption that BIPs are authoritative?
[01:07:20]  <kallewoof> prayank: BIPs are primarily meant to coordinate software. If we make multiple versions, that's going to be chaos.
[01:07:35]  <luke-jr> add a header to every non-Final BIP?
[01:07:35]  <michaelfolkson> prayank: You are free to create mirrors. Personally I see the value in a central repository. 
[01:07:48]  <luke-jr> though even Final BIPs may be disputed
[01:07:52]  <prayank> michaelfolkson: soft forks will have a PR in Core or other implementations. That PR is more important than the BIP itself.
[01:08:00]  <michaelfolkson> The last thing I want to do is wonder which repo the Taproot BIPs are in
[01:08:14]  <michaelfolkson> Amongst thousands of possible mirrors
[01:08:45]  <michaelfolkson> prayank: Disagree. The BIP plays a role, as does the Core PR
[01:09:00]  <prayank> Convenience vs Permissionless
[01:09:19]  <kallewoof> a core dev will see it differently from a non core dev
[01:09:25]  <michaelfolkson> It isn't convenience vs permissionless. It is chaos vs clarity
[01:09:56]  <prayank> These proposals are for Bitcoin. A protocol for decentralized network.
[01:10:15]  <michaelfolkson> Core is a central repo. BIPs is a central repo.
[01:10:19]  <luke-jr> prayank: in some cases, competing BIPs may be necessary; but when not necessary, a single BIP is ideal
[01:10:46]  <michaelfolkson> [01:06:54]  <luke-jr> how do we reduce the incorrect assumption that BIPs are authoritative?
[01:12:11]  <michaelfolkson> I'm not sure. I wonder if there should be wording on soft fork BIPs, consensus change BIPs that says these are the recommended activation params from the BIP author/advocate but do not necessarily indicate that they have community consensus
[01:12:53]  <michaelfolkson> If we are going to continue with BIP authors/advocates having complete latitude to include whatever they want
[01:13:00]  <michaelfolkson> (which I don't like)
[01:13:51]  <luke-jr> michaelfolkson: the alternative creates an authority?
[01:14:06]  <michaelfolkson> Right. Or the soft fork BIPs don't have activation params in at all
[01:14:14]  <michaelfolkson> And that is included in the BIP process
[01:14:51]  <luke-jr> I guess that ties in with ==Additional number/document registries==
[01:15:19]  <luke-jr> but then people might perceive the BIP editor's judgement as authoritative
[01:15:32]  <luke-jr> which is probably worse
[01:15:42]  <michaelfolkson> This time it wasn't a massive problem as there was overwhelming community consensus for Taproot and the activation params weren't only different by MTP, block height. But for a future proposed soft fork who knows what craziness could occur
[01:15:49]  <prayank> Any thoughts on suggestions by Matt Corallo, harding, Greg Maxwell and laanwj
[01:16:16]  <michaelfolkson> *were only different by MTP. block height, BIP 8, not BIP 8
[01:16:56]  <luke-jr> prayank: ?
[01:17:02]  <prayank> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018859.html
[01:17:13]  <prayank> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018868.html
[01:17:21]  <prayank> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018869.html
[01:17:30]  <prayank> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018871.html
[01:17:45]  <michaelfolkson> I think we can include discussing these in the next meeting prayank
[01:17:53]  <michaelfolkson> We'd need time to read them
[01:17:59]  <prayank> Okay
[01:18:06]  <michaelfolkson> And we've already been 1 hour 20
[01:18:25]  <luke-jr> the first one (by Matt) just seems a rehash of harding's earlier trolling
[01:18:30]  <luke-jr> second as well
[01:18:44]  <michaelfolkson> ==Greater controls over soft fork, hard fork BIPs and activation BIPs== was always going to high hanging fruit :)
[01:18:49]  <michaelfolkson> It is difficult
[01:19:12]  <michaelfolkson> But I think at least the process wording, guidance needs to be improved 
[01:19:13]  <luke-jr> laanwj's suggestion to add a BIP editor is already done
[01:19:43]  <luke-jr> though as I suggested earlier we can do with more
[01:19:51]  <prayank> luke-jr: I know he trolls a lot. But that email had some interesting things.
[01:19:53]  <luke-jr> my understanding is that, like me, kallewoof also has limited time
[01:20:17]  <michaelfolkson> And activation BIPs should definitely be finalized before being proposed as the activation method
[01:20:39]  <michaelfolkson> Ok shall we wrap this up then? Next meeting in a couple of weeks
[01:20:49]  <kallewoof> adding more bip editors will make BIPs seem less authoritative. the more the better, even. the problem is, we don't want to add nonsensical BIPs if we can avoid it, and we do want to ensure the authors are pinged/approve of changes to their proposals.
[01:22:01]  <kallewoof> I think harding should be added as a BIP editor, for starters.
[01:22:17]  <michaelfolkson> Does he want to be one?
[01:22:18]  <luke-jr> strongly disagree on harding with his history
[01:22:24]  <harding> No thanks.  As mentioned earlier, I think I'm a terrible maintainer.
[01:22:45]  <harding> (And, yeah, there's not a lot of point while I have an outstanding disagreement with luke-jr.)
[01:23:08]  <michaelfolkson> I only think you want more BIP editors if kallewoof and luke-jr don't have time for it
[01:23:11]  <kallewoof> harding: In that case, I think you should tone down your opinions on who is an editor. Just my opinion *shrug*
[01:23:43]  <harding> kallewoof: that's fair (but I won't).
[01:24:08]  <michaelfolkson> I would say harding would be an obvious choice for a BIP editor if he wanted it
[01:25:15]  <michaelfolkson> Anything else before we wrap up?
[01:25:33]  <michaelfolkson> We didn't cover ==Document process for adding BIP editors==
[01:25:43]  <michaelfolkson> ==BIP versions==
[01:26:05]  <michaelfolkson> ==Markdown==
[01:26:14]  <michaelfolkson> But I think we can cover them next time
[01:26:34]  <michaelfolkson> It sounds like we should have enough to do a BIP 3 revision
[01:26:56]  <michaelfolkson> Next meeting is Wednesday 29th
[01:27:14]  <michaelfolkson> [01:25:15]  <michaelfolkson> Anything else before we wrap up?
[01:27:43]  <michaelfolkson> I'll take that silence as no. I'll write up a summary for the bitcoin-dev mailing list
[01:27:46]  <luke-jr> XD
[01:27:55]  <michaelfolkson> Thanks for attending everyone
[01:28:03]  <luke-jr> also someone will have to write the BIP
[01:28:05]  <prayank> Please share about next meeting on Twitter. It seems nobody read mailing list. We need more participants in such meetings.
[01:28:21]  <luke-jr> prayank: good idea
[01:28:56]  <michaelfolkson> I'm happy to help write BIP 3 (and don't need to recognized as a co-author)
[01:29:25]  <michaelfolkson> I think the authors should be kallewoof and luke-jr as the current editors
[01:29:42]  <kallewoof> i have a PR already in #1015. i assumed we would update that
[01:29:51]  <kallewoof> and add author(s) as appropriate
[01:29:53]  <michaelfolkson> kallewoof: Sounds good
[01:30:03]  <michaelfolkson> OK cool
[01:30:06]  <michaelfolkson> #endmeeting