Delivery-date: Sun, 21 Apr 2024 12:08:43 -0700 Received: from mail-qt1-f184.google.com ([209.85.160.184]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rycYM-0001Su-2D for bitcoindev@gnusha.org; Sun, 21 Apr 2024 12:08:43 -0700 Received: by mail-qt1-f184.google.com with SMTP id d75a77b69052e-4311d908f3csf18301371cf.1 for ; Sun, 21 Apr 2024 12:08:41 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1713726515; cv=pass; d=google.com; s=arc-20160816; b=ti6qBhRvtePLLyeeUMHfVPmQ6Fej84FkehK0IQSqo0vcjaTvuCDyRG79sCEutS7kvC 8ubOClQXPabxS/Gl0xqcwXYinpBjgC0IgGCILioYcKAQN5aCrRh1f3M+JnywrKytFpgf KF+eNMiUa4A69rwO3xCD8fVAz1LUo6oT5cbzO/Jk8Z8em1aGMWxXVW7qLeMDH/5AgLfh cpGNdeWPxWuml9AfziZg9nOI+bR+7oYf6rm5qlN/hC9q/QxTtFcYJ2yBQgRlJ5/pDGFm pLtSWue2JPg/o6R84kfPDuecG2XkDtXL6b6buezAWirUgaIYPnD+1qj42RmLl9WDMviG 7y/g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:content-transfer-encoding :mime-version:feedback-id:references:in-reply-to:message-id:subject :cc:from:to:date:dkim-signature; bh=5ZSITj+CZsnMaJlfPPJN/kLM9xhJO7TxkGsa12NS3s8=; fh=BpsxEuXytlix/GKzbg5Vnh3kaZGjo16GjG1mx8mAk8w=; b=rt5aLi6jLC8vpIrO2YYYjRwLfCgGp9UKU5ebKjzmKUECtHw/T0uQ/YDykpfTyR85yP EIZGpONUmTGB8HYau8YPbbVD9c7D3+zlrvUeZUUY2NxoPzDGME926Lnzj83+SdRoIOtU 8twbCxP990PvY3ddHuCWH2qf2Vqkcsdu+Ox/ddh9emc5cRstSvg/CrZiZlfN8PluwJUp fGc/sBxK2A3Ym2CyCfLhuycScZNz8eoyfpreptTgZBGkvZWgvL1NR/rb62hWiY+LvtjT sabwm90diiDwgVYJ/UPMMcCuepe6MbPlDfxTG6pbG9EFE25P65gzXuiBJWV2S0pWZmRe AohA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@achow101.com header.s=protonmail3 header.b=i9QjrZug; spf=pass (google.com: domain of lists@achow101.com designates 185.70.40.18 as permitted sender) smtp.mailfrom=lists@achow101.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=achow101.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1713726515; x=1714331315; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:from:to:cc:subject :date:message-id:reply-to; bh=5ZSITj+CZsnMaJlfPPJN/kLM9xhJO7TxkGsa12NS3s8=; b=qoce2iLk2xMMd4VJVpeh7IUjvFFqcwQMZEs8NVfX8lPQxrreYFTKQo9SSjPdx+vczz ngMS8dUrBJ2sEX0U4wIhDDaJN9Knxp51BhTtUf+aQ3WAUPXXDB+e/c2c207P5qNR/dlC 50z/TJEPEazrQXsJ93i+2nvUUj8jz+sB+bY5T6nctziezH376FrL7wyHB9GeoxxmB/to TI63x3HJji1t32q2tmoqx9tgk4CvgRDD3MaT9vo0P2hoxpXyhSIJJVm77yZhdZAqgOg9 c00FmGpMdkLaz35jSJsPgFph/bAZXwoyGaLER83uJgIdxMtELI2BiJ/TrAPzuiG6GEg0 Dw9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713726515; x=1714331315; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender :content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:x-beenthere :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5ZSITj+CZsnMaJlfPPJN/kLM9xhJO7TxkGsa12NS3s8=; b=MJTLCIIRRxflAk4g0Q7vacZj/a8v3X6ABd/KKyXWhbbuA8IzwtwKPN0Lqf1r5UR3fe +S5+dDhTyE+V9qyJ/dtuwKG/FvrsF2u4zbTg5mtvGqMv7Ke7Dx6/nSJo9USe2kn3mWKx h8kUL+5XTGIrsYPkgdwWv1kPK5Xt0YnOMeS7LopuLJcLq3XCNzuGCSvKCFVC7zg7sx4g +sR8aY6mqGbkPsAEB+4xpuloEVPX2x4htqcLEtnyWQozbjIVNzooi46Uu/RqCnlP0yk8 MTgF6/bHgfnX5GrOxSuCqX6zJvdZsQlADOGrwiLHWfAmYgE5viWsV8OTe8szmasPcgGm mDow== X-Forwarded-Encrypted: i=2; AJvYcCWhBLNz/HcYKWvQlCxpfdJnuznfse4BytBZEBA4IzqAhD7J4Wg3khE9invllRvVF1PifkzD8J5Zmv2an74iTRFCaWfG8lA= X-Gm-Message-State: AOJu0YxR4i5U3ZZeh3zzAnxl50Bqx0RIpplytecrjOmVL6Ab4d3EE4Vx N8VR4xrZ2Fsvrv7RWQAlCYEHMMMdgFpTPJKpVK0X/qBLHt/mt2RT X-Google-Smtp-Source: AGHT+IH5P4g5mSHfF8PsYVMZD77HF7kMSTatSWFvvL96WsjhLL9Acozv4G4XNsjk9My2OHm0b3YBZQ== X-Received: by 2002:a05:6214:1d0d:b0:69b:7d34:9f6 with SMTP id e13-20020a0562141d0d00b0069b7d3409f6mr10529625qvd.5.1713726515360; Sun, 21 Apr 2024 12:08:35 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6214:2605:b0:69b:a44:bb68 with SMTP id 6a1803df08f44-6a05d4e5a87ls76452276d6.0.-pod-prod-00-us; Sun, 21 Apr 2024 12:08:34 -0700 (PDT) X-Received: by 2002:a05:6214:301e:b0:69b:6fd4:4ad4 with SMTP id ke30-20020a056214301e00b0069b6fd44ad4mr542291qvb.0.1713726514216; Sun, 21 Apr 2024 12:08:34 -0700 (PDT) Received: by 2002:a05:620a:4096:b0:790:72a8:15eb with SMTP id af79cd13be357-79072a817a1ms85a; Sun, 21 Apr 2024 11:47:14 -0700 (PDT) X-Received: by 2002:a05:600c:4691:b0:417:d4f6:1aa2 with SMTP id p17-20020a05600c469100b00417d4f61aa2mr7227372wmo.4.1713725232151; Sun, 21 Apr 2024 11:47:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1713725232; cv=none; d=google.com; s=arc-20160816; b=l0lcmuQOSlHuzHX29+yrWxlhWCgYzsG0EJ8sRbK3ThdCAqwVU+jbsnkkzIq+UfLceD 04eIxqOWFYJmYmOrWMH6H5zl+PuS9wsmXCj8SKS9/qzLUEbRd1fQ1pinuuyLxUqTO9ih 45YiRuI6fYwHn1p9o7KBm9FgDXYkfCaH/dnCQMe/+bZC6pHkdBVjmcyUsQyeuPtklVUJ IA/uY/GGTdgMNk0jqZddBzuYSsCuDmCTDMT0VZXREuEDIPNj8aeYCV6JbNwnbbgrR+iw d65MXSNPqC8f6she4B1URpVmi9e9mgrMmPn4tjEVKxfIFPRNmUggCKBPM6USOT8HXmGH auOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:feedback-id:references :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature; bh=f3VXYhbf2jI0UkEswARY2KZSAB3kyxlvvu7fTwruRig=; fh=pSOpppcm2rxHcL5T9Qkj8WNPxoKM2tLOXXz4UBOFhb4=; b=cUrRTSt6yb+SiZZlGQjNiLS8oHnS7t62d1rIrSOupo4Kd5FiEL4iILX853cJYiL9xe li7z/aa+rFwx4NHZsdMmlqCmLIM7HhcgMN5Ltx30TwHYFHSgq5/jqTciIn2TdiM5pHnX PiYx147f8IxsxIW42swHP3drGQF2gDNfkDVSXb6JUCoSmObMP+Fs8bGm4Xr0b0oLt33h Dt0rZACjEhBKPDTMHiYxa1FpwfC6IOqtmeK81n7YS1JuXt2bpM8sMaihPsCbKol4JC5D 8K8amZOhRmZeQZE4u6W2rrlVLVrF3qrAqkKLqgCr6o7dV070wGLIo8AdlUXrHHXTkFTk w4tQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@achow101.com header.s=protonmail3 header.b=i9QjrZug; spf=pass (google.com: domain of lists@achow101.com designates 185.70.40.18 as permitted sender) smtp.mailfrom=lists@achow101.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=achow101.com Received: from mail-4018.proton.ch (mail-4018.proton.ch. [185.70.40.18]) by gmr-mx.google.com with ESMTPS id ka11-20020a05600c584b00b0041816b2a39bsi375399wmb.0.2024.04.21.11.47.12 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Apr 2024 11:47:12 -0700 (PDT) Received-SPF: pass (google.com: domain of lists@achow101.com designates 185.70.40.18 as permitted sender) client-ip=185.70.40.18; Date: Sun, 21 Apr 2024 18:47:05 +0000 To: Michael Folkson From: "'Ava Chow' via Bitcoin Development Mailing List" Cc: bitcoindev@googlegroups.com Subject: Re: [bitcoindev] Re: Adding New BIP Editors Message-ID: <84bb3ca1-a18e-48c8-a934-6fcef5470a36@achow101.com> In-Reply-To: References: <2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com> <070755a0-10e9-4903-9524-dd8ef98c1c8b@achow101.com> <0d4d85e3-9fbb-4bd4-af0f-92225e699b63@achow101.com> <97a10141-8847-417a-af11-d95e7d3be064@achow101.com> <0591e62d-12da-48ac-9d19-faea473c647c@achow101.com> Feedback-ID: 53660394:user:proton X-Pm-Message-ID: 4a5f457e4411b4fdb4f188bfc7e39ded837864c3 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: lists@achow101.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@achow101.com header.s=protonmail3 header.b=i9QjrZug; spf=pass (google.com: domain of lists@achow101.com designates 185.70.40.18 as permitted sender) smtp.mailfrom=lists@achow101.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=achow101.com X-Original-From: Ava Chow Reply-To: Ava Chow Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.0 (-) On 04/21/2024 01:57 PM, Michael Folkson wrote: > So once a BIP number is allocated (or before) the BIP author can write > whatever they like on that BIP? Including false and misleading > statements? And the BIP editors have to merge it as long as it meets > formatting requirements? I did not say that they can write anything, do not put words in my=20 mouth. Modifications to a BIP are held to the same standard as when it=20 is initially proposed. This standard is largely about formatting, but=20 also about keeping BIPs as actual technical specifications. So long as=20 the BIP after those modifications meet those requirements, then BIP=20 editors should merge them. > A misleading statement like "This soft fork will definitely activate > at block X as it has been merged into implementation Y. It hasn't been > merged into Bitcoin Core yet but Bitcoin Core will merge the soft fork > after the activation" BIPs are specifications. They are not blog posts. They are not the place=20 for opining about whether or not something will activate. Such=20 statements would be off topic for a BIP and do not meet the standard for=20 merging, so no, I do not think that should be merged, and I do not think=20 any of the proposed BIP editors would merge such a PR. >=20 > This is a step change from before. If we aren't relying on *any* > judgment then there might as well be 100 BIP editors. Because the > editors aren't doing anything, each BIP author (or champion) has total > license to write whatever they like on their BIP. >=20 >> They are not arbiters of what is activated on Bitcoin. They are not gate= keepers of soft forks. >=20 > Of course not. The BIP editors do not decide what is activated on > Bitcoin. But they are gatekeepers on ensuring BIPs are high quality > and don't include false and misleading statements. Because false and > misleading statements can impact the evolution of an activation > process. >=20 > I tried. Based on your perspective all we need is one malicious BIP > author (or champion) and they'll make the entire BIP process a joke > and the BIP editors won't be able to do anything. You are being deliberately obtuse and strawmanning. I did not say that=20 the BIP editors won't be able to do anything; I did not say that that a=20 BIP author can put whatever they want once they get a BIP number. I suggest that you read the BIP process thread split from this one for=20 opinions on how to refine the BIPs process to make it clearer as to what=20 BIP editors should be merging. Frankly, I don't understand what it is your are arguing for or trying to=20 achieve. You make absurd claims, use strawman arguments, and throw out=20 whataboutisms. This all seems to me to be concern trolling, and as such,=20 I see no reason to continue responding to you. Ava >=20 > Michael >=20 >=20 >=20 > On Sun, Apr 21, 2024 at 5:39=E2=80=AFPM Ava Chow wro= te: >> >> You are misunderstanding the role of BIP editors. They are not arbiters >> of what is activated on Bitcoin. They are not gatekeepers of soft forks. >> If a BIP author proposes or agrees with a change to their BIP and those >> changes are formatted correctly, it is not the BIP editors' rights nor >> responsibilities to refuse to merge that change. As with Bitcoin Core >> maintainers, BIP editing is a largely janitorial role. >> >> Just because something is a BIP does not mean it is a good idea. Just >> because a BIP specifying a fork contains deployment parameters does not >> mean it will actually be deployed. There are several BIPs for both hard >> and soft forks that are rejected or withdrawn that have deployment >> parameters. >> >> Furthermore, for myself, I would actually prefer that contentious soft >> forks for which some people are legitimately attempting to activate have >> their deployment parameters be specified in a/the BIP. Having competing >> activation parameters in different BIPs is preferable over the >> documentation being spread around in many different places. It makes it >> much easier for implementations to inform users what they've actually >> implemented so that users can make a more informed decision. >> >> On 04/21/2024 07:43 AM, Michael Folkson wrote: >>> Ava >>> >>> Thanks for the detailed response, I appreciate the insight. >>> >>>>> I'm even more concerned about future soft fork activation attempts. >>>>> These don't necessarily need to be attempted via a Bitcoin Core merge= d >>>>> pull request hence the BIPs repo could be a key source of information >>>>> and guidance on this. >>> >>>> This concern doesn't make any sense. There are already multiple soft a= nd >>>> hard fork BIPs that are not active nor good ideas. A BIP does not need >>>> to be a good idea. >>> >>> I would hope that a contentious soft fork and activation params for >>> that contentious soft fork would not be merged into the Bitcoin Core >>> codebase and up until now it hasn't been. I would hope all the Bitcoin >>> Core maintainers understand that even if they personally think a soft >>> fork is a good idea (apparently there is nothing to stop them merging >>> it without discussing it with the other maintainers) that they >>> shouldn't independently merge it if it is contentious. >>> >>> Similarly I would hope that all BIP editors would be careful about >>> what information gets merged around soft fork activation *attempts* >>> whether that be activation details on a particular soft fork BIP or on >>> a separate activation BIP. With Taproot there were very strong >>> disagreements over activation parameters for a non-contentious soft >>> fork. It would be much messier for a contentious soft fork activation >>> attempt. I'm not sure all these new BIP editors understand that or >>> would perhaps even agree with that. For example Laolu is listed as a >>> supporter of a CTV activation attempt back in 2022 [0] which was >>> clearly contentious. That doesn't inspire me with confidence that as >>> soon as he is a BIP editor he won't start merging details on >>> contentious soft fork activation attempts in BIPs and merging that >>> soft fork in say btcd. He would need to be removed as a BIP editor if >>> he were to do something like that. >>> >>> Thanks >>> Michael >>> >>> [0]: https://utxos.org/signals/ >>> >>> >>> >>> On Sun, Apr 21, 2024 at 12:05=E2=80=AFAM Ava Chow = wrote: >>>> >>>> >>>> On 04/20/2024 06:21 PM, Michael Folkson wrote: >>>>> It is inevitable there will be a "revert war" unless they all have to >>>>> agree on merge decisions or communicate prior to merging. It is just = a >>>>> matter of time. Does for example Ordinal Numbers get a BIP number? I >>>>> suspect all the new BIP editors won't agree on that. >>>> >>>> Why do you think that a revert war is inevitable? >>>> >>>> The Bitcoin Core repo operates in a similar way - the maintainers are >>>> independent and work autonomously. The maintainers do not have to agre= e >>>> on merge decisions nor do they communicate prior to merging. If there'= s >>>> disagreement about a merge decision, we talk to each other about it li= ke >>>> adults and come to a mutually agreeable resolution. I don't think >>>> there's ever been a revert war in the history of Bitcoin. >>>> >>>> I would expect that when there is something that is likely to be >>>> controversial or is ambiguous that it should be a BIP that they would >>>> then talk to each other about it. It doesn't have to be all or nothing= - >>>> they can do most work without communicating, but when there's question= s >>>> or ambiguity, then they communicate. >>>> >>>>> Who is to blame in a "revert war" if each editor is free to merge >>>>> whatever pull request they like? The editor who merged it? Why should >>>>> they be removed as an editor for merging a pull request when they fin= d >>>>> out later a different editor disagreed with that merge decision and >>>>> wants to revert the merge? >>>> >>>> A revert war would be someone merging a PR that reverts another, then >>>> someone else (opening then) merging a PR that reverts that, and it goe= s >>>> back and forth. It would not be limited to PRs only. This would likely >>>> be super obvious too that they are controversially merging things as I >>>> would be surprised if other BIP editors didn't comment on any of those >>>> actions, besides the fact that many people do also watch the BIPs repo= . >>>> Regardless, the blame is on those who are doing the reverting, and wou= ld >>>> be both sides. >>>> >>>>> I'm even more concerned about future soft fork activation attempts. >>>>> These don't necessarily need to be attempted via a Bitcoin Core merge= d >>>>> pull request hence the BIPs repo could be a key source of information >>>>> and guidance on this. >>>> >>>> This concern doesn't make any sense. There are already multiple soft a= nd >>>> hard fork BIPs that are not active nor good ideas. A BIP does not need >>>> to be a good idea. >>>> >>>>> I've seen Wladimir is contributing again to Core. Is there a plan to >>>>> give him commit access again? >>>> >>>> It would have to be through the typical maintainer process, although I >>>> doubt that he even wants it. But that's completely orthogonal to the >>>> BIPs repo discussion. >>>> >>>>> I'd be more comfortable with him >>>>> overseeing things in the various repos under the Bitcoin Core >>>>> (/bitcoin) GitHub org as it sounds like you don't really care if the >>>>> BIPs repo degenerates into a free for all. >>>> >>>> I don't understand why you assume that. >>>> >>>> I've said this before, but if I see a revert war going on in the BIPs >>>> repo, I will remove those involved immediately and make a thread on th= e >>>> list to discuss what to do about them. But I doubt that's a scenario >>>> that will actually come to pass. >>>> >>>> Ava >>>> >>>>> >>>>> Thanks >>>>> Michael >>>>> >>>>> On Sat, Apr 20, 2024 at 10:15=E2=80=AFPM 'Ava Chow' via Bitcoin Devel= opment >>>>> Mailing List wrote: >>>>>> >>>>>> 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 hi= m >>>>>> about being a BIPs editor. >>>>>> >>>>>>> I'm confused by this process that we don't even ask the people if t= hey >>>>>>> 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. >>>>>> >>>>>> Ava >>>>>> >>>>>> [1]: >>>>>> https://gnusha.org/pi/bitcoindev/83b69000-ca1e-4a58-90b5-114cb09ac0b= bn@googlegroups.com/ >>>>>> [2]: >>>>>> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a-920b-32bd88d5e77= 8@murch.one/ >>>>>> >>>>>>> >>>>>>> On Sat, Apr 20, 2024 at 12:30=E2=80=AFPM 'Ava Chow' via Bitcoin Dev= elopment >>>>>>> Mailing List >>>>>> > wrote: >>>>>>> >>>>>>> Since we're now past the deadline of April 19th, I'd like to= inform >>>>>>> everyone of what will happen on Monday. >>>>>>> >>>>>>> There has not been any actual objections to the nominees nor= have there >>>>>>> been any suggestions on choosing a subset of them since my l= ast email. >>>>>>> As such, there is rough consensus on adding Kanzure, Murch, = Jonatack, >>>>>>> Ruben, and Roasbeef as BIP editors, and they will be added o= n Monday >>>>>>> April 22nd. >>>>>>> >>>>>>> Ava >>>>>>> >>>>>>> On 04/16/2024 01:08 PM, 'Ava Chow' via Bitcoin Development M= ailing List >>>>>>> wrote: >>>>>>> > While I don't disagree that 5 or 6 people seems like a lo= t to add at >>>>>>> > once, it's not clear to me how we should decide which sub= set of the >>>>>>> > nominees should be added. As it is now, I have only seen = an actual >>>>>>> > objection to Kanzure and Ruben from /dev/fd0, and no expl= icit >>>>>>> objections >>>>>>> > to anyone else. It seems like the vast majority of people= don't share >>>>>>> > their concerns either as both Kanzure and Ruben continue = to be >>>>>>> endorsed >>>>>>> > by many others. >>>>>>> > >>>>>>> > Looking at the endorsements each candidate has received, = the current >>>>>>> > counts are: >>>>>>> > * Kanzure - 17 for, 1 against >>>>>>> > * Murch - 13 for >>>>>>> > * Jonatack - 13 for >>>>>>> > * Ruben - 12 for, 1 against >>>>>>> > * Roasbeef - 9 for >>>>>>> > * Michael Folkson - none >>>>>>> > >>>>>>> > However, I don't want this process to become a popularity= contest and >>>>>>> > require some kind of formal voting. Rather I'd prefer tha= t this >>>>>>> process >>>>>>> > be something more like how Bitcoin Core maintainers are a= dded - by >>>>>>> > achieving rough consensus. Without any explicit objection= s to any of >>>>>>> > these candidates, I'm inclined to move forward with addin= g the 5 who >>>>>>> > have received endorsements. Having to pick "winners" from= this list >>>>>>> > seems like a quick way to stir up drama that I don't thin= k anyone >>>>>>> really >>>>>>> > wants to deal with. >>>>>>> > >>>>>>> > I do want to note that neither Kanzure, Ruben, nor Roasbe= ef have >>>>>>> posted >>>>>>> > on this list that they are willing to be BIP editors. I h= ave >>>>>>> reached out >>>>>>> > to all 3 of them privately, and received responses from K= anzure and >>>>>>> > Ruben that indicate that they probably are willing, but p= ublic >>>>>>> > confirmation from them on this list would also be nice. I= have not >>>>>>> > received a response from Roasbeef. >>>>>>> > >>>>>>> > Ava >>>>>>> > >>>>>>> > On 04/11/2024 10:22 AM, Sergi Delgado Segura wrote: >>>>>>> >> > I would prefer having more (9+?) than less folks on = this >>>>>>> task, so >>>>>>> >> personal preferences are easily ignored and overwritten = by the group >>>>>>> >> majority. >>>>>>> >> >>>>>>> >> I disagree with that, the more doesn't really the better= here. >>>>>>> Having >>>>>>> >> too many editors may result in a tragedy of the commons,= in >>>>>>> which people >>>>>>> >> just commit to the job because many others do, and they = do not >>>>>>> end up >>>>>>> >> doing as much because they expect others to do the it. T= his does not >>>>>>> >> only make the process look bad but may burnout the ones = that end up >>>>>>> >> doing the job, given their time commitment ends up being= too far >>>>>>> from >>>>>>> >> their expectations. >>>>>>> >> >>>>>>> >> I think being more moderate with the amount of people is= better, and >>>>>>> >> gives us leeway in case the workload ends up being exces= sive and >>>>>>> we need >>>>>>> >> to add more people (plus discourage people from joining = and >>>>>>> slacking off). >>>>>>> >> >>>>>>> >> I think 3 more people should be a good number to start f= rom. >>>>>>> >> I'd personally vouch for Murch, Kanzure, and Ruben based= on >>>>>>> their track >>>>>>> >> record in the space >>>>>>> >> >>>>>>> >> On Tue, Apr 2, 2024 at 4:30=E2=80=AFPM nvk >>>>>> >>>>>>> >> >> w= rote: >>>>>>> >> >>>>>>> >> +1 for >>>>>>> >> Kanzure >>>>>>> >> RubenSomsen >>>>>>> >> Seccour >>>>>>> >> Jon Atack >>>>>>> >> Roasbeef >>>>>>> >> >>>>>>> >> I would prefer having more (9+?) than less folks on this= task, so >>>>>>> >> personal preferences are easily ignored and overwritten = by the group >>>>>>> >> majority. >>>>>>> >> >>>>>>> >> BIPs were intended as a means to collect ideas, not enfo= rce ideas. >>>>>>> >> >>>>>>> >> I'd like to return to that. >>>>>>> >> >>>>>>> >> - NVK (temp gmail account) >>>>>>> >> >>>>>>> >> On Monday, April 1, 2024 at 5:16:54=E2=80=AFPM UTC-= 4 David A. >>>>>>> Harding wrote: >>>>>>> >> >>>>>>> >> On 2024-03-28 10:04, Matt Corallo wrote: >>>>>>> >> > Please provide justification rather than sim= ply >>>>>>> saying "I >>>>>>> >> like Bob!". >>>>>>> >> >>>>>>> >> Using only comments from the mailing list, the >>>>>>> following appears >>>>>>> >> to be >>>>>>> >> the candidate list along with the current suppo= rt. >>>>>>> Asterisks denote >>>>>>> >> candidates who indicated their willingness to a= ccept >>>>>>> the role. >>>>>>> >> >>>>>>> >> - Bryan "Kanzure" Bishop, recommended by Ava Ch= ow[1], Chris >>>>>>> >> Stewart[3], >>>>>>> >> Michael Folkson[6], Peter Todd[9], Matt Corallo= [10], >>>>>>> Brandon >>>>>>> >> Black[11], >>>>>>> >> Antoine Riard[12], Murch[13], Antoine Poinsot[1= 5], John >>>>>>> >> Carvalho[16] >>>>>>> >> >>>>>>> >> - Ruben Somsen, recommended by Ava Chow[1], Chr= is >>>>>>> Stewart[3], >>>>>>> >> Michael >>>>>>> >> Folkson[6], Antoine Riard[12], Murch[13], Antoi= ne >>>>>>> Poinsot[15], John >>>>>>> >> Carvalho[16] >>>>>>> >> >>>>>>> >> - Jon Atack*, recommended by Luke Dashjr[2], Ch= ris >>>>>>> Stewart[3], >>>>>>> >> /dev/fd0[5][7], >>>>>>> >> Brandon Black[11], Antoine Riard[12], Ava Chow[= 14], John >>>>>>> >> Carvalho[16] >>>>>>> >> >>>>>>> >> - Olaoluwa "Roasbeef" Osuntokun, recommended by= Chris >>>>>>> >> Stewart[3], John >>>>>>> >> C. Vernaleo[4], /dev/fd0[5][7], Keagan McClella= nd[8], >>>>>>> Antoine >>>>>>> >> Riard[12], Ava Chow[14] >>>>>>> >> >>>>>>> >> - Mark "Murch" Erhardt*, recommended by Michael >>>>>>> Folkson[6], Keagan >>>>>>> >> McClelland[8], Matt Corallo[10], Brandon Black[= 11], Antoine >>>>>>> >> Riard[12], >>>>>>> >> Ava Chow[14] >>>>>>> >> >>>>>>> >> - Michael Folkson* >>>>>>> >> >>>>>>> >> Note: Luke Dashjr proposed[17] Seccour and Greg= Tonoski for >>>>>>> >> "non-dev >>>>>>> >> triaging", Tonoski proposed himself[18] for "BI= P >>>>>>> editor", and >>>>>>> >> Antoine >>>>>>> >> Riard[12] proposed Seccour for "decentralized P= M". >>>>>>> >> >>>>>>> >> I searched the BIPs repo by commenter to see if= any of >>>>>>> the above >>>>>>> >> candidates had been especially active there, wh= ich is >>>>>>> listed >>>>>>> >> below as: >>>>>>> >> total PRs they commented on (number still open/= number >>>>>>> closed). >>>>>>> >> >>>>>>> >> - 21 (1/20) commenter:kanzure >>>>>>> >> - 3 (2/1) commenter:rubensomsen >>>>>>> >> - 15 (0/15) commenter:jonatack >>>>>>> >> - 18 (2/16) commenter:roasbeef >>>>>>> >> - 10 (6/4) commenter:Murchandamus >>>>>>> >> - 57 (6/51) commenter:michaelfolkson >>>>>>> >> >>>>>>> >> I'll also note that Osuntokun is the only membe= r of the >>>>>>> set to >>>>>>> >> have a >>>>>>> >> merged BIP that they co-authored, although I be= lieve >>>>>>> there are >>>>>>> >> far-along >>>>>>> >> draft BIPs for both Murch (terminology) and Som= sen (Silent >>>>>>> >> Payments). I >>>>>>> >> don't think this should be a requirement, but I= do think it >>>>>>> >> demonstrates >>>>>>> >> familiarity with the process. >>>>>>> >> >>>>>>> >> Speaking only for myself, I think all of the ca= ndidates >>>>>>> above with >>>>>>> >> multiple recommendations from other community >>>>>>> participants are >>>>>>> >> fully >>>>>>> >> qualified for the role, so I'll only provide a = detailed >>>>>>> >> justification >>>>>>> >> for the person who would be my first pick: Murc= h is not >>>>>>> only a >>>>>>> >> longstanding and broadly liked Bitcoin contribu= tor, but >>>>>>> (as Corallo >>>>>>> >> mentioned) he has worked on standardizing termi= nology >>>>>>> through a >>>>>>> >> draft >>>>>>> >> BIP. In addition, he provided an extremely deta= iled >>>>>>> review of >>>>>>> >> all 300 >>>>>>> >> pages of a draft of Mastering Bitcoin (3rd edit= ion) and has >>>>>>> >> reviewed >>>>>>> >> drafts of over 200 weekly Optech newsletters, i= n both cases >>>>>>> >> significantly improving the accuracy and >>>>>>> comprehensibility of the >>>>>>> >> documentation. To me, that seems very similar t= o the >>>>>>> work we'd >>>>>>> >> ask him >>>>>>> >> to perform as a BIPs editor and it's something = that >>>>>>> he's already >>>>>>> >> doing, >>>>>>> >> so I think there's an excellent fit of person t= o role. >>>>>>> >> >>>>>>> >> -Dave >>>>>>> >> >>>>>>> >> [1] >>>>>>> >> >>>>>>> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow= 101.com/ >>>>>>> > >>>>>>> >> [2] >>>>>>> >> >>>>>>> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashj= r.org/ >>>>>>> >>>>>>> > >>>>>>> >> [3] >>>>>>> >> >>>>>>> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@googl= egroups.com/ > >>>>>>> >> [4] >>>>>>> >> >>>>>>> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpu= rgatory.com/ > >>>>>>> >> [5] >>>>>>> >> >>>>>>> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@googl= egroups.com/ > >>>>>>> >> [6] >>>>>>> >> >>>>>>> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@googl= egroups.com/ > >>>>>>> >> [7] >>>>>>> >> >>>>>>> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@googl= egroups.com/ > >>>>>>> >> [8] >>>>>>> >> >>>>>>> https://gnusha.org/pi/bitcoindev/CALeFGL1-LKPWd7YRS110ut8tX= =3DwruqgLEazRA5...@mail.gmail.com/ > >>>>>>> >> [9] >>>>>>> https://gnusha.org/pi/bitcoindev/ZgePPvbf...@petertodd.org/ >>>>>>> >>>>>>> >> >>>>>>> >>>>>> > >>>>>>> >> [10] >>>>>>> >> >>>>>>> https://gnusha.org/pi/bitcoindev/f9435999-42df-46b5...@mattc= orallo.com/ > >>>>>>> >> [11] >>>>>>> https://gnusha.org/pi/bitcoindev/ZgWRu32FXzqqg69V@console/ >>>>>>> >>>>>>> >> >>>>>>> >>>>>> = > >>>>>>> >> [12] >>>>>>> >> >>>>>>> https://gnusha.org/pi/bitcoindev/CALZpt+E8DohYEJ9aO+FiF6+E..= .@mail.gmail.com/ > >>>>>>> >> [13] >>>>>>> >> >>>>>>> https://gnusha.org/pi/bitcoindev/53a0015c-b76a-441a...@murch= .one/ >>>>>>> >>>>>>> > >>>>>>> >> [14] >>>>>>> >> >>>>>>> https://gnusha.org/pi/bitcoindev/ae482890-bce3-468f...@achow= 101.com/ >>>>>>> > >>>>>>> >> [15] >>>>>>> >> >>>>>>> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5= Wof_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS= 4xojo=3D@protonmail.com/ > >>>>>>> >> [16] >>>>>>> >> >>>>>>> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@googl= egroups.com/ > >>>>>>> >> [17] >>>>>>> >> >>>>>>> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU= =3D=3DYJMvd9Qrst+...@mail.gmail.com/ > >>>>>>> >> >>>>>>> >> -- >>>>>>> >> You received this message because you are subscribe= d to the >>>>>>> Google >>>>>>> >> Groups "Bitcoin Development Mailing List" group. >>>>>>> >> To unsubscribe from this group and stop receiving e= mails >>>>>>> from it, >>>>>>> >> send an email to bitcoindev+unsubscribe@googlegroup= s.com >>>>>>> >>>>>>> >> >>>>>> >. >>>>>>> >> To view this discussion on the web visit >>>>>>> >> >>>>>>> https://groups.google.com/d/msgid/bitcoindev/7b4e2223-0b96-4= ca0-a441-aebcfc7b0bben%40googlegroups.com >. >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> -- >>>>>>> >> Sergi. >>>>>>> >> >>>>>>> >> -- >>>>>>> >> 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+unsubscribe@googlegroups.com >>>>>>> >>>>>>> >> >>>>>> >. >>>>>>> >> To view this discussion on the web visit >>>>>>> >> >>>>>>> https://groups.google.com/d/msgid/bitcoindev/CAEYHFxV_8_Jw61= tysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com >. >>>>>>> > >>>>>>> > -- >>>>>>> > You received this message because you are subscribed to t= he >>>>>>> Google Groups "Bitcoin Development Mailing List" group. >>>>>>> > To unsubscribe from this group and stop receiving emails = from it, >>>>>>> send an email to bitcoindev+unsubscribe@googlegroups.com >>>>>>> . >>>>>>> > To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/bitcoindev/fb52ccb5-9942-4= db8-b880-3c06ebc47cd1%40achow101.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 fro= m it, >>>>>>> send an email to bitcoindev+unsubscribe@googlegroups.com >>>>>>> . >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/bitcoindev/070755a0-10e9-4= 903-9524-dd8ef98c1c8b%40achow101.com . >>>>>>> >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google G= roups "Bitcoin Development Mailing List" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, se= nd an email to bitcoindev+unsubscribe@googlegroups.com. >>>>>> To view this discussion on the web visit https://groups.google.com/d= /msgid/bitcoindev/0d4d85e3-9fbb-4bd4-af0f-92225e699b63%40achow101.com. >>>>> >>>>> >>>>> >>>>> -- >>>>> Michael Folkson >>>>> Personal email: michaelfolkson@gmail.com >>>> >>> >>> >>> -- >>> Michael Folkson >>> Personal email: michaelfolkson@gmail.com >> >=20 >=20 > -- > Michael Folkson > Personal email: michaelfolkson@gmail.com --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/= bitcoindev/84bb3ca1-a18e-48c8-a934-6fcef5470a36%40achow101.com.