summaryrefslogtreecommitdiff
path: root/c6/ee08bcf46a01733df1ee986054c2e6fefd3c3a
blob: 70164c09ed5f7e6b1a49b31be2091b33dbf59907 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
Delivery-date: Mon, 01 Apr 2024 14:17:10 -0700
Received: from mail-qv1-f55.google.com ([209.85.219.55])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRBTOIVSYAMGQELTYLLSY@googlegroups.com>)
	id 1rrP1g-0005Uo-8D
	for bitcoindev@gnusha.org; Mon, 01 Apr 2024 14:17:10 -0700
Received: by mail-qv1-f55.google.com with SMTP id 6a1803df08f44-698fd09061csf17223636d6.3
        for <bitcoindev@gnusha.org>; Mon, 01 Apr 2024 14:17:08 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1712006222; cv=pass;
        d=google.com; s=arc-20160816;
        b=mQqMrlyG1XdA5mxx9/uzLmFXtzqqxhnsGKAlu79udmWRpGklWSADOITXbTQbcysiW3
         NvH0eW6ezdParW4lg1h9JdOFSv7GdIj/WSIEuwxp+dUID/PFEBBHOL9GseFTMqIv1s+y
         eiq/fzhEc5UNVTu6o2jNBbraSVRgLwsjrrgw2d+7srrnAJCLdTmoMc7qNGWxVZoa2VLy
         W5pix8cVrpLd60OvryniXDQNeA36HuIV/TtP25GnU1/qUiGHbZ7yv+JRTlHlktBnlk38
         acNY/lqBV/O8qZpamUVb3jiUwvB+9NDk/Xrn6eQnnJHWx/g9+Xf8jwGmiZROygYmurY7
         L76g==
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:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=aGK6EFsr3DdVUntfEsNg/KU5//++eS/EZRljNDYzjIs=;
        fh=7+j0abTtmY9lEBvvXMjoRo+Q8c4wgwreSNPUg8piOXk=;
        b=dPenpaxvVx5DpRpH01WPr53xZMHq0mbG6+g/F+sx3nsiH+qevMJ7tJ5VkYgUgBwaik
         AZpjE3b1WDP2Bi5TFFNZA4OCK1NkJaxYAZD15IFmBngryNy34VBFXR0i+MTDXkz3GEu/
         gMuZLPpHBmX3tq3FJ2JJ9pHQXSq0mh9t//dYvt9/aPS+l28MCKXbmpmpTrsKaGNL3HHo
         Wc66E/zJQC+HBjGWp5rHDRnmnfwi4rcfIoucHVd2TJanbpEWE9ajVuMdnwTPMISPgNkN
         g2v/fQHACgZBDr8zKqC4ssjgmII7LvPxtJ3ZxcvNFAjYOZMVTkLvyWLL66/xhpezJuqR
         ib4A==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=g2DtWJyQ;
       spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::d32 as permitted sender) smtp.mailfrom=antoine.riard@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=1712006222; x=1712611022; 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:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=aGK6EFsr3DdVUntfEsNg/KU5//++eS/EZRljNDYzjIs=;
        b=eeVrO6CidQuWc5JBRSTQlsYeVLP66qczDbYt+v2x5i+QLRkAgQ8BtlFTYRpdz1cL70
         L5N+5/sckQfXdGe1sgTCVnFzMViS3nAa231StiW1B2PWpaYUCIT4XheNY+s17Jjqm0su
         XM/XzSPKuPSp7wk3Z34l72EVeYdfDlGWVx4mogp/FLaKwknXV7BCRsr0S5AhcsIQ3VaG
         SkGKEQ3WVH3IHXDKF/rkCymLvPyTXquRtZ+nJS62VZ2qK6oNRD1ckJoA1MSWz3bxO9Az
         uQPA37ZQUbO0+rCErx0fhyYnoGL9goAxRXAD9ALSIkuo9apr6faV9nH+9epHnw42C8qO
         t/dg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1712006222; x=1712611022; 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:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=aGK6EFsr3DdVUntfEsNg/KU5//++eS/EZRljNDYzjIs=;
        b=N7bo9uooapjmDFWWeX4SkQSdB0pCA8AkKaUdvp+1YlDrUkp/ys2zoLJbCeAviSxXuP
         XNDgyhxyz48NptuuS964AMw79VkHsBfcs504IzkJJ6rq7Xu9p94jEiZvRuoN10IBYlv4
         cFkHDQmOlNbbeEO92uEpK9WrjYzDe1CvxKsZOyTfFFx17i0Md+8DfvrGfTmIDbYqBRKF
         i3x/WyEO8GKlG1RmOo+prWN/y7nJ7LOXYpKXT+LEIrzxPr/1DNVvkAXhhfPIGOTyHaeX
         6fhcVY/Azu9zyZbZbV2QDjCwi6nWgngiHS61KFHio5ye51rGq3iYE6uJkeWH3bGDEfz3
         NuWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1712006222; x=1712611022;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender: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=aGK6EFsr3DdVUntfEsNg/KU5//++eS/EZRljNDYzjIs=;
        b=xMDd/PUkcA2RfTFFnw4TNRuJsr3oEwQnxllFCCJPvDgpVdusRdSqENvMVVRYQgXPnX
         BLjLT474ZRdpvzPckysB2NgNrlTGH5nhG4jb1DM/kl8fKrTYlDa2EZwzSKBnPY9j6uBe
         si8X+BiNyzYTOUvWqvbJBg9g8n4OIlY2OCgJr6DPduWRoIxuPzirLGxEv8iastKCPPAX
         Q6PgAfWTbGgBT9HLITSUI90LZnXvk9IAQQIoEjRtyHTMRBKb6oez3lp+QaEKCGvimdmZ
         o4GXE8dEL6xUeKs3oFIpPLGNY6Z5DvRN6zAPWaK3c7UhVmT1wSGQ4v3k+34e29tjmkya
         L9rw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCV7a4+vAOL522ILgVnt73EK+z/v7+1T5kEp18vDHEzoTDsylLHvLNoidNPUMsnj231OBJlLzhAhvSuFJvz25wSg0Nqwv18=
X-Gm-Message-State: AOJu0YwjwzCVDiESmNujZt6Aj4XoPZQmbONsVsBofo75G8Ek2gopHO3u
	XPAlx9fq2rQmg9vh3AVpYah8ApHf41TEqRojn5n+BP0PgUCqCYRu
X-Google-Smtp-Source: AGHT+IGctdZuROmLzoP2AuQGeQAzC1TA8d5PqOJbbCFtxwN0ImsphUoezOxBoOa60K2RgjsK7aMF7g==
X-Received: by 2002:a0c:f7cc:0:b0:699:514:3046 with SMTP id f12-20020a0cf7cc000000b0069905143046mr4817522qvo.15.1712006221799;
        Mon, 01 Apr 2024 14:17:01 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:ad4:5c87:0:b0:698:f37f:7964 with SMTP id o7-20020ad45c87000000b00698f37f7964ls1535720qvh.0.-pod-prod-04-us;
 Mon, 01 Apr 2024 14:17:01 -0700 (PDT)
X-Received: by 2002:a05:620a:4144:b0:78b:ea82:d78b with SMTP id k4-20020a05620a414400b0078bea82d78bmr103197qko.3.1712006221079;
        Mon, 01 Apr 2024 14:17:01 -0700 (PDT)
Received: by 2002:a05:620a:444b:b0:78b:c6cb:86d4 with SMTP id af79cd13be357-78bc6cbd439ms85a;
        Mon, 1 Apr 2024 13:14:34 -0700 (PDT)
X-Received: by 2002:a0c:f909:0:b0:696:a3f4:9c39 with SMTP id v9-20020a0cf909000000b00696a3f49c39mr11126006qvn.52.1712002473094;
        Mon, 01 Apr 2024 13:14:33 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1712002473; cv=none;
        d=google.com; s=arc-20160816;
        b=Ljr3eTMu3hRmiMFo4TKRZGYi2onFZ8SRGuwXhWF04fnbXJCvncGuezolAIzZ32lRhu
         hx4fo1jYp1kTu7HWhf7BG1mE1DU2QExRYmOvR97u9yfR4YxjNUbby2qV8Spo9sK0GObZ
         /JdaTLm3SsSVT3ggSwPU8Md0GPNWm/Fl3o8iEF3O0gQVrsHToZaHZi9wdQr5BCg7NRNI
         AqlfwKV2eye28Y/4O7J0+uOqwp33k6vVG3AuiizxuPFC6FvpVIRC3IPskxHCrJcz9WgI
         9llxCGYnFDj3y1/+AYH5b+ICh69BgG2zk5PfTI63URWDzbmEobRz5LCXOdqH6W8bQjB6
         B9uA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=VXncrJzdqkRQtjZHCU5OS8xF7tl9xU4WDNtxXI/l+4c=;
        fh=gNZB6R3gE0GWmgYCZFlcuq+Q7ciK/nQdnDvSFJ8wRPo=;
        b=HHstgek09/LH1oou+tCvwpYr5RmFHxeaDTzSpJ8PyAwTkuGSWHPoh6Qtk3MLTtaY3P
         FffwY+4kBPvIFkuLMa5fS7JK1BekfqYFx+I9M/Ah6yCq4jpNsjGi28QtceT8l/JAiC1w
         d8IDFsFmM8OMo3Jad6QkFQ2IGRlJmzUcYDyslJIiAuF9vkukwo6OWf1c9nHDWt/uw5uj
         KlHl+pRmIfVlYpcEVvs2tN3gdkSOwiItnHNEAYGs8iBgQSTPlTD5AGGfs0xrC0PQ7+E/
         xxhiDFHcOqL5T7IxBpsq1pvOJJtEVm/16bBvu8rnFS6/RRUzHCnknc4+5XWS8yEXZ8EA
         OpQg==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=g2DtWJyQ;
       spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::d32 as permitted sender) smtp.mailfrom=antoine.riard@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com. [2607:f8b0:4864:20::d32])
        by gmr-mx.google.com with ESMTPS id qf1-20020a0562144b8100b006965f40ae76si376296qvb.8.2024.04.01.13.14.33
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Mon, 01 Apr 2024 13:14:33 -0700 (PDT)
Received-SPF: pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::d32 as permitted sender) client-ip=2607:f8b0:4864:20::d32;
Received: by mail-io1-xd32.google.com with SMTP id ca18e2360f4ac-7cc5fdb0148so189322939f.3
        for <bitcoindev@googlegroups.com>; Mon, 01 Apr 2024 13:14:33 -0700 (PDT)
X-Received: by 2002:a6b:5d07:0:b0:7cc:652d:ce60 with SMTP id
 r7-20020a6b5d07000000b007cc652dce60mr10194508iob.20.1712002472261; Mon, 01
 Apr 2024 13:14:32 -0700 (PDT)
MIME-Version: 1.0
References: <2092f7ff-4860-47f8-ba1a-c9d97927551e@achow101.com>
 <e4048607-64b7-4772-b74e-4566a4b50bc0n@googlegroups.com> <9288df7b-f2e9-4106-b843-c1ff8f8a62a3@dashjr.org>
 <42e6c1d1d39d811e2fe7c4c5ce6e09c705bd3dbb.camel@timruffing.de>
 <d1e7183c-30e6-4f1a-8fd6-cddc46f129a2n@googlegroups.com> <52a0d792-d99f-4360-ba34-0b12de183fef@murch.one>
 <84309c3f-e848-d333-fd28-bdd55899b713@netpurgatory.com> <9baa15e4-062d-478f-8c87-8ff19ab79989@murch.one>
 <4c1462b7-ea1c-4a36-be81-7c3719157fabn@googlegroups.com> <6806b22d-043d-4201-841a-95e17cd8d542@mattcorallo.com>
 <846b668f-8386-4869-a3b1-55d346efbea1n@googlegroups.com> <f8fa1a55-644f-4cf1-b8c1-4fdef22d1869n@googlegroups.com>
 <CAFvNmHQiXFbjMxHWeWYb4J5TDDpYT0o4CexYdcOjrUAaCt4f6w@mail.gmail.com>
 <CALZpt+EU4JzbDepsu4Wz-6e0XB4VuKCqatiRnb1nKXe++jF+Rw@mail.gmail.com> <CAFvNmHSN6dN5yS3+zrgW2c5wDbQbZwEd71vGdr2Z4OrSQLdZDA@mail.gmail.com>
In-Reply-To: <CAFvNmHSN6dN5yS3+zrgW2c5wDbQbZwEd71vGdr2Z4OrSQLdZDA@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Mon, 1 Apr 2024 21:14:20 +0100
Message-ID: <CALZpt+F=dUVn6bDLewjVVHGymhqYZgHQZ4yX+tfAPWx9gH_pzA@mail.gmail.com>
Subject: Re: [bitcoindev] Re: Adding New BIP Editors
To: Michael Folkson <michaelfolkson@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="00000000000036c13106150ea38f"
X-Original-Sender: antoine.riard@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=g2DtWJyQ;       spf=pass
 (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::d32
 as permitted sender) smtp.mailfrom=antoine.riard@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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

--00000000000036c13106150ea38f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Michael,

Thanks for the thoughtful answer.

> I repeat having the BIPs repo under a different GitHub organization
> would *not* have resulted in a different outcome in the Taproot
> activation params or avoided that particular conflict. If Core
> maintainers had merged a BIPs PR or kicked Luke off as a BIPs editor
> that would have been a different outcome. There are costs to moving
> the BIPs repo to a different GitHub organization (existing links,
> discoverability, two GitHub organizations to worry about rather than
> one) and as long as Core maintainers don't overrule BIP editors in the
> BIPs repo there are no clear upsides.

Fair point, though I think it's more a one-time migration cost for
long-term returns.
I still believe we shall apply the principle of least privilege when we can=
.
This blog article is a good one to meditate:
https://laanwj.github.io/2016/05/06/hostility-scams-and-moving-forward.html

> Just as you don't need to be a maintainer to provide high quality pull
> request review in the Core repo you don't need to be a BIP editor to
> provide high quality pull request review in the BIPs repo. There is
> nothing to stop people who aren't BIP editors continuing to provide
> review of your work in English and a BIPs repo in English only needs
> BIP editors who are fluent in English.

That's a fair point too, terminology / high-quality review can be provided
by non-editors.
The worthiness of having non-English editors it's up if we see this as an
administrative task or editorial one in my opinion.

> I think we'd agree we are somewhere in between these pure extremes and
> I'd argue mostly towards the administrative task end. One of the
> reasons I think Kanzure, RubenSomsen and Murch are good BIP editor
> candidates is that they can also provide high quality pull request
> review before potentially merging but unlike the Core repo where bad
> ideas should never be merged a BIP editor will end up merging up pull
> requests they think are bad ideas that they would never want merged
> into Core. A BIP can get a BIP number and end up being rejected by
> Core or the broader community for example.

On the experience of the inheritance rule in bip125, I would say it's not
so bad if there is a minimum of editorial checks.
At least when the proposal starts to be "proposed" / "final". You don't
need at first how standards are aging with time.
It's not specific to BIP, we have this issue with the BOLTs which have been
amended many times to make things more robust.

I don't know if the BIP process should be more proactive "deprecating" /
"obsolating" / "cleaning-up" standards like done by the IETF.
(It's clearly another set of tasks far beyond the focus of this
discussion...).

> This seems even more bureaucratic to me. Different numbers to track,
> more complexity. There is a BINANA repo [0] for Bitcoin Inquisition
> for this kind of early experimentation for proposed consensus changes
> that aren't advanced enough to be BIPs.

That "fast-track" numbers assignment experiment might work with time. Let'
see.

> Personally I think it is fine as it is. We are discussing the
> potential addition of high quality BIP editors as only having one
> currently (Luke) is clearly not ideal. That will alleviate Luke as a
> single bottleneck. I do think it is time for an update to the BIP
> process (BIP 3) too so BIP editors have some guidance on how to treat
> bad ideas (how bad are we talking!) and are comfortable merging pull
> requests around attempted (successful or failed) soft fork
> activations. Ultimately though just like with Core maintainers there
> is going to be some personal judgment required especially during those
> cases where there isn't clear community consensus either way. Hence
> for those cases I'd be much more comfortable with say Kanzure,
> RubenSomsen or Murch than someone we know very little about and hasn't
> demonstrated a strong understanding of how Bitcoin works.

On the contrary, the BIP process should clearly bound BIP editors personal
judgement, especially at a time of lack of clear community consensus.
If there is one lesson of consensus activation or policy changes over the
last few years, it's better to "wait-and-proactively-build-more-consensus"
rather than "force-through".
Even if the "force-through" is coming from appointed editors or whatever,
practice and respect of the process matters over titles and roles in my
opinion.

For sure, anyone who has already championed a change in Bitcoin has fallen
short of impatience, myself included (e.g with mempoolfullrbf).
Yet, it's good to remember that a bit of technical conservatism,
over-reviewing and feedback collection is always welcome on the delicate
changes.

All that said, I said my opinion on the list of BIP candidates already and
I have nothing more to say.
I won't express myself further on this subject, too much code to write and
review.

Best,
Antoine



Le dim. 31 mars 2024 =C3=A0 17:01, Michael Folkson <michaelfolkson@gmail.co=
m> a
=C3=A9crit :

> Hi Antoine
>
> Thanks for the challenge. I think we are going to end up disagreeing
> on some things but perhaps the discussion is worth having.
>
> > Indeed, avoiding new conflicts like we have seen with Luke with Taproot
> activation params is a good reason to separate repositories in my opinion=
.
> Beyond, "security through distrusting" [0] is a very legitimate
> security philosophy including for communication space infrastructure.
>
> I repeat having the BIPs repo under a different GitHub organization
> would *not* have resulted in a different outcome in the Taproot
> activation params or avoided that particular conflict. If Core
> maintainers had merged a BIPs PR or kicked Luke off as a BIPs editor
> that would have been a different outcome. There are costs to moving
> the BIPs repo to a different GitHub organization (existing links,
> discoverability, two GitHub organizations to worry about rather than
> one) and as long as Core maintainers don't overrule BIP editors in the
> BIPs repo there are no clear upsides.
>
> > No, I wish to ensure that if the aim of the BIP is ensuring high-qualit=
y
> and readability of standards those ones are well-written, including when
> the original standard is contributed by someone non-native.
> I can only remember numerous times when my english technical texts
> have been kindly corrected by other contributors. Having editors
> understanding multiple languages helps in quality redaction.
>
> Just as you don't need to be a maintainer to provide high quality pull
> request review in the Core repo you don't need to be a BIP editor to
> provide high quality pull request review in the BIPs repo. There is
> nothing to stop people who aren't BIP editors continuing to provide
> review of your work in English and a BIPs repo in English only needs
> BIP editors who are fluent in English.
>
> > Beyond, from reading conversations it sounds there is a disagreement if
> it's an administrative task (i.e "assigning numbers") or editorial one (i=
.e
> "high-quality, well-written standards").
>
> I think we'd agree we are somewhere in between these pure extremes and
> I'd argue mostly towards the administrative task end. One of the
> reasons I think Kanzure, RubenSomsen and Murch are good BIP editor
> candidates is that they can also provide high quality pull request
> review before potentially merging but unlike the Core repo where bad
> ideas should never be merged a BIP editor will end up merging up pull
> requests they think are bad ideas that they would never want merged
> into Core. A BIP can get a BIP number and end up being rejected by
> Core or the broader community for example.
>
> > If we wish to make things less bureaucratic, we might actually separate
> the two tasks with different groups of BIP process maintainers :
> - assign temporary numbers for experimentation
> - wait for more-or-less finalized drafts written in a quality fashion
> - assign final numbers for standard candidate deployment
>
> This seems even more bureaucratic to me. Different numbers to track,
> more complexity. There is a BINANA repo [0] for Bitcoin Inquisition
> for this kind of early experimentation for proposed consensus changes
> that aren't advanced enough to be BIPs.
>
> > If you see other ways to dissociate the roles and make things less
> bureaucratic ? E.g having people only in charge of triage.
> If I remember correctly the IETF does not assign RFC numbers for draft
> proposals, and you generally have years of experimentation.
>
> Personally I think it is fine as it is. We are discussing the
> potential addition of high quality BIP editors as only having one
> currently (Luke) is clearly not ideal. That will alleviate Luke as a
> single bottleneck. I do think it is time for an update to the BIP
> process (BIP 3) too so BIP editors have some guidance on how to treat
> bad ideas (how bad are we talking!) and are comfortable merging pull
> requests around attempted (successful or failed) soft fork
> activations. Ultimately though just like with Core maintainers there
> is going to be some personal judgment required especially during those
> cases where there isn't clear community consensus either way. Hence
> for those cases I'd be much more comfortable with say Kanzure,
> RubenSomsen or Murch than someone we know very little about and hasn't
> demonstrated a strong understanding of how Bitcoin works.
>
> > PS: By the way, even at the United Nations, unanimity is not the rule,
> it's two-third of the general assembly. I think your analogy is not valid=
.
>
> Perhaps we can leave discussion of my imperfect analogies to a
> different forum :) Hopefully we can agree that this is a direction of
> travel that we shouldn't be pursuing for the BIPs repo.
>
> [0]: https://github.com/bitcoin-inquisition/binana
>
> On Sat, Mar 30, 2024 at 8:01=E2=80=AFPM Antoine Riard <antoine.riard@gmai=
l.com>
> wrote:
> >
> > Hi Michael,
> >
> > > In the past there have been disagreements between Core maintainers an=
d
> > > BIP editors (e.g. Luke with Taproot activation params) and those Core
> > > maintainers haven't merged pull requests in the BIPs repo or removed
> > > him as a BIP editor. As long as that continues it isn't necessary to
> > > create a new GitHub organization for the BIPs repo. They are separate
> > > repos with different maintainers/editors but under the same
> > > organization and everyone knows where it is located.
> >
> > Indeed, avoiding new conflicts like we have seen with Luke with Taproot
> activation params is a good reason to separate repositories in my opinion=
.
> > Beyond, "security through distrusting" [0] is a very legitimate securit=
y
> philosophy including for communication space infrastructure.
> >
> > [0]
> https://www.qubes-os.org/news/2017/12/11/joanna-rutkowska-black-hat-europ=
e-2017/
> >
> > > It seems like you want to create some kind of United Nations for the
> > > BIP process. As I said previously this is almost entirely an
> > > administrative task. Going to a committee of 10 people with different
> > > nationalities and languages to decide whether something should get a
> > > BIP number is absurd. If you think Luke is slow to respond wait until
> > > your United Nations of the BIP process has to all agree to assign a
> > > BIP number. Please don't try to make this unnecessarily bureaucratic
> > > and political for no reason. There's enough of that outside of
> > > Bitcoin.
> >
> > No, I wish to ensure that if the aim of the BIP is ensuring high-qualit=
y
> and readability of standards those ones are well-written, including when
> the original standard is contributed by someone non-native.
> > I can only remember numerous times when my english technical texts have
> been kindly corrected by other contributors. Having editors understanding
> multiple languages helps in quality redaction.
> >
> > Beyond, from reading conversations it sounds there is a disagreement if
> it's an administrative task (i.e "assigning numbers") or editorial one (i=
.e
> "high-quality, well-written standards").
> >
> > If we wish to make things less bureaucratic, we might actually separate
> the two tasks with different groups of BIP process maintainers :
> > - assign temporary numbers for experimentation
> > - wait for more-or-less finalized drafts written in a quality fashion
> > - assign final numbers for standard candidate deployment
> >
> > If you see other ways to dissociate the roles and make things less
> bureaucratic ? E.g having people only in charge of triage.
> > If I remember correctly the IETF does not assign RFC numbers for draft
> proposals, and you generally have years of experimentation.
> >
> > Best,
> > Antoine
> >
> > PS: By the way, even at the United Nations, unanimity is not the rule,
> it's two-third of the general assembly. I think your analogy is not valid=
.
> >
> > Le sam. 30 mars 2024 =C3=A0 11:52, Michael Folkson <michaelfolkson@gmai=
l.com>
> a =C3=A9crit :
> >>
> >> > In a world where both Core and BIP repository are living under a
> single Github organization, I don't think in matters that much as the
> highest privilege account will be able to
> >> override any BIP merging decision, or even remove on the flight BIP
> >> editors rights in case of conflicts or controversies. If you're
> >> raising the issue that the BIP repository should be moved to its own
> >> GH repository I think it's a valuable point.
> >>
> >> In the past there have been disagreements between Core maintainers and
> >> BIP editors (e.g. Luke with Taproot activation params) and those Core
> >> maintainers haven't merged pull requests in the BIPs repo or removed
> >> him as a BIP editor. As long as that continues it isn't necessary to
> >> create a new GitHub organization for the BIPs repo. They are separate
> >> repos with different maintainers/editors but under the same
> >> organization and everyone knows where it is located.
> >>
> >> > Beyond, I still think we should ensure we have a wider crowd of
> geographically and culturally diverse BIP editors. As if the role is
> ensuring high-quality and readability of the terminology of the standards=
,
> we might have highly-skilled technical BIP champions which are not Englis=
h
> native. With the current set of proposed BIP editors, to the best of my
> knowledge, at least we have few langages spoken by the candidates: Dutch,
> French, German, Spanish. This can be very helpful to translate concepts
> devised in language A to technical english.
> >>
> >> It seems like you want to create some kind of United Nations for the
> >> BIP process. As I said previously this is almost entirely an
> >> administrative task. Going to a committee of 10 people with different
> >> nationalities and languages to decide whether something should get a
> >> BIP number is absurd. If you think Luke is slow to respond wait until
> >> your United Nations of the BIP process has to all agree to assign a
> >> BIP number. Please don't try to make this unnecessarily bureaucratic
> >> and political for no reason. There's enough of that outside of
> >> Bitcoin.
> >>
> >> On Fri, Mar 29, 2024 at 9:14=E2=80=AFPM Antoine Riard <antoine.riard@g=
mail.com>
> wrote:
> >> >
> >> > > Roasbeef's work on alternative clients and lightning make him
> technically
> >> > useful
> >> >
> >> > I think one of the aim of the BIP process is to harmonize common
> mechanisms among Bitcoin clients of different langages breeds or at
> different layers (wallet / full-node).
> >> > Having someone among BIP editors with a proven track record of
> contributing to other full-node codebase beyond C++ can be valuable in th=
at
> sense.
> >> > Especially for all matters related to compatibility and deployment.
> >> >
> >> > > For example I think Jon Atack would make a great Core maintainer a=
t
> some point in the future and I'm not sure a BIP editor should also be a
> Core maintainer given the
> >> > > independence sometimes required between Core and the BIP process
> >> >
> >> > In a world where both Core and BIP repository are living under a
> single Github organization, I don't think in matters that much as the
> highest privilege account will be able to
> >> > override any BIP merging decision, or even remove on the flight BIP
> editors rights in case of conflicts or controversies. If you're raising t=
he
> issue that the BIP repository should be moved to its own GH repository I
> think it's a valuable point.
> >> >
> >> > Beyond, I still think we should ensure we have a wider crowd of
> geographically and culturally diverse BIP editors. As if the role is
> ensuring high-quality and readability of the terminology of the standards=
,
> we might have highly-skilled technical BIP champions which are not Englis=
h
> native. With the current set of proposed BIP editors, to the best of my
> knowledge, at least we have few langages spoken by the candidates: Dutch,
> French, German, Spanish. This can be very helpful to translate concepts
> devised in language A to technical english.
> >> >
> >> > Best,
> >> > Antoine
> >> >
> >> >
> >> > Le vendredi 29 mars 2024 =C3=A0 12:33:09 UTC, /dev /fd0 a =C3=A9crit=
 :
> >> >>
> >> >> Justification:
> >> >>
> >> >> 1. Jon Atack: Good at avoiding controversies and technical
> documentation.
> >> >> 2. Roasbeef: Since BIPs are not just related to bitcoin core, it's
> good to have btcd maintainer as a BIP editor.
> >> >>
> >> >> On Friday, March 29, 2024 at 1:47:41=E2=80=AFAM UTC+5:30 Matt Coral=
lo wrote:
> >> >>>
> >> >>> Please provide justification rather than simply saying "I like
> Bob!".
> >> >>>
> >> >>> Matt
> >> >>>
> >> >>> On 3/28/24 12:09 PM, /dev /fd0 wrote:
> >> >>> > I support Jon Atack and Roasbeef from this list.
> >> >>> >
> >> >>> > On Thursday, March 28, 2024 at 6:57:53=E2=80=AFPM UTC+5:30 Murch=
 wrote:
> >> >>> >
> >> >>> > I just went through the thread, previously mentioned were:
> >> >>> >
> >> >>> > - Kanzure
> >> >>> > - Ruben Somsen
> >> >>> > - Greg Tonoski
> >> >>> > - Jon Atack
> >> >>> > - Roasbeef
> >> >>> > - Seccour
> >> >>> >
> >> >>> > And Matt just suggested me for the role. Hope I didn=E2=80=99t o=
verlook
> anyone.
> >> >>> >
> >> >>> > On 3/27/24 19:39, John C. Vernaleo wrote:
> >> >>> > > That said, I would find it helpful if someone could go through
> the
> >> >>> > > thread and list all the people who've been proposed so people
> know who
> >> >>> > > they should be thinking about.
> >> >>> >
> >> >>> > --
> >> >>> > You received this message because you are subscribed to the
> Google Groups "Bitcoin Development
> >> >>> > Mailing List" group.
> >> >>> > To unsubscribe from this group and stop receiving emails from it=
,
> send an email to
> >> >>> > bitcoindev+...@googlegroups.com <mailto:
> bitcoindev+...@googlegroups.com>.
> >> >>> > To view this discussion on the web visit
> >> >>> >
> https://groups.google.com/d/msgid/bitcoindev/4c1462b7-ea1c-4a36-be81-7c37=
19157fabn%40googlegroups.com
> <
> https://groups.google.com/d/msgid/bitcoindev/4c1462b7-ea1c-4a36-be81-7c37=
19157fabn%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter
> >.
> >> >
> >> > --
> >> > 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/f8fa1a55-644f-4cf1-b8c1-4fde=
f22d1869n%40googlegroups.com
> .
> >>
> >>
> >>
> >> --
> >> Michael Folkson
> >> Personal email: michaelfolkson@gmail.com
>
>
>
> --
> 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/CALZpt%2BF%3DdUVn6bDLewjVVHGymhqYZgHQZ4yX%2BtfAPWx9gH_pzA%40mail=
.gmail.com.

--00000000000036c13106150ea38f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Michael,<div><br></div><div>Thanks for the thoughtful a=
nswer.</div><div><br></div><div>&gt; I repeat having the BIPs repo under a =
different GitHub organization<br>&gt; would *not* have resulted in a differ=
ent outcome in the Taproot<br>&gt; activation params or avoided that partic=
ular conflict. If Core<br>&gt; maintainers had merged a BIPs PR or kicked L=
uke off as a BIPs editor<br>&gt; that would have been a different outcome. =
There are costs to moving<br>&gt; the BIPs repo to a different GitHub organ=
ization (existing links,<br>&gt; discoverability, two GitHub organizations =
to worry about rather than<br>&gt; one) and as long as Core maintainers don=
&#39;t overrule BIP editors in the<br>&gt; BIPs repo there are no clear ups=
ides.<br></div><div><br></div><div>Fair point, though I think it&#39;s more=
 a one-time migration cost for long-term=C2=A0returns.</div><div>I still be=
lieve we shall apply the principle of least privilege when we can.</div><di=
v>This blog article is a good one to meditate:</div><div><a href=3D"https:/=
/laanwj.github.io/2016/05/06/hostility-scams-and-moving-forward.html">https=
://laanwj.github.io/2016/05/06/hostility-scams-and-moving-forward.html</a><=
br></div><div><br></div><div>&gt; Just as you don&#39;t need to be a mainta=
iner to provide high quality pull<br>&gt; request review in the Core repo y=
ou don&#39;t need to be a BIP editor to<br>&gt; provide high quality pull r=
equest review in the BIPs repo. There is<br>&gt; nothing to stop people who=
 aren&#39;t BIP editors continuing to provide<br>&gt; review of your work i=
n English and a BIPs repo in English only needs<br>&gt; BIP editors who are=
 fluent in English.<span class=3D"gmail-im" style=3D"color:rgb(80,0,80)"><b=
r></span></div><div><br></div><div>That&#39;s a fair point too, terminology=
 / high-quality review can be provided by non-editors.</div><div>The worthi=
ness of having non-English editors it&#39;s up if we see this as an adminis=
trative task or editorial one in my opinion.</div><div><br></div><div>&gt; =
I think we&#39;d agree we are somewhere in between these pure extremes and<=
br>&gt; I&#39;d argue mostly towards the administrative task end. One of th=
e<br>&gt; reasons I think Kanzure, RubenSomsen and Murch are good BIP edito=
r<br>&gt; candidates is that they can also provide high quality pull reques=
t<br>&gt; review before potentially merging but unlike the Core repo where =
bad<br>&gt; ideas should never be merged a BIP editor will end up merging u=
p pull<br>&gt; requests they think are bad ideas that they would never want=
 merged<br>&gt; into Core. A BIP can get a BIP number and end up being reje=
cted by<br>&gt; Core or the broader community for example.<br></div><div><b=
r></div><div>On the experience of the inheritance rule in bip125, I would s=
ay it&#39;s not so bad if there is a minimum of editorial=C2=A0checks.</div=
><div>At least when the proposal starts to be &quot;proposed&quot; / &quot;=
final&quot;. You don&#39;t need at first how standards are aging with time.=
</div><div>It&#39;s not specific to BIP, we have this issue with the BOLTs =
which have been amended many times to make things more robust.</div><div><b=
r></div><div>I don&#39;t know if the BIP process should be more proactive &=
quot;deprecating&quot; / &quot;obsolating&quot; / &quot;cleaning-up&quot; s=
tandards like done by the IETF.</div><div>(It&#39;s clearly another set of =
tasks far beyond the focus of this discussion...).</div><div><br></div><div=
>&gt; This seems even more bureaucratic to me. Different numbers to track,<=
br>&gt; more complexity. There is a BINANA repo [0] for Bitcoin Inquisition=
<br>&gt; for this kind of early experimentation for proposed consensus chan=
ges<br>&gt; that aren&#39;t advanced enough to be BIPs.<br></div><div><br><=
/div><div>That &quot;fast-track&quot; numbers assignment experiment might w=
ork with time. Let&#39; see.</div><div><br></div><div>&gt; Personally I thi=
nk it is fine as it is. We are discussing the<br>&gt; potential addition of=
 high quality BIP editors as only having one<br>&gt; currently (Luke) is cl=
early not ideal. That will alleviate Luke as a<br>&gt; single bottleneck. I=
 do think it is time for an update to the BIP<br>&gt; process (BIP 3) too s=
o BIP editors have some guidance on how to treat<br>&gt; bad ideas (how bad=
 are we talking!) and are comfortable merging pull<br>&gt; requests around =
attempted (successful or failed) soft fork<br>&gt; activations. Ultimately =
though just like with Core maintainers there<br>&gt; is going to be some pe=
rsonal judgment required especially during those<br>&gt; cases where there =
isn&#39;t clear community consensus either way. Hence<br>&gt; for those cas=
es I&#39;d be much more comfortable with say Kanzure,<br>&gt; RubenSomsen o=
r Murch than someone we know very little about and hasn&#39;t<br>&gt; demon=
strated a strong understanding of how Bitcoin works.<br></div><div><br></di=
v><div>On the contrary, the=C2=A0BIP process should clearly bound BIP edito=
rs personal judgement, especially at a time of lack of clear community cons=
ensus.</div><div>If there is one lesson of consensus activation or policy c=
hanges over the last few years, it&#39;s better to &quot;wait-and-proactive=
ly-build-more-consensus&quot; rather than &quot;force-through&quot;.</div><=
div>Even if the &quot;force-through&quot; is coming from appointed editors =
or whatever, practice and respect of the process matters over titles and ro=
les in my opinion.</div><div><br></div><div>For sure, anyone who has alread=
y championed a change in Bitcoin has fallen short of impatience, myself inc=
luded (e.g with mempoolfullrbf).</div><div>Yet, it&#39;s good to remember t=
hat a bit of technical conservatism, over-reviewing and feedback collection=
 is always welcome on=C2=A0the delicate changes.</div><div><br></div><div>A=
ll that said, I said my=C2=A0opinion on=C2=A0the list of BIP candidates=C2=
=A0already and I have nothing more to say.</div><div>I won&#39;t express my=
self further on this subject, too much code to write and review.</div><div>=
<br></div><div>Best,</div><div>Antoine</div><div><br></div><div><br></div><=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">L=
e=C2=A0dim. 31 mars 2024 =C3=A0=C2=A017:01, Michael Folkson &lt;<a href=3D"=
mailto:michaelfolkson@gmail.com">michaelfolkson@gmail.com</a>&gt; a =C3=A9c=
rit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-colo=
r:rgb(204,204,204);padding-left:1ex">Hi Antoine<br>
<br>
Thanks for the challenge. I think we are going to end up disagreeing<br>
on some things but perhaps the discussion is worth having.<br>
<br>
&gt; Indeed, avoiding new conflicts like we have seen with Luke with Taproo=
t activation params is a good reason to separate repositories in my opinion=
.<br>
Beyond, &quot;security through distrusting&quot; [0] is a very legitimate<b=
r>
security philosophy including for communication space infrastructure.<br>
<br>
I repeat having the BIPs repo under a different GitHub organization<br>
would *not* have resulted in a different outcome in the Taproot<br>
activation params or avoided that particular conflict. If Core<br>
maintainers had merged a BIPs PR or kicked Luke off as a BIPs editor<br>
that would have been a different outcome. There are costs to moving<br>
the BIPs repo to a different GitHub organization (existing links,<br>
discoverability, two GitHub organizations to worry about rather than<br>
one) and as long as Core maintainers don&#39;t overrule BIP editors in the<=
br>
BIPs repo there are no clear upsides.<br>
<br>
&gt; No, I wish to ensure that if the aim of the BIP is ensuring high-quali=
ty and readability of standards those ones are well-written, including when=
 the original standard is contributed by someone non-native.<br>
I can only remember numerous times when my english technical texts<br>
have been kindly corrected by other contributors. Having editors<br>
understanding multiple languages helps in quality redaction.<br>
<br>
Just as you don&#39;t need to be a maintainer to provide high quality pull<=
br>
request review in the Core repo you don&#39;t need to be a BIP editor to<br=
>
provide high quality pull request review in the BIPs repo. There is<br>
nothing to stop people who aren&#39;t BIP editors continuing to provide<br>
review of your work in English and a BIPs repo in English only needs<br>
BIP editors who are fluent in English.<br>
<br>
&gt; Beyond, from reading conversations it sounds there is a disagreement i=
f it&#39;s an administrative task (i.e &quot;assigning numbers&quot;) or ed=
itorial one (i.e &quot;high-quality, well-written standards&quot;).<br>
<br>
I think we&#39;d agree we are somewhere in between these pure extremes and<=
br>
I&#39;d argue mostly towards the administrative task end. One of the<br>
reasons I think Kanzure, RubenSomsen and Murch are good BIP editor<br>
candidates is that they can also provide high quality pull request<br>
review before potentially merging but unlike the Core repo where bad<br>
ideas should never be merged a BIP editor will end up merging up pull<br>
requests they think are bad ideas that they would never want merged<br>
into Core. A BIP can get a BIP number and end up being rejected by<br>
Core or the broader community for example.<br>
<br>
&gt; If we wish to make things less bureaucratic, we might actually separat=
e the two tasks with different groups of BIP process maintainers :<br>
- assign temporary numbers for experimentation<br>
- wait for more-or-less finalized drafts written in a quality fashion<br>
- assign final numbers for standard candidate deployment<br>
<br>
This seems even more bureaucratic to me. Different numbers to track,<br>
more complexity. There is a BINANA repo [0] for Bitcoin Inquisition<br>
for this kind of early experimentation for proposed consensus changes<br>
that aren&#39;t advanced enough to be BIPs.<br>
<br>
&gt; If you see other ways to dissociate the roles and make things less bur=
eaucratic ? E.g having people only in charge of triage.<br>
If I remember correctly the IETF does not assign RFC numbers for draft<br>
proposals, and you generally have years of experimentation.<br>
<br>
Personally I think it is fine as it is. We are discussing the<br>
potential addition of high quality BIP editors as only having one<br>
currently (Luke) is clearly not ideal. That will alleviate Luke as a<br>
single bottleneck. I do think it is time for an update to the BIP<br>
process (BIP 3) too so BIP editors have some guidance on how to treat<br>
bad ideas (how bad are we talking!) and are comfortable merging pull<br>
requests around attempted (successful or failed) soft fork<br>
activations. Ultimately though just like with Core maintainers there<br>
is going to be some personal judgment required especially during those<br>
cases where there isn&#39;t clear community consensus either way. Hence<br>
for those cases I&#39;d be much more comfortable with say Kanzure,<br>
RubenSomsen or Murch than someone we know very little about and hasn&#39;t<=
br>
demonstrated a strong understanding of how Bitcoin works.<br>
<br>
&gt; PS: By the way, even at the United Nations, unanimity is not the rule,=
 it&#39;s two-third of the general assembly. I think your analogy is not va=
lid.<br>
<br>
Perhaps we can leave discussion of my imperfect analogies to a<br>
different forum :) Hopefully we can agree that this is a direction of<br>
travel that we shouldn&#39;t be pursuing for the BIPs repo.<br>
<br>
[0]: <a href=3D"https://github.com/bitcoin-inquisition/binana" rel=3D"noref=
errer" target=3D"_blank">https://github.com/bitcoin-inquisition/binana</a><=
br>
<br>
On Sat, Mar 30, 2024 at 8:01=E2=80=AFPM Antoine Riard &lt;<a href=3D"mailto=
:antoine.riard@gmail.com" target=3D"_blank">antoine.riard@gmail.com</a>&gt;=
 wrote:<br>
&gt;<br>
&gt; Hi Michael,<br>
&gt;<br>
&gt; &gt; In the past there have been disagreements between Core maintainer=
s and<br>
&gt; &gt; BIP editors (e.g. Luke with Taproot activation params) and those =
Core<br>
&gt; &gt; maintainers haven&#39;t merged pull requests in the BIPs repo or =
removed<br>
&gt; &gt; him as a BIP editor. As long as that continues it isn&#39;t neces=
sary to<br>
&gt; &gt; create a new GitHub organization for the BIPs repo. They are sepa=
rate<br>
&gt; &gt; repos with different maintainers/editors but under the same<br>
&gt; &gt; organization and everyone knows where it is located.<br>
&gt;<br>
&gt; Indeed, avoiding new conflicts like we have seen with Luke with Taproo=
t activation params is a good reason to separate repositories in my opinion=
.<br>
&gt; Beyond, &quot;security through distrusting&quot; [0] is a very legitim=
ate security philosophy including for communication space infrastructure.<b=
r>
&gt;<br>
&gt; [0] <a href=3D"https://www.qubes-os.org/news/2017/12/11/joanna-rutkows=
ka-black-hat-europe-2017/" rel=3D"noreferrer" target=3D"_blank">https://www=
.qubes-os.org/news/2017/12/11/joanna-rutkowska-black-hat-europe-2017/</a><b=
r>
&gt;<br>
&gt; &gt; It seems like you want to create some kind of United Nations for =
the<br>
&gt; &gt; BIP process. As I said previously this is almost entirely an<br>
&gt; &gt; administrative task. Going to a committee of 10 people with diffe=
rent<br>
&gt; &gt; nationalities and languages to decide whether something should ge=
t a<br>
&gt; &gt; BIP number is absurd. If you think Luke is slow to respond wait u=
ntil<br>
&gt; &gt; your United Nations of the BIP process has to all agree to assign=
 a<br>
&gt; &gt; BIP number. Please don&#39;t try to make this unnecessarily burea=
ucratic<br>
&gt; &gt; and political for no reason. There&#39;s enough of that outside o=
f<br>
&gt; &gt; Bitcoin.<br>
&gt;<br>
&gt; No, I wish to ensure that if the aim of the BIP is ensuring high-quali=
ty and readability of standards those ones are well-written, including when=
 the original standard is contributed by someone non-native.<br>
&gt; I can only remember numerous times when my english technical texts hav=
e been kindly corrected by other contributors. Having editors understanding=
 multiple languages helps in quality redaction.<br>
&gt;<br>
&gt; Beyond, from reading conversations it sounds there is a disagreement i=
f it&#39;s an administrative task (i.e &quot;assigning numbers&quot;) or ed=
itorial one (i.e &quot;high-quality, well-written standards&quot;).<br>
&gt;<br>
&gt; If we wish to make things less bureaucratic, we might actually separat=
e the two tasks with different groups of BIP process maintainers :<br>
&gt; - assign temporary numbers for experimentation<br>
&gt; - wait for more-or-less finalized drafts written in a quality fashion<=
br>
&gt; - assign final numbers for standard candidate deployment<br>
&gt;<br>
&gt; If you see other ways to dissociate the roles and make things less bur=
eaucratic ? E.g having people only in charge of triage.<br>
&gt; If I remember correctly the IETF does not assign RFC numbers for draft=
 proposals, and you generally have years of experimentation.<br>
&gt;<br>
&gt; Best,<br>
&gt; Antoine<br>
&gt;<br>
&gt; PS: By the way, even at the United Nations, unanimity is not the rule,=
 it&#39;s two-third of the general assembly. I think your analogy is not va=
lid.<br>
&gt;<br>
&gt; Le sam. 30 mars 2024 =C3=A0 11:52, Michael Folkson &lt;<a href=3D"mail=
to:michaelfolkson@gmail.com" target=3D"_blank">michaelfolkson@gmail.com</a>=
&gt; a =C3=A9crit :<br>
&gt;&gt;<br>
&gt;&gt; &gt; In a world where both Core and BIP repository are living unde=
r a single Github organization, I don&#39;t think in matters that much as t=
he highest privilege account will be able to<br>
&gt;&gt; override any BIP merging decision, or even remove on the flight BI=
P<br>
&gt;&gt; editors rights in case of conflicts or controversies. If you&#39;r=
e<br>
&gt;&gt; raising the issue that the BIP repository should be moved to its o=
wn<br>
&gt;&gt; GH repository I think it&#39;s a valuable point.<br>
&gt;&gt;<br>
&gt;&gt; In the past there have been disagreements between Core maintainers=
 and<br>
&gt;&gt; BIP editors (e.g. Luke with Taproot activation params) and those C=
ore<br>
&gt;&gt; maintainers haven&#39;t merged pull requests in the BIPs repo or r=
emoved<br>
&gt;&gt; him as a BIP editor. As long as that continues it isn&#39;t necess=
ary to<br>
&gt;&gt; create a new GitHub organization for the BIPs repo. They are separ=
ate<br>
&gt;&gt; repos with different maintainers/editors but under the same<br>
&gt;&gt; organization and everyone knows where it is located.<br>
&gt;&gt;<br>
&gt;&gt; &gt; Beyond, I still think we should ensure we have a wider crowd =
of geographically and culturally diverse BIP editors. As if the role is ens=
uring high-quality and readability of the terminology of the standards, we =
might have highly-skilled technical BIP champions which are not English nat=
ive. With the current set of proposed BIP editors, to the best of my knowle=
dge, at least we have few langages spoken by the candidates: Dutch, French,=
 German, Spanish. This can be very helpful to translate concepts devised in=
 language A to technical english.<br>
&gt;&gt;<br>
&gt;&gt; It seems like you want to create some kind of United Nations for t=
he<br>
&gt;&gt; BIP process. As I said previously this is almost entirely an<br>
&gt;&gt; administrative task. Going to a committee of 10 people with differ=
ent<br>
&gt;&gt; nationalities and languages to decide whether something should get=
 a<br>
&gt;&gt; BIP number is absurd. If you think Luke is slow to respond wait un=
til<br>
&gt;&gt; your United Nations of the BIP process has to all agree to assign =
a<br>
&gt;&gt; BIP number. Please don&#39;t try to make this unnecessarily bureau=
cratic<br>
&gt;&gt; and political for no reason. There&#39;s enough of that outside of=
<br>
&gt;&gt; Bitcoin.<br>
&gt;&gt;<br>
&gt;&gt; On Fri, Mar 29, 2024 at 9:14=E2=80=AFPM Antoine Riard &lt;<a href=
=3D"mailto:antoine.riard@gmail.com" target=3D"_blank">antoine.riard@gmail.c=
om</a>&gt; wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; &gt; Roasbeef&#39;s work on alternative clients and lightning=
 make him technically<br>
&gt;&gt; &gt; useful<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I think one of the aim of the BIP process is to harmonize com=
mon mechanisms among Bitcoin clients of different langages breeds or at dif=
ferent layers (wallet / full-node).<br>
&gt;&gt; &gt; Having someone among BIP editors with a proven track record o=
f contributing to other full-node codebase beyond C++ can be valuable in th=
at sense.<br>
&gt;&gt; &gt; Especially for all matters related to compatibility and deplo=
yment.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; &gt; For example I think Jon Atack would make a great Core ma=
intainer at some point in the future and I&#39;m not sure a BIP editor shou=
ld also be a Core maintainer given the<br>
&gt;&gt; &gt; &gt; independence sometimes required between Core and the BIP=
 process<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; In a world where both Core and BIP repository are living unde=
r a single Github organization, I don&#39;t think in matters that much as t=
he highest privilege account will be able to<br>
&gt;&gt; &gt; override any BIP merging decision, or even remove on the flig=
ht BIP editors rights in case of conflicts or controversies. If you&#39;re =
raising the issue that the BIP repository should be moved to its own GH rep=
ository I think it&#39;s a valuable point.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Beyond, I still think we should ensure we have a wider crowd =
of geographically and culturally diverse BIP editors. As if the role is ens=
uring high-quality and readability of the terminology of the standards, we =
might have highly-skilled technical BIP champions which are not English nat=
ive. With the current set of proposed BIP editors, to the best of my knowle=
dge, at least we have few langages spoken by the candidates: Dutch, French,=
 German, Spanish. This can be very helpful to translate concepts devised in=
 language A to technical english.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Best,<br>
&gt;&gt; &gt; Antoine<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Le vendredi 29 mars 2024 =C3=A0 12:33:09 UTC, /dev /fd0 a =C3=
=A9crit :<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Justification:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; 1. Jon Atack: Good at avoiding controversies and technica=
l documentation.<br>
&gt;&gt; &gt;&gt; 2. Roasbeef: Since BIPs are not just related to bitcoin c=
ore, it&#39;s good to have btcd maintainer as a BIP editor.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; On Friday, March 29, 2024 at 1:47:41=E2=80=AFAM UTC+5:30 =
Matt Corallo wrote:<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Please provide justification rather than simply sayin=
g &quot;I like Bob!&quot;.<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Matt<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; On 3/28/24 12:09 PM, /dev /fd0 wrote:<br>
&gt;&gt; &gt;&gt;&gt; &gt; I support Jon Atack and Roasbeef from this list.=
<br>
&gt;&gt; &gt;&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt;&gt; &gt; On Thursday, March 28, 2024 at 6:57:53=E2=80=AFP=
M UTC+5:30 Murch wrote:<br>
&gt;&gt; &gt;&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt;&gt; &gt; I just went through the thread, previously menti=
oned were:<br>
&gt;&gt; &gt;&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt;&gt; &gt; - Kanzure<br>
&gt;&gt; &gt;&gt;&gt; &gt; - Ruben Somsen<br>
&gt;&gt; &gt;&gt;&gt; &gt; - Greg Tonoski<br>
&gt;&gt; &gt;&gt;&gt; &gt; - Jon Atack<br>
&gt;&gt; &gt;&gt;&gt; &gt; - Roasbeef<br>
&gt;&gt; &gt;&gt;&gt; &gt; - Seccour<br>
&gt;&gt; &gt;&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt;&gt; &gt; And Matt just suggested me for the role. Hope I =
didn=E2=80=99t overlook anyone.<br>
&gt;&gt; &gt;&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt;&gt; &gt; On 3/27/24 19:39, John C. Vernaleo wrote:<br>
&gt;&gt; &gt;&gt;&gt; &gt; &gt; That said, I would find it helpful if someo=
ne could go through the<br>
&gt;&gt; &gt;&gt;&gt; &gt; &gt; thread and list all the people who&#39;ve b=
een proposed so people know who<br>
&gt;&gt; &gt;&gt;&gt; &gt; &gt; they should be thinking about.<br>
&gt;&gt; &gt;&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt;&gt; &gt; --<br>
&gt;&gt; &gt;&gt;&gt; &gt; You received this message because you are subscr=
ibed to the Google Groups &quot;Bitcoin Development<br>
&gt;&gt; &gt;&gt;&gt; &gt; Mailing List&quot; group.<br>
&gt;&gt; &gt;&gt;&gt; &gt; To unsubscribe from this group and stop receivin=
g emails from it, send an email to<br>
&gt;&gt; &gt;&gt;&gt; &gt; <a href=3D"mailto:bitcoindev%2B...@googlegroups.=
com" target=3D"_blank">bitcoindev+...@googlegroups.com</a> &lt;mailto:<a hr=
ef=3D"mailto:bitcoindev%2B...@googlegroups.com" target=3D"_blank">bitcoinde=
v+...@googlegroups.com</a>&gt;.<br>
&gt;&gt; &gt;&gt;&gt; &gt; To view this discussion on the web visit<br>
&gt;&gt; &gt;&gt;&gt; &gt; <a href=3D"https://groups.google.com/d/msgid/bit=
coindev/4c1462b7-ea1c-4a36-be81-7c3719157fabn%40googlegroups.com" rel=3D"no=
referrer" target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/4c=
1462b7-ea1c-4a36-be81-7c3719157fabn%40googlegroups.com</a> &lt;<a href=3D"h=
ttps://groups.google.com/d/msgid/bitcoindev/4c1462b7-ea1c-4a36-be81-7c37191=
57fabn%40googlegroups.com?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=
=3D"noreferrer" target=3D"_blank">https://groups.google.com/d/msgid/bitcoin=
dev/4c1462b7-ea1c-4a36-be81-7c3719157fabn%40googlegroups.com?utm_medium=3De=
mail&amp;utm_source=3Dfooter</a>&gt;.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; --<br>
&gt;&gt; &gt; You received this message because you are subscribed to the G=
oogle Groups &quot;Bitcoin Development Mailing List&quot; group.<br>
&gt;&gt; &gt; To unsubscribe from this group and stop receiving emails from=
 it, send an email to <a href=3D"mailto:bitcoindev%2Bunsubscribe@googlegrou=
ps.com" target=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
&gt;&gt; &gt; To view this discussion on the web visit <a href=3D"https://g=
roups.google.com/d/msgid/bitcoindev/f8fa1a55-644f-4cf1-b8c1-4fdef22d1869n%4=
0googlegroups.com" rel=3D"noreferrer" target=3D"_blank">https://groups.goog=
le.com/d/msgid/bitcoindev/f8fa1a55-644f-4cf1-b8c1-4fdef22d1869n%40googlegro=
ups.com</a>.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; Michael Folkson<br>
&gt;&gt; Personal email: <a href=3D"mailto:michaelfolkson@gmail.com" target=
=3D"_blank">michaelfolkson@gmail.com</a><br>
<br>
<br>
<br>
-- <br>
Michael Folkson<br>
Personal email: <a href=3D"mailto:michaelfolkson@gmail.com" target=3D"_blan=
k">michaelfolkson@gmail.com</a><br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/CALZpt%2BF%3DdUVn6bDLewjVVHGymhqYZgHQZ4yX%2BtfAPWx9gH=
_pzA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://group=
s.google.com/d/msgid/bitcoindev/CALZpt%2BF%3DdUVn6bDLewjVVHGymhqYZgHQZ4yX%2=
BtfAPWx9gH_pzA%40mail.gmail.com</a>.<br />

--00000000000036c13106150ea38f--