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
|
Delivery-date: Thu, 25 Apr 2024 03:46:51 -0700
Received: from mail-yw1-f188.google.com ([209.85.128.188])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBC3PT7FYWAMRBE7JVCYQMGQEFRSP6GQ@googlegroups.com>)
id 1rzwcs-00027Z-7P
for bitcoindev@gnusha.org; Thu, 25 Apr 2024 03:46:50 -0700
Received: by mail-yw1-f188.google.com with SMTP id 00721157ae682-61b17188625sf1879877b3.2
for <bitcoindev@gnusha.org>; Thu, 25 Apr 2024 03:46:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1714042004; x=1714646804; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:sender:from
:to:cc:subject:date:message-id:reply-to;
bh=o2u31v4DEilKim/dEKPPG3CIEbqHRX9t3TbkYmS2i9U=;
b=uyIrQUqkyBTKi5knmPyMhj57lPETLA21HGd3TB+1+qBh51/ixyghE6UeL9Dn+w5zFB
qC0NVN72Yc0fRN9LnVV7CJ9gSclWMg2aATUuygfwD/IkwPK+W+oeGAnQ2L8otXOkMPda
QnoqFFybpMWf5Tk2roMhVnTOBG11gr4ta4ylqyAP3SxhIOMHAC1e0CEojtGlq2f+iqZE
CkdVlAKhlKjIRg9lvLHp5J4OhnlYRjB52OamgB9f4Ckj/71awrL0O/nketlCJXjqcW3R
kc0+eGnBOwJ9QGpRiYbaACrRGKmGaxeuUYBgmVBfWDLisZKgrUIT6x3xk7L6YzfqEiwC
BVrg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1714042004; x=1714646804; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:from:to:cc
:subject:date:message-id:reply-to;
bh=o2u31v4DEilKim/dEKPPG3CIEbqHRX9t3TbkYmS2i9U=;
b=ZXZgizpfWeeFuMULz1zHLuYu/hfYyrH4uI/OpksDEHsVBvoXW7vNq4p/6rdOFi6dyt
PMGbhTFXI6rrHTl7uyPewSz75bIi65jzrLPycAKHahheE3Hokllgkn6r/MAfl/t9cLkM
QzqIXS8/nkZP5YtOgmw6FtRbOFU+8hAKoSIE5wjAq8e8dvyDHOPID/M+aRHxRVV8qE0L
SNDoMzicFtEkomiwel8MdMPAAfRg/B52yR9tUd/WwRffn+bzLgU20r2xlXS3CHoxiYdc
LXuLMMxzftdfNkeUmqpv6vDFXhF4r8DGxy90DkIPU6TimltHr+vmd8EpdTlN8LP9XH+S
MLBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1714042004; x=1714646804;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:x-beenthere
:x-gm-message-state:sender:from:to:cc:subject:date:message-id
:reply-to;
bh=o2u31v4DEilKim/dEKPPG3CIEbqHRX9t3TbkYmS2i9U=;
b=c8g4k65/Sp//cdf7E3FXk/bhJbXejMb/4giNuMMR3wYBVfH+kgGndIu3O+/MtSHcK6
Jp6KpAMjqogeAyowI/NiNDP4MNLpHm4jXYFnXyz/re7opys1G1+AeamPxfTon7qOjb0r
NRyb6U5Rzc25dSFsyu4uI9Daa23a0GgT1gHAkkJGUJH6Stmf/hIt8YAEckC3pEzGsGdy
QhZP2Tbqf3AegLy+sg4XKhAcinZV8ExTEynV+dDrevx3bOLaRWWTyueA3NC4uKJx4edb
MJkoKNmbv40k5PgbBPIFvfNWLe2NPid9JJK6/FUBYyYeKCO55389DL1NSlP/cp12X9v9
51YQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCX6T4yV1YfT2zdfiMkekxupc0Lx9UmyG5ojEyeQQeP2a0OiE14aK0A4q4PvO6ksLEs1O31wn5OeB66v+svuDFudMbaqDFY=
X-Gm-Message-State: AOJu0YxVLwN62tW0Pi2WclNifXW5PdiyJ+eePMbbPKZrWQQKqnIzPqwu
0Q+PyokuY8ZRYm1n+m1WLvyTevqeVDgWo6H3cGlar+HNyEFPmE09
X-Google-Smtp-Source: AGHT+IHBT9uPAiJwdnEgrrNyRYKxkqlUHxO/4Xz4/1C3IASRONrsxGPTv50LTiJfixT+BuhUxiVvKA==
X-Received: by 2002:a25:6b44:0:b0:de5:4f72:46bf with SMTP id o4-20020a256b44000000b00de54f7246bfmr4300355ybm.5.1714042004308;
Thu, 25 Apr 2024 03:46:44 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:db09:0:b0:dcd:a08f:c83a with SMTP id 3f1490d57ef6-de5861e7b04ls1211229276.2.-pod-prod-05-us;
Thu, 25 Apr 2024 03:46:42 -0700 (PDT)
X-Received: by 2002:a81:7155:0:b0:615:130a:2503 with SMTP id m82-20020a817155000000b00615130a2503mr1246257ywc.8.1714042002803;
Thu, 25 Apr 2024 03:46:42 -0700 (PDT)
Received: by 2002:a05:690c:fca:b0:611:2a20:d0cc with SMTP id 00721157ae682-61b84d1e16dms7b3;
Wed, 24 Apr 2024 23:42:58 -0700 (PDT)
X-Received: by 2002:a05:6902:72c:b0:dda:c4ec:7db5 with SMTP id l12-20020a056902072c00b00ddac4ec7db5mr653347ybt.4.1714027377096;
Wed, 24 Apr 2024 23:42:57 -0700 (PDT)
Date: Wed, 24 Apr 2024 23:42:56 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <a32f9994-059d-44dd-83c7-c3bb732888adn@googlegroups.com>
In-Reply-To: <ZigzHENxN5F5Uqs/@erisian.com.au>
References: <070755a0-10e9-4903-9524-dd8ef98c1c8b@achow101.com>
<ZigzHENxN5F5Uqs/@erisian.com.au>
Subject: Re: [bitcoindev] Re: Adding New BIP Editors
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_49814_1790430370.1714027376707"
X-Original-Sender: antoine.riard@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 (/)
------=_Part_49814_1790430370.1714027376707
Content-Type: multipart/alternative;
boundary="----=_Part_49815_1746854077.1714027376707"
------=_Part_49815_1746854077.1714027376707
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi AJ,
> When choosing personnel, asking for public objections is probably a
> pretty bad approach. It's hurtful to the person being objected to, both
> when the objections are accurate and when they aren't, and, especially
> if the objections end up being ignored, it's harmful to the working
> environment when the person who objected has to work with the person
> they objected to in future.
>
> Personally, I'd suggest focussing more on "are they demonstrably doing
> useful work? yes, then they keep or increase their perms; no, then
> decrease their perms". (Probably couldn't have done anything different
> this time around, but maybe something to keep in mind for the future)
> Along those lines, it might be worth having a review in six months or
> so to see which of the editors and processes have been effective, and
> which ones haven't, and see if there's anything worth changing further
> to increase the wins and diminish the losses. Could be worth making
> something like that a regular thing (once a year?); for the Debian
> Technical Committee, we had somewhat similar problems with inactivity
> and a lack of renewal, which (IMO) was fixed in a big part just by
> having a policy of saying "okay, longest serving member gets booted,
> remaining folks should invite someone new" once a year.
I'm respectfully dissenting here. Decade(s)-old IETF / BIP standards
are kinda open-source commons after-all, and this is very expected than
someone who is aspiring to get perms in their maintenance have to answer
objections from the non-permissioned people enjoying usage of the
commons.
Yes, it can hurt to have to answers public objections on your person
when you're aspiring to open-source perms. I think that's part of the
process, if you wish a comfortable job you can always go to work at
$YOUR_LOCAL_BIG_TECH (tm). Additionally, one can wish to be sure
that the candidate have sufficient level of ethics / personal integrity.
Especially, to serve as a check-and-balance when one has to conduct
privileged actions in the execution of permissions.
W.r.t, I can only invite anyone to read the ACM Code of Ethics:
https://www.acm.org/code-of-ethics
(Far from perfect as ethics is a dynamic concept after-all, though can
provide guidelines if you're entitled with perms in this space, and you
don't know how to act in a given instance).
Apart of that, I think the idea of the longest serving members in a
set of maintainers / editors without substantial activity getting booted
every X and remaining folks can invite someone new can serve as a not
so bad rule of thumb.
To conclude, I'm rejoicing too on seeing concrete results in the nomination
of BIP editors, which doesn't forbid ulterior discussions on improving its
process.
Best,
Antoine
Le mercredi 24 avril 2024 =C3=A0 16:36:38 UTC+1, Anthony Towns a =C3=A9crit=
:
> On Sat, Apr 20, 2024 at 07:14:34PM +0000, 'Ava Chow' via Bitcoin=20
> Development 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 last email.
> > As such, there is rough consensus on adding Kanzure, Murch, Jonatack,
> > Ruben, and Roasbeef as BIP editors, and they will be added on Monday
> > April 22nd.
>
> Thanks for pushing this forward, Ava!
>
> One thing though:
>
> > There has not been any actual objections to the nominees nor have there
>
> When choosing personnel, asking for public objections is probably a
> pretty bad approach. It's hurtful to the person being objected to, both
> when the objections are accurate and when they aren't, and, especially
> if the objections end up being ignored, it's harmful to the working
> environment when the person who objected has to work with the person
> they objected to in future.
>
> Personally, I'd suggest focussing more on "are they demonstrably doing
> useful work? yes, then they keep or increase their perms; no, then
> decrease their perms". (Probably couldn't have done anything different
> this time around, but maybe something to keep in mind for the future)
>
> Along those lines, it might be worth having a review in six months or
> so to see which of the editors and processes have been effective, and
> which ones haven't, and see if there's anything worth changing further
> to increase the wins and diminish the losses. Could be worth making
> something like that a regular thing (once a year?); for the Debian
> Technical Committee, we had somewhat similar problems with inactivity
> and a lack of renewal, which (IMO) was fixed in a big part just by
> having a policy of saying "okay, longest serving member gets booted,
> remaining folks should invite someone new" once a year.
>
> Anyway, it's easy to quibble about what the best process might be,
> but actual results are more important, so thanks again Ava!
>
> Cheers,
> aj
>
>
--=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/a32f9994-059d-44dd-83c7-c3bb732888adn%40googlegroups.com.
------=_Part_49815_1746854077.1714027376707
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi AJ,<div><br /></div><div>> When choosing personnel, asking for public=
objections is probably a<br />> pretty bad approach. It's hurtful to th=
e person being objected to, both<br />> when the objections are accurate=
and when they aren't, and, especially<br />> if the objections end up b=
eing ignored, it's harmful to the working<br />> environment when the pe=
rson who objected has to work with the person<br />> they objected to in=
future.<br />><br />> Personally, I'd suggest focussing more on "are=
they demonstrably doing<br />> useful work? yes, then they keep or incr=
ease their perms; no, then<br />> decrease their perms". (Probably could=
n't have done anything different<br />> this time around, but maybe some=
thing to keep in mind for the future)<br /><br />> Along those lines, it=
might be worth having a review in six months or<br />> so to see which =
of the editors and processes have been effective, and<br />> which ones =
haven't, and see if there's anything worth changing further<br />> to in=
crease the wins and diminish the losses. Could be worth making<br />> so=
mething like that a regular thing (once a year?); for the Debian<br />> =
Technical Committee, we had somewhat similar problems with inactivity<br />=
> and a lack of renewal, which (IMO) was fixed in a big part just by<br =
/>> having a policy of saying "okay, longest serving member gets booted,=
<br />> remaining folks should invite someone new" once a year.</div><di=
v><br /></div><div>I'm respectfully dissenting here. Decade(s)-old IETF / B=
IP standards</div><div>are kinda open-source commons after-all, and this is=
very expected than</div><div>someone who is aspiring to get perms in their=
maintenance have to answer</div><div>objections from the non-permissioned =
people enjoying =C2=A0usage of the</div><div>commons.</div><div><br /></div=
><div>Yes, it can hurt to have to answers public objections on your person<=
/div><div>when you're aspiring to open-source perms. I think that's part of=
the</div><div>process, if you wish a comfortable job you can always go to =
work at</div><div>$YOUR_LOCAL_BIG_TECH (tm). Additionally, one can wish to =
be sure</div><div>that the candidate have sufficient level of ethics / pers=
onal integrity.</div><div>Especially, to serve as a check-and-balance when =
one has to conduct</div><div>privileged actions in the execution of permiss=
ions.</div><div><br /></div><div>W.r.t, I can only invite anyone to read th=
e ACM Code of Ethics:</div><div>https://www.acm.org/code-of-ethics</div><di=
v><br /></div><div>(Far from perfect as ethics is a dynamic concept after-a=
ll, though can</div><div>provide guidelines if you're entitled with perms i=
n this space, and you</div><div>don't know how to act in a given instance).=
</div><div><br /></div><div>Apart of that, I think the idea of the longest =
serving members in a</div><div>set of maintainers / editors without substan=
tial activity getting booted</div><div>every X and remaining folks can invi=
te someone new can serve as a not</div><div>so bad rule of thumb.</div><div=
><br /></div><div>To conclude, I'm rejoicing too on seeing concrete results=
in the nomination</div><div>of BIP editors, which doesn't forbid ulterior =
discussions on improving its</div><div>process.</div><div><br /></div><div>=
Best,</div><div>Antoine</div><div><br /></div><div class=3D"gmail_quote"><d=
iv dir=3D"auto" class=3D"gmail_attr">Le mercredi 24 avril 2024 =C3=A0 16:36=
:38 UTC+1, Anthony Towns a =C3=A9crit=C2=A0:<br/></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204,=
204, 204); padding-left: 1ex;">On Sat, Apr 20, 2024 at 07:14:34PM +0000, &=
#39;Ava Chow' via Bitcoin Development Mailing List wrote:
<br>> Since we're now past the deadline of April 19th, I'd like =
to inform
<br>> everyone of what will happen on Monday.
<br>>
<br>> There has not been any actual objections to the nominees nor have =
there
<br>> been any suggestions on choosing a subset of them since my last em=
ail.
<br>> As such, there is rough consensus on adding Kanzure, Murch, Jonata=
ck,
<br>> Ruben, and Roasbeef as BIP editors, and they will be added on Mond=
ay
<br>> April 22nd.
<br>
<br>Thanks for pushing this forward, Ava!
<br>
<br>One thing though:
<br>
<br>> There has not been any actual objections to the nominees nor have =
there
<br>
<br>When choosing personnel, asking for public objections is probably a
<br>pretty bad approach. It's hurtful to the person being objected to, =
both
<br>when the objections are accurate and when they aren't, and, especia=
lly
<br>if the objections end up being ignored, it's harmful to the working
<br>environment when the person who objected has to work with the person
<br>they objected to in future.
<br>
<br>Personally, I'd suggest focussing more on "are they demonstrab=
ly doing
<br>useful work? yes, then they keep or increase their perms; no, then
<br>decrease their perms". (Probably couldn't have done anything d=
ifferent
<br>this time around, but maybe something to keep in mind for the future)
<br>
<br>Along those lines, it might be worth having a review in six months or
<br>so to see which of the editors and processes have been effective, and
<br>which ones haven't, and see if there's anything worth changing =
further
<br>to increase the wins and diminish the losses. Could be worth making
<br>something like that a regular thing (once a year?); for the Debian
<br>Technical Committee, we had somewhat similar problems with inactivity
<br>and a lack of renewal, which (IMO) was fixed in a big part just by
<br>having a policy of saying "okay, longest serving member gets boote=
d,
<br>remaining folks should invite someone new" once a year.
<br>
<br>Anyway, it's easy to quibble about what the best process might be,
<br>but actual results are more important, so thanks again Ava!
<br>
<br>Cheers,
<br>aj
<br>
<br></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List" 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/a32f9994-059d-44dd-83c7-c3bb732888adn%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/a32f9994-059d-44dd-83c7-c3bb732888adn%40googlegroups.com</a>.=
<br />
------=_Part_49815_1746854077.1714027376707--
------=_Part_49814_1790430370.1714027376707--
|