From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 21 Apr 2024 10:59:09 -0700 Received: from mail-qv1-f62.google.com ([209.85.219.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rybT1-0000mJ-Mp for bitcoindev@gnusha.org; Sun, 21 Apr 2024 10:59:09 -0700 Received: by mail-qv1-f62.google.com with SMTP id 6a1803df08f44-69b123bfbd9sf55609716d6.1 for ; Sun, 21 Apr 2024 10:59:07 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1713722341; cv=pass; d=google.com; s=arc-20160816; b=0M/QMYvfmIj9lDxeRPHdNYILjlLUbzeh+6RoP8KAg+DHC2HolFZWmN+rPKBR1yVB+n T06+hA3j9yTRKpoWq8DaQ7q9EP+RCuXdd6XgRh5FG4aYf4AyEtQ376YETMilV5Ffy/Qj xOAUlypCXv1TyZsbAdXlX5buCzQvmFpxYb8abaI4l9Ri5Cu+r15k9nhWkv031z6Cvkk3 MsvQ8RygLyh58JGkPK6AxT2brKrg6sgk0GWTJR70d+iXM55C3afnn4d11LnCt/d4ttZ3 SYjeNUsohYT5NcY1q4k6XiwOEn6tK8YXE37AxE4RFnDEsdRgs09VJqgE0oC9TnON8iCz gNQQ== 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:content-transfer-encoding:cc:to :subject:message-id:date:from:in-reply-to:references:mime-version :sender:dkim-signature:dkim-signature; bh=NWssHQ2+dQIdJI8H37qB6RT/KrF8AmpRAOjQh2q4jGc=; fh=va6bkBLogM91PePAQ7xk6nEfb9Zf/okMJBO6GevxfWI=; b=LTBLVCKSySqaMeU445f02/1fVdZP1urDk8QIrRAwqAWGb4Bkvj9tX5ox+wXj6dT40a zGjQkL0+FKIM4UrJzRJs7+jj00SfLHihq/YM/UhmawItkk/XcXxr4OjuYzkaHZgEdPwc 4+8DeSHpcWS9kIbRF/tsSce1J4XsRJ2zAgZc/sP+4afz4jkrC4JP/8sMEDEbj60LLO5I pTn+VrapIrnEwf9NdG2mCb0FiKECtroiWKM6+NI5W87OHnNThtIZQG0u1rHnIk1fa39B Qz2SzCx93jnbQuFCL+zIThaqV3/74gBhHJ72FpEFKt/4LXUmkjY7fZlQBANy3qFo5nvu A6OA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="E6Hl5JK/"; spf=pass (google.com: domain of michaelfolkson@gmail.com designates 2a00:1450:4864:20::42b as permitted sender) smtp.mailfrom=michaelfolkson@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1713722341; x=1714327141; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version:sender :from:to:cc:subject:date:message-id:reply-to; bh=NWssHQ2+dQIdJI8H37qB6RT/KrF8AmpRAOjQh2q4jGc=; b=vwnndlwAsreuFtz6IPxwnjn7i8aYeWKvdiTo1NuZ2yWYXxkwIV2MTCwOqT2FUeRKUm ahf721MJd3KqvpKjIviB6JROEgBjQZuvamXgKooK4iI0rLZ4JFyJf/m9p66UswdTT154 3tWyWOjrCRwONgd7CUmWhrI5MPppvg3rXEuQXLZGOFvYps0d9whLv+asvhFb9DTltRWU g5yXQCJ7WK9zNR/9ngiuRxgg8xkAzzyMLzXyeee5f0jrhFvA56dds1cGWqEZ4qStfocF 2OBYKZmo+bLtinamSKHCkvPcvGsJE8ytZX3n/Z17PZne0k2cSRwZ4A9IuC7EeHQGicnR iwow== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713722341; x=1714327141; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version:from:to:cc :subject:date:message-id:reply-to; bh=NWssHQ2+dQIdJI8H37qB6RT/KrF8AmpRAOjQh2q4jGc=; b=OHJsVuwyBUFAdGd+H7L1G9sS2UQ5lLGCCj8j13uXo3/co8GjwOe4k+N8VwiwrSME9q YQvxTOCoba45hTCCHOMuMNfdnjItVeAHGrB4sD20QF6hs9yflHXhAZLVru1mxvqMLKLh kEGhaBFWx+WCj2jF8t1891RnI9RbB+WMCFfSH4XKjDHbXVaO3MDHNS7gF5EeFlY7uAfM Tp4tVDFLxuanuthLR3qACqWbmEiXoymIKiJJ8Skkk+GKeydVKG1KrgxQhtxG55++8CWi 9qAz0ZJT1+l6EzYQrDPLUsOCLp0HKH7UPaDZ0u5gUM9LybEkqYBXWpWpmw7c59U500Fn 9fVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713722341; x=1714327141; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to; bh=NWssHQ2+dQIdJI8H37qB6RT/KrF8AmpRAOjQh2q4jGc=; b=gssUYRFtGRO+hIEVPzxx4TJDOvvCdxuxnL2OPZP2iUJEjdj/RH6OKG1CfLaJFehuVg 2R68r31hq0f26fZ0espc7rqqhBn5ZT584cvo/HVfbpi84/g/dQvifn72CQD/ZQeoupkl 6fYGs9JON0gONZqr7290F1p6FkmQEUlh2IpZArRM+7CFbdXZtAbgMU81OZf8lUZYeN5B gPMhvcVhjiZwUYyRGTHvrsQCv+L5nSdCOMPovMFLONXO9n6Fy3Y7dmPt1aXs3jd0ncqe OkvOl94kTfmfztUb6NQxSvop8oAxbSAZy60ryYqe0QaQmduizuPXm2CQGgPllNju0TDi R9rg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUz0u74Fdy2CN7EgUnzpEgc9eko/tDE8Kgdb9WvHCap05fQnpJ3pnUhQ2Exz/zsNAhEy1clMdazYNGueZmjTW+zon+8Bj0= X-Gm-Message-State: AOJu0YzkG1Dz+eY5jwJF2RmVP3v5BhivABoQZD7opizVAg9GPPMvfh5c pu5uTEhzidwGWGAJz/MMwBTQupMWuC2aBbRBmNDl7fYba9mt2U1A X-Google-Smtp-Source: AGHT+IH5eJQe1wDjYmmEifaVSDjAQXG3TO/vAewhbtSiIZdP5j83OdCsTIK9JaNj8VbmTeORf3mFxQ== X-Received: by 2002:ad4:4a12:0:b0:69b:373c:b9c with SMTP id m18-20020ad44a12000000b0069b373c0b9cmr7712600qvz.18.1713722340993; Sun, 21 Apr 2024 10:59:00 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6214:1d02:b0:699:1eb:ece9 with SMTP id 6a1803df08f44-6a05d7ea182ls73601226d6.2.-pod-prod-00-us; Sun, 21 Apr 2024 10:59:00 -0700 (PDT) X-Received: by 2002:ad4:5b8d:0:b0:6a0:424a:ab0a with SMTP id 13-20020ad45b8d000000b006a0424aab0amr447492qvp.2.1713722339980; Sun, 21 Apr 2024 10:58:59 -0700 (PDT) Received: by 2002:a05:620a:190e:b0:78f:622:a7d8 with SMTP id af79cd13be357-78f08ff52ebms85a; Sun, 21 Apr 2024 10:57:55 -0700 (PDT) X-Received: by 2002:a2e:be8c:0:b0:2da:ceb9:d8a9 with SMTP id a12-20020a2ebe8c000000b002daceb9d8a9mr5251662ljr.45.1713722273025; Sun, 21 Apr 2024 10:57:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1713722273; cv=none; d=google.com; s=arc-20160816; b=AMWZzpA9jFVt4K5YyGLHZrrGlPLVXTvptLIXqGY04h5gt87hV1ohfRJW+YS8y4cqoi UzzEIqv2iD1rD1IE7qnhjMYtUJNTp7jPRE/1WdfDXfGhKNOR6eS1skc7tqdeAJfZzVU1 L12E2M2930kfMnMu3bSHyhgyDi7N6jkoPQJJRte5sWxdpC7U5+TcOZEAxVSENDhzn3Zv tsmRkm5JmfDaS+ZlDyYRYQu7a9/xo0Swy/eUmJx8ouaV4OLbFvtqTqD73EWQOrk2EoLf GuOS4+k6LVmXuGLKWYeiaKC/hPbPluRF82XA0luSzwb327TSblCWiQsjR0IJHfwK+iYK rtWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=Qp5RfjJPG5CcDOvoKXN+u77JlOGdo7wWFAYKiim7mFE=; fh=FaZol9Uk6gnK+uGtcSFJW2nlQY6QrNwlPUIRM6Aafbo=; b=OM5XEImM9vl3F1pcbV7r3R7qLKnTVqoxgaQpI3u+b/hmyIa8fQnTUBlb2eJFtvaWeW zyRD65GBTtl+a2bHTweWVk5xyjB1iFZWdiAFJbgteGIsNzO30EhfzIMIBw3K0kIzYmGt VjC4IRdlhYc4mX4FPVRil16P3TZuqPT9/A0759sWd+cJuo+Cii22ysAeFmx+nZrP7KdQ iiBlTiUWe0o0KUkf6pJOF6V8XShgLOptXdowUqIoJLE90QhHtR6OcC/YSng4dnKkj75N hIQ8zxEZc7hYPMpIg03Tl98FuibccjF4MEe2t3xd3UCSs8wPxk25WOxNiVupp3rY4HyI th4w==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="E6Hl5JK/"; spf=pass (google.com: domain of michaelfolkson@gmail.com designates 2a00:1450:4864:20::42b as permitted sender) smtp.mailfrom=michaelfolkson@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com. [2a00:1450:4864:20::42b]) by gmr-mx.google.com with ESMTPS id b18-20020a2e8952000000b002dd5ea1636esi53159ljk.3.2024.04.21.10.57.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 21 Apr 2024 10:57:53 -0700 (PDT) Received-SPF: pass (google.com: domain of michaelfolkson@gmail.com designates 2a00:1450:4864:20::42b as permitted sender) client-ip=2a00:1450:4864:20::42b; Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-34665dd7744so2673360f8f.1 for ; Sun, 21 Apr 2024 10:57:52 -0700 (PDT) X-Received: by 2002:adf:e743:0:b0:346:afab:9702 with SMTP id c3-20020adfe743000000b00346afab9702mr5168268wrn.13.1713722271818; Sun, 21 Apr 2024 10:57:51 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <0591e62d-12da-48ac-9d19-faea473c647c@achow101.com> From: Michael Folkson Date: Sun, 21 Apr 2024 18:57:39 +0100 Message-ID: Subject: Re: [bitcoindev] Re: Adding New BIP Editors To: Ava Chow Cc: bitcoindev@googlegroups.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: michaelfolkson@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b="E6Hl5JK/"; spf=pass (google.com: domain of michaelfolkson@gmail.com designates 2a00:1450:4864:20::42b as permitted sender) smtp.mailfrom=michaelfolkson@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com 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: -0.5 (/) > 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. 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? 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" 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. > They are not arbiters of what is activated on Bitcoin. They are not gatek= eepers of soft forks. 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. 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. Michael On Sun, Apr 21, 2024 at 5:39=E2=80=AFPM Ava Chow wrote= : > > 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 la= st email. > >>>>> As such, there is rough consensus on adding Kanzure, Murch, J= onatack, > >>>>> Ruben, and Roasbeef as BIP editors, and they will be added on= Monday > >>>>> April 22nd. > >>>>> > >>>>> Ava > >>>>> > >>>>> On 04/16/2024 01:08 PM, 'Ava Chow' via Bitcoin Development Ma= iling List > >>>>> wrote: > >>>>> > While I don't disagree that 5 or 6 people seems like a lot= to add at > >>>>> > once, it's not clear to me how we should decide which subs= et of the > >>>>> > nominees should be added. As it is now, I have only seen a= n actual > >>>>> > objection to Kanzure and Ruben from /dev/fd0, and no expli= cit > >>>>> objections > >>>>> > to anyone else. It seems like the vast majority of people = don't share > >>>>> > their concerns either as both Kanzure and Ruben continue t= o be > >>>>> endorsed > >>>>> > by many others. > >>>>> > > >>>>> > Looking at the endorsements each candidate has received, t= he 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 that= this > >>>>> process > >>>>> > be something more like how Bitcoin Core maintainers are ad= ded - by > >>>>> > achieving rough consensus. Without any explicit objections= to any of > >>>>> > these candidates, I'm inclined to move forward with adding= 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 think= anyone > >>>>> really > >>>>> > wants to deal with. > >>>>> > > >>>>> > I do want to note that neither Kanzure, Ruben, nor Roasbee= f have > >>>>> posted > >>>>> > on this list that they are willing to be BIP editors. I ha= ve > >>>>> reached out > >>>>> > to all 3 of them privately, and received responses from Ka= nzure and > >>>>> > Ruben that indicate that they probably are willing, but pu= blic > >>>>> > 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 t= his > >>>>> task, so > >>>>> >> personal preferences are easily ignored and overwritten b= y 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 d= o not > >>>>> end up > >>>>> >> doing as much because they expect others to do the it. Th= is does not > >>>>> >> only make the process look bad but may burnout the ones t= hat 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 excess= ive and > >>>>> we need > >>>>> >> to add more people (plus discourage people from joining a= nd > >>>>> slacking off). > >>>>> >> > >>>>> >> I think 3 more people should be a good number to start fr= om. > >>>>> >> 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 >>>>> > >>>>> >> >> wr= ote: > >>>>> >> > >>>>> >> +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 b= y the group > >>>>> >> majority. > >>>>> >> > >>>>> >> BIPs were intended as a means to collect ideas, not enfor= ce 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 simp= ly > >>>>> saying "I > >>>>> >> like Bob!". > >>>>> >> > >>>>> >> Using only comments from the mailing list, the > >>>>> following appears > >>>>> >> to be > >>>>> >> the candidate list along with the current suppor= t. > >>>>> Asterisks denote > >>>>> >> candidates who indicated their willingness to ac= cept > >>>>> the role. > >>>>> >> > >>>>> >> - Bryan "Kanzure" Bishop, recommended by Ava Cho= w[1], Chris > >>>>> >> Stewart[3], > >>>>> >> Michael Folkson[6], Peter Todd[9], Matt Corallo[= 10], > >>>>> Brandon > >>>>> >> Black[11], > >>>>> >> Antoine Riard[12], Murch[13], Antoine Poinsot[15= ], John > >>>>> >> Carvalho[16] > >>>>> >> > >>>>> >> - Ruben Somsen, recommended by Ava Chow[1], Chri= s > >>>>> Stewart[3], > >>>>> >> Michael > >>>>> >> Folkson[6], Antoine Riard[12], Murch[13], Antoin= e > >>>>> Poinsot[15], John > >>>>> >> Carvalho[16] > >>>>> >> > >>>>> >> - Jon Atack*, recommended by Luke Dashjr[2], Chr= is > >>>>> Stewart[3], > >>>>> >> /dev/fd0[5][7], > >>>>> >> Brandon Black[11], Antoine Riard[12], Ava Chow[1= 4], John > >>>>> >> Carvalho[16] > >>>>> >> > >>>>> >> - Olaoluwa "Roasbeef" Osuntokun, recommended by = Chris > >>>>> >> Stewart[3], John > >>>>> >> C. Vernaleo[4], /dev/fd0[5][7], Keagan McClellan= d[8], > >>>>> Antoine > >>>>> >> Riard[12], Ava Chow[14] > >>>>> >> > >>>>> >> - Mark "Murch" Erhardt*, recommended by Michael > >>>>> Folkson[6], Keagan > >>>>> >> McClelland[8], Matt Corallo[10], Brandon Black[1= 1], 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 "BIP > >>>>> editor", and > >>>>> >> Antoine > >>>>> >> Riard[12] proposed Seccour for "decentralized PM= ". > >>>>> >> > >>>>> >> I searched the BIPs repo by commenter to see if = any of > >>>>> the above > >>>>> >> candidates had been especially active there, whi= ch is > >>>>> listed > >>>>> >> below as: > >>>>> >> total PRs they commented on (number still open/n= umber > >>>>> 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 member= of the > >>>>> set to > >>>>> >> have a > >>>>> >> merged BIP that they co-authored, although I bel= ieve > >>>>> there are > >>>>> >> far-along > >>>>> >> draft BIPs for both Murch (terminology) and Soms= en (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 can= didates > >>>>> above with > >>>>> >> multiple recommendations from other community > >>>>> participants are > >>>>> >> fully > >>>>> >> qualified for the role, so I'll only provide a d= etailed > >>>>> >> justification > >>>>> >> for the person who would be my first pick: Murch= is not > >>>>> only a > >>>>> >> longstanding and broadly liked Bitcoin contribut= or, but > >>>>> (as Corallo > >>>>> >> mentioned) he has worked on standardizing termin= ology > >>>>> through a > >>>>> >> draft > >>>>> >> BIP. In addition, he provided an extremely detai= led > >>>>> review of > >>>>> >> all 300 > >>>>> >> pages of a draft of Mastering Bitcoin (3rd editi= on) and has > >>>>> >> reviewed > >>>>> >> drafts of over 200 weekly Optech newsletters, in= both cases > >>>>> >> significantly improving the accuracy and > >>>>> comprehensibility of the > >>>>> >> documentation. To me, that seems very similar to= the > >>>>> work we'd > >>>>> >> ask him > >>>>> >> to perform as a BIPs editor and it's something t= hat > >>>>> he's already > >>>>> >> doing, > >>>>> >> so I think there's an excellent fit of person to= role. > >>>>> >> > >>>>> >> -Dave > >>>>> >> > >>>>> >> [1] > >>>>> >> > >>>>> https://gnusha.org/pi/bitcoindev/2092f7ff-4860-47f8...@achow1= 01.com/ > >>>>> > > >>>>> >> [2] > >>>>> >> > >>>>> https://gnusha.org/pi/bitcoindev/9288df7b-f2e9-4106...@dashjr= .org/ > >>>>> > >>>>> > > >>>>> >> [3] > >>>>> >> > >>>>> https://gnusha.org/pi/bitcoindev/d1e7183c-30e6-4f1a...@google= groups.com/ > > >>>>> >> [4] > >>>>> >> > >>>>> https://gnusha.org/pi/bitcoindev/84309c3f-e848-d333...@netpur= gatory.com/ > > >>>>> >> [5] > >>>>> >> > >>>>> https://gnusha.org/pi/bitcoindev/4c1462b7-ea1c-4a36...@google= groups.com/ > > >>>>> >> [6] > >>>>> >> > >>>>> https://gnusha.org/pi/bitcoindev/a116fba3-5948-48d2...@google= groups.com/ > > >>>>> >> [7] > >>>>> >> > >>>>> https://gnusha.org/pi/bitcoindev/846b668f-8386-4869...@google= groups.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...@mattco= rallo.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...@achow1= 01.com/ > >>>>> > > >>>>> >> [15] > >>>>> >> > >>>>> https://gnusha.org/pi/bitcoindev/ppBS1tfMU3SFX85kmIBVBd0WpT5W= of_oSBXsuizh7692AUDw2TojfvCqvcvlmsy9E69qfWMxK-UZWawf8IDApPqF7bXOH4gwU1c2jS4= xojo=3D@protonmail.com/ > > >>>>> >> [16] > >>>>> >> > >>>>> https://gnusha.org/pi/bitcoindev/ad284018-e99c-4552...@google= groups.com/ > > >>>>> >> [17] > >>>>> >> > >>>>> https://gnusha.org/pi/bitcoindev/CAMHHROw9mZJRnTbUo76PdqwJU= =3D=3DYJMvd9Qrst+...@mail.gmail.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 em= ails > >>>>> 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/7b4e2223-0b96-4c= a0-a441-aebcfc7b0bben%40googlegroups.com >. > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> -- > >>>>> >> Sergi. > >>>>> >> > >>>>> >> -- > >>>>> >> 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/CAEYHFxV_8_Jw61t= ysL_cV_xiXBcRyA3e%3DCGHGuSCgm%2B-4WxT9w%40mail.gmail.com >. > >>>>> > > >>>>> > -- > >>>>> > You received this message because you are subscribed to th= e > >>>>> Google Groups "Bitcoin Development Mailing List" group. > >>>>> > To unsubscribe from this group and stop receiving emails f= rom 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-4d= b8-b880-3c06ebc47cd1%40achow101.com . > >>>>> > >>>>> -- > >>>>> You received this message because you are subscribed to the G= oogle > >>>>> 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/070755a0-10e9-49= 03-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 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/CAFvNmHTgfwSx-kNzHSFW_7HWfOG1yupJQGZqXWzG47i%3D-DjSsA%40mail.gma= il.com.