From: Antoine Riard <antoine.riard@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Adding New BIP Editors
Date: Wed, 24 Apr 2024 23:42:56 -0700 (PDT) [thread overview]
Message-ID: <a32f9994-059d-44dd-83c7-c3bb732888adn@googlegroups.com> (raw)
In-Reply-To: <ZigzHENxN5F5Uqs/@erisian.com.au>
[-- Attachment #1.1: Type: text/plain, Size: 5477 bytes --]
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 à 16:36:38 UTC+1, Anthony Towns a écrit :
> On Sat, Apr 20, 2024 at 07:14:34PM +0000, 'Ava Chow' via Bitcoin
> 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
>
>
--
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/a32f9994-059d-44dd-83c7-c3bb732888adn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 6648 bytes --]
next prev parent reply other threads:[~2024-04-25 10:46 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-27 18:53 [bitcoindev] " 'Ava Chow' via Bitcoin Development Mailing List
2024-02-27 20:11 ` [bitcoindev] " 'Léo Haf' via Bitcoin Development Mailing List
2024-02-27 22:40 ` Luke Dashjr
2024-02-27 22:57 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-02-27 23:26 ` Steve Lee
2024-02-28 11:12 ` bitcoin-dev-ml.void867 via Bitcoin Development Mailing List
2024-02-28 16:31 ` Tim Ruffing
2024-03-07 20:56 ` Antoine Riard
2024-03-14 11:56 ` Chris Stewart
2024-03-27 21:25 ` Murch
2024-03-27 23:36 ` Keagan McClelland
2024-03-27 23:39 ` John C. Vernaleo
2024-03-28 13:02 ` Murch
2024-03-28 16:09 ` /dev /fd0
2024-03-28 20:04 ` Matt Corallo
2024-03-28 20:31 ` Antoine Riard
2024-03-28 20:59 ` John C. Vernaleo
2024-03-28 21:19 ` Matt Corallo
2024-03-29 2:34 ` Michael Folkson
2024-03-29 5:24 ` /dev /fd0
2024-03-29 21:08 ` Antoine Riard
2024-03-30 11:51 ` Michael Folkson
2024-03-30 20:01 ` Antoine Riard
2024-03-31 16:01 ` Michael Folkson
2024-04-01 20:14 ` Antoine Riard
2024-04-07 10:11 ` Ali Sherief
2024-04-01 21:13 ` David A. Harding
2024-04-01 23:55 ` /dev /fd0
2024-04-02 0:37 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-02 13:49 ` /dev /fd0
2024-04-02 14:28 ` Luke Dashjr
2024-04-02 15:13 ` Gloria Zhao
2024-04-02 15:39 ` Luke Dashjr
2024-04-03 15:03 ` Murch
2024-04-02 8:18 ` Michael Folkson
2024-04-02 14:24 ` nvk
2024-04-11 14:22 ` Sergi Delgado Segura
2024-04-15 17:50 ` Matt Corallo
2024-04-16 12:34 ` Tim Ruffing
2024-04-16 13:32 ` NVK
2024-04-16 17:08 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-17 23:58 ` 'nsvrn' via Bitcoin Development Mailing List
2024-04-19 22:32 ` Olaoluwa Osuntokun
2024-04-20 19:14 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-20 19:48 ` NVK
2024-04-20 19:59 ` Michael Folkson
2024-04-20 20:59 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-20 20:46 ` Steve Lee
2024-04-20 21:08 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-20 21:11 ` Steve Lee
2024-04-20 21:37 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-20 22:03 ` Steve Lee
2024-04-20 22:47 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-22 2:44 ` Steve Lee
2024-04-20 22:21 ` Michael Folkson
2024-04-20 23:05 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-21 11:43 ` Michael Folkson
2024-04-21 16:39 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-21 17:57 ` Michael Folkson
2024-04-21 18:47 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-21 19:18 ` Michael Folkson
2024-04-21 20:48 ` Antoine Riard
2024-04-21 23:01 ` Matt Corallo
2024-04-22 0:06 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-22 4:28 ` Ali Sherief
2024-04-23 22:15 ` Anthony Towns
2024-04-25 6:42 ` Antoine Riard [this message]
2024-03-29 22:17 ` Keagan McClelland
2024-03-30 4:04 ` Peter Todd
2024-04-01 18:42 ` Jonas Nick
2024-03-27 23:54 ` Matt Corallo
2024-03-28 15:50 ` Brandon Black
2024-03-28 19:42 ` Antoine Riard
2024-03-28 20:04 ` Matt Corallo
2024-04-02 13:17 ` [bitcoindev] Time for an update to BIP2? Tim Ruffing
2024-04-03 19:44 ` Pieter Wuille
2024-04-04 5:00 ` Anthony Towns
2024-04-04 9:09 ` Niklas Goegge
2024-04-04 12:58 ` [bitcoindev] Adding New BIP Editors 0xB10C
2024-05-13 18:33 ` [bitcoindev] Time for an update to BIP2? Murch
2024-04-01 18:41 ` [bitcoindev] Re: Adding New BIP Editors Murch
2024-03-31 17:01 ` 'Ava Chow' via Bitcoin Development Mailing List
2024-04-01 6:21 ` /dev /fd0
2024-04-01 11:58 ` Michael Folkson
2024-04-03 16:58 ` Juan Galt
2024-04-03 17:24 ` Vasil Dimov
2024-04-03 18:34 ` 'Fabian' via Bitcoin Development Mailing List
2024-03-07 22:39 ` Keagan McClelland
2024-02-27 21:33 ` [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List
2024-02-27 21:48 ` Greg Tonoski
2024-02-27 23:10 ` [bitcoindev] " /dev /fd0
2024-02-28 4:22 ` /dev /fd0
2024-03-09 10:46 ` Michael Folkson
2024-03-10 17:27 ` Bitcoin Error Log
2024-03-11 16:48 ` Jon A
2024-04-05 19:18 ` Larry Ruane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a32f9994-059d-44dd-83c7-c3bb732888adn@googlegroups.com \
--to=antoine.riard@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox