another heave on the co-chair selection procedure
Colleagues, the selection process needs another nudge. Although there have been a few expressions of support and no objections, I’m reluctant to declare consensus because only a handful of people have spoken. I’d *really* like to declare victory so we can get on with the job of finding a co-chair. It’s uncomfortable to do this when the WG has argely been silent about how the leadership is selected. So could you please indicate your support or opposition to the following? Thanks. I would also ask the WG to avoid the temptation to rat-hole or over-think the selection procedure, for instance by proposing elaborate steps to apply in corner cases that in all probability will never arise. We're only appointing a WG co-chair, not the Internet's Supreme-Leader-for-Life. The WG can always change the suggested process later if practical experience proves it is broken or needs improvement. Note too that there is no mention of elections or votes. This is deliberate. (1) The IoT WG will have 2 co-chairs who serve staggered 2-year terms. (2) A co-chair cannot serve more than 3 consecutive terms. (3) Each year, the longest serving co-chair will stand down and subject to (2) may make themselves available for re-appointment. (4) The incoming co-chair will be chosen by the WG using consensus and the remaining co-chair will make the consensus determination. (5) Any circumstances not covered by the above will be resolved by the RIPE Chair whose decision will be final. Vote early, vote often. Well OK, we don’t vote but I hope you get the point. :-)
I support this. best regards Wolfgang
On 9. Oct 2018, at 16:27, Jim Reid <jim@rfc1035.com> wrote:
(1) The IoT WG will have 2 co-chairs who serve staggered 2-year terms. (2) A co-chair cannot serve more than 3 consecutive terms. (3) Each year, the longest serving co-chair will stand down and subject to (2) may make themselves available for re-appointment. (4) The incoming co-chair will be chosen by the WG using consensus and the remaining co-chair will make the consensus determination. (5) Any circumstances not covered by the above will be resolved by the RIPE Chair whose decision will be final.
-- Wolfgang Tremmel Phone +49 69 1730902 26 | Fax +49 69 4056 2716 | Mobile +49 171 8600 816 | wolfgang.tremmel@de-cix.net Geschaeftsfuehrer Harald A. Summa | Registergericht AG Köln HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net
+1 for support! Cheers matthias On Tue, 9 Oct 2018, Wolfgang Tremmel wrote:
I support this.
best regards Wolfgang
On 9. Oct 2018, at 16:27, Jim Reid <jim@rfc1035.com> wrote:
(1) The IoT WG will have 2 co-chairs who serve staggered 2-year terms. (2) A co-chair cannot serve more than 3 consecutive terms. (3) Each year, the longest serving co-chair will stand down and subject to (2) may make themselves available for re-appointment. (4) The incoming co-chair will be chosen by the WG using consensus and the remaining co-chair will make the consensus determination. (5) Any circumstances not covered by the above will be resolved by the RIPE Chair whose decision will be final.
-- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl
Hi, looks like a very reasonable approach to me, so +1 for the outlined process. cheers Enno On Tue, Oct 09, 2018 at 05:10:57PM +0200, Matthias Waehlisch wrote:
+1 for support!
Cheers matthias
On Tue, 9 Oct 2018, Wolfgang Tremmel wrote:
I support this.
best regards Wolfgang
On 9. Oct 2018, at 16:27, Jim Reid <jim@rfc1035.com> wrote:
(1) The IoT WG will have 2 co-chairs who serve staggered 2-year terms. (2) A co-chair cannot serve more than 3 consecutive terms. (3) Each year, the longest serving co-chair will stand down and subject to (2) may make themselves available for re-appointment. (4) The incoming co-chair will be chosen by the WG using consensus and the remaining co-chair will make the consensus determination. (5) Any circumstances not covered by the above will be resolved by the RIPE Chair whose decision will be final.
-- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl
_______________________________________________ iot-wg mailing list iot-wg@ripe.net https://lists.ripe.net/mailman/listinfo/iot-wg
-- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Florian Grunow, Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator =======================================================
(1) The IoT WG will have 2 co-chairs who serve staggered 2-year terms. (2) A co-chair cannot serve more than 3 consecutive terms. (3) Each year, the longest serving co-chair will stand down and subject to (2) may make themselves available for re-appointment. (4) The incoming co-chair will be chosen by the WG using consensus and the remaining co-chair will make the consensus determination. (5) Any circumstances not covered by the above will be resolved by the RIPE Chair whose decision will be final.
I like this... +1 Nigel
Nigel Titley writes:
(1) The IoT WG will have 2 co-chairs who serve staggered 2-year terms. (2) A co-chair cannot serve more than 3 consecutive terms. (3) Each year, the longest serving co-chair will stand down and subject to (2) may make themselves available for re-appointment. (4) The incoming co-chair will be chosen by the WG using consensus and the remaining co-chair will make the consensus determination. (5) Any circumstances not covered by the above will be resolved by the RIPE Chair whose decision will be final.
I like this...
+1
+1, jaap
On 10/9/18 4:27 PM, Jim Reid wrote:
It’s uncomfortable to do this when the WG has argely been silent about how the leadership is selected.
the WG (or at the very least the list) has been pretty silent, period.
So could you please indicate your support or opposition to the following? Thanks.
I support this process.
(1) The IoT WG will have 2 co-chairs who serve staggered 2-year terms. (2) A co-chair cannot serve more than 3 consecutive terms. (3) Each year, the longest serving co-chair will stand down and subject to (2) may make themselves available for re-appointment. (4) The incoming co-chair will be chosen by the WG using consensus and the remaining co-chair will make the consensus determination. (5) Any circumstances not covered by the above will be resolved by the RIPE Chair whose decision will be final.
Jelte
Jim Reid <jim@rfc1035.com> writes:
(1) The IoT WG will have 2 co-chairs who serve staggered 2-year terms. (2) A co-chair cannot serve more than 3 consecutive terms. (3) Each year, the longest serving co-chair will stand down and subject to (2) may make themselves available for re-appointment. (4) The incoming co-chair will be chosen by the WG using consensus and the remaining co-chair will make the consensus determination. (5) Any circumstances not covered by the above will be resolved by the RIPE Chair whose decision will be final.
+1 Jens -- ---------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@quux.de | --------------- | ----------------------------------------------------------------------------
On Tue, Oct 09, 2018 at 03:27:52PM +0100, Jim Reid wrote:
(1) The IoT WG will have 2 co-chairs who serve staggered 2-year terms. (2) A co-chair cannot serve more than 3 consecutive terms. (3) Each year, the longest serving co-chair will stand down and subject to (2) may make themselves available for re-appointment. (4) The incoming co-chair will be chosen by the WG using consensus and the remaining co-chair will make the consensus determination. (5) Any circumstances not covered by the above will be resolved by the RIPE Chair whose decision will be final.
I do not especially like it, because other WGs have demonstrated that a consensus process for personnel decisions easily degenerates. However, I can live with that. For item (3) I think what is meant is that the alternate terms are maintained, not that the "longest serving co-chair" will have to repeatedly ask for reappointment. "The co-chair whose term is up" would sound better to my ears, at least. -Peter
On 09/10/18 16:29, Peter Koch wrote:
On Tue, Oct 09, 2018 at 03:27:52PM +0100, Jim Reid wrote:
(1) The IoT WG will have 2 co-chairs who serve staggered 2-year terms. (2) A co-chair cannot serve more than 3 consecutive terms. (3) Each year, the longest serving co-chair will stand down and subject to (2) may make themselves available for re-appointment. (4) The incoming co-chair will be chosen by the WG using consensus and the remaining co-chair will make the consensus determination. (5) Any circumstances not covered by the above will be resolved by the RIPE Chair whose decision will be final.
I do not especially like it, because other WGs have demonstrated that a consensus process for personnel decisions easily degenerates. However, I can live with that.
For item (3) I think what is meant is that the alternate terms are maintained, not that the "longest serving co-chair" will have to repeatedly ask for reappointment. "The co-chair whose term is up" would sound better to my ears, at least.
I hate to say this but Peter does have a point. We all understand what you mean but one of these days a nit-picking bike shedder will come along and we'll have to fix it. Peter's suggestion is sound, I think. You can tell it's a quiet day. Nigel
On 9 Oct 2018, at 16:45, Nigel Titley <nigel@titley.com> wrote:
"The co-chair whose term is up" would sound better to my ears, at least.
I hate to say this but Peter does have a point. We all understand what you mean but one of these days a nit-picking bike shedder will come along and we'll have to fix it. Peter's suggestion is sound, I think.
You can tell it's a quiet day.
Fixed in the next release. :-) Thanks Nigel and Peter.
Hi Jim, I also don't feel that consensus is the best available option for selecting people for positions. What could be used is anonymous voting ballots. I don't know what exactly software or platforms are used for that, but this is how we vote during elections at ICANN constituencies for example. And then the person is elected by the majority of votes. I believe it's better than consensus. With all the rest points I'm fine. Best, Olga 9 октября 2018, 18:45:12, от "Nigel Titley" <nigel@titley.com>: On 09/10/18 16:29, Peter Koch wrote:
On Tue, Oct 09, 2018 at 03:27:52PM +0100, Jim Reid wrote:
(1) The IoT WG will have 2 co-chairs who serve staggered 2-year terms. (2) A co-chair cannot serve more than 3 consecutive terms. (3) Each year, the longest serving co-chair will stand down and subject to (2) may make themselves available for re-appointment. (4) The incoming co-chair will be chosen by the WG using consensus and the remaining co-chair will make the consensus determination. (5) Any circumstances not covered by the above will be resolved by the RIPE Chair whose decision will be final.
I do not especially like it, because other WGs have demonstrated that a consensus process for personnel decisions easily degenerates. However, I can live with that.
For item (3) I think what is meant is that the alternate terms are maintained, not that the "longest serving co-chair" will have to repeatedly ask for reappointment. "The co-chair whose term is up" would sound better to my ears, at least.
I hate to say this but Peter does have a point. We all understand what you mean but one of these days a nit-picking bike shedder will come along and we'll have to fix it. Peter's suggestion is sound, I think. You can tell it's a quiet day. Nigel _______________________________________________ iot-wg mailing list iot-wg@ripe.net https://lists.ripe.net/mailman/listinfo/iot-wg
On 12 Oct 2018, at 15:26, Olga Kyryliuk <olga_kyryliuk@ukr.net> wrote:
I also don't feel that consensus is the best available option for selecting people for positions. What could be used is anonymous voting ballots. I don't know what exactly software or platforms are used for that, but this is how we vote during elections at ICANN constituencies for example. And then the person is elected by the majority of votes. I believe it's better than consensus.
Thanks for your reply Olga. RIPE has always used consensus for all important decisions: WG charters, policy making, selecting WG chairs, etc. If you want to change that, you will need to persuade the RIPE community -- by consensus! -- to agree to use some other mechanism. Voting at RIPE is not practical because there is no way of controlling who gets to vote or policing how often they do that. Since there's no membership or eligibility criteria, the concept of one member, one vote just doesn't make sense. Which is why we use consensus-based decision making for the big stuff. Many other institutions do that too, usually for similar reasons. I'm not sure how well your ICANN example could or would fit at RIPE. That's probably a discussion for another list and another place. If I understand your position correctly, you support the proposed selection procedure though you'd prefer the WG used voting instead of consensus. Is that right?
On Fri, Oct 12, 2018 at 07:59:41PM +0100, Jim Reid wrote:
RIPE has always used consensus for all important decisions: WG charters, policy making, selecting WG chairs, etc. If you want to change that, you will need to persuade the RIPE community -- by consensus! -- to agree to use some other mechanism.
I am not sure I understand this advice. To the best of my knowledge, the chair selection is agreed upon by the WG itself and there is no pre-approved toolbox to choose from, so I fail to see the need to convince the whole RIPE community first.
Voting at RIPE is not practical because there is no way of controlling who gets to vote or policing how often they do that. Since there's no membership or eligibility criteria, the concept of one member, one vote just doesn't make sense. Which is why we use consensus-based decision making for the big stuff. Many other institutions do that too, usually for similar reasons.
The fact that the constituency is not or only loosely defined is not the reason for a consensus based approach. Consensus is a process (of compromise) to balance interests in multiple dimensions. It is fairly applicable to binary decisions and has proven to not work well for assigning chair positions - unless you expect people to discuss each other's pros and cons in public and entertain the embarrasment of having all those highlights publicly archived to eternity on mailing lists or some video platform. To avoid that, there's always behind-the-curtain activity. Drawing lots is probably less painful. The current proposal qualifies, in my opinion, only because it is no worse than the approach chosen by most of the other WGs. -Peter (who pleas guilty as charged discussing meta rather than wg content)
Thanks for your comments Peter. As I said earlier, further discussion about RIPE decision making is inappropriate for this list. If you want to have that discussion, please take it elsewhere.
On Oct 12, 2018, at 21:59, Jim Reid <jim@rfc1035.com> wrote:
On 12 Oct 2018, at 15:26, Olga Kyryliuk <olga_kyryliuk@ukr.net> wrote:
I also don't feel that consensus is the best available option for selecting people for positions. What could be used is anonymous voting ballots. I don't know what exactly software or platforms are used for that, but this is how we vote during elections at ICANN constituencies for example. And then the person is elected by the majority of votes. I believe it's better than consensus.
Thanks for your reply Olga.
RIPE has always used consensus for all important decisions: WG charters, policy making, selecting WG chairs, etc.
I understand that this is one of the RIPE WG. But do we really MUST use consensus to select co-chair? Is there any document that defines such co-chair selection? I see voting as more clear and effective procedure. What should be done if WG has a member that disagree with any candidate (except him/her for example :) )?
If you want to change that, you will need to persuade the RIPE community -- by consensus! -- to agree to use some other mechanism. Voting at RIPE is not practical because there is no way of controlling who gets to vote or policing how often they do that. Since there's no membership or eligibility criteria, the concept of one member, one vote just doesn't make sense. Which is why we use consensus-based decision making for the big stuff. Many other institutions do that too, usually for similar reasons.
I'm not sure how well your ICANN example could or would fit at RIPE. That's probably a discussion for another list and another place.
If I understand your position correctly, you support the proposed selection procedure though you'd prefer the WG used voting instead of consensus. Is that right?
_______________________________________________ iot-wg mailing list iot-wg@ripe.net https://lists.ripe.net/mailman/listinfo/iot-wg
-- Best regards Taras Heichenko tasic@hostmaster.ua
On 15 Oct 2018, at 10:58, Taras Heichenko <tasic@hostmaster.ua> wrote:
I understand that this is one of the RIPE WG. But do we really MUST use consensus to select co-chair?
Nobody's suggested any other way of appointing the co-chairs of this WG. We appear to have reasonable support for the proposed procedure. Nobody's objected to it either. So on balance, I'd say yes, we must use consensus to select the co-chair(s). If you want to propose some other selection mechanism, feel free to circulate that and convince the WG your alternative would be better (for some definition of better) than what's already been proposed and seems to be generally acceptable. Please inform this list by the end of this week if you intend to do bring forward an alternative. We can't allow the WG to limp along without a selection procedure for much longer. This is now verging on the intolerable. And I *really* want another co-chair to share the load of running the WG.
Is there any document that defines such co-chair selection?
No. There are documents which define that. Each WG decides its own selection method. They have all independently chosen to use consensus.
I see voting as more clear and effective procedure.
Voting only makes sense when it's clear who gets to vote. That doesn't make sense at RIPE because there's no definition (or notion) of membership.
What should be done if WG has a member that disagree with any candidate (except him/her for example :) )?
The same as what happens when someone doesn't vote for a candidate they don't like. Consensus does not imply or require unanimity. The IETF has an RFC which explains consensus. Please read it. Although that document relates to IETF decision making, many of its ideas and principles apply at other fora such as RIPE that use consensus. I now repeat for the FINAL time. Further discussion of RIPE decision making and whether consensus is or isn't appropriate for that is out of scope for this list. Take that discussion somewhere else. This does not prevent you or anyone else suggesting another mechanism for appointing the co-chair of the IoT WG on this list.
Thanks, Jim, for coming back with detailed reply. I am not that well aware that consenus at RIPE is a long-lasting tradition. My comment was made based on my experience in other communities where consensus is regularly blocked due to interpersonal relations. But if at RIPE it works, I have no objections to moving further with selecting the co-chair according to proposed procedure, and get to the contents. Best, Olga 12 октября 2018, 21:59:45, от "Jim Reid" <jim@rfc1035.com>: On 12 Oct 2018, at 15:26, Olga Kyryliuk <olga_kyryliuk@ukr.net> wrote:
I also don't feel that consensus is the best available option for selecting people for positions. What could be used is anonymous voting ballots. I don't know what exactly software or platforms are used for that, but this is how we vote during elections at ICANN constituencies for example. And then the person is elected by the majority of votes. I believe it's better than consensus.
Thanks for your reply Olga. RIPE has always used consensus for all important decisions: WG charters, policy making, selecting WG chairs, etc. If you want to change that, you will need to persuade the RIPE community -- by consensus! -- to agree to use some other mechanism. Voting at RIPE is not practical because there is no way of controlling who gets to vote or policing how often they do that. Since there's no membership or eligibility criteria, the concept of one member, one vote just doesn't make sense. Which is why we use consensus-based decision making for the big stuff. Many other institutions do that too, usually for similar reasons. I'm not sure how well your ICANN example could or would fit at RIPE. That's probably a discussion for another list and another place. If I understand your position correctly, you support the proposed selection procedure though you'd prefer the WG used voting instead of consensus. Is that right?
Hi Jim, full ack from my side. Cheers, Peter
Am 09.10.2018 um 16:27 schrieb Jim Reid <jim@rfc1035.com>:
Colleagues, the selection process needs another nudge. Although there have been a few expressions of support and no objections, I’m reluctant to declare consensus because only a handful of people have spoken. I’d *really* like to declare victory so we can get on with the job of finding a co-chair. It’s uncomfortable to do this when the WG has argely been silent about how the leadership is selected.
So could you please indicate your support or opposition to the following? Thanks.
I would also ask the WG to avoid the temptation to rat-hole or over-think the selection procedure, for instance by proposing elaborate steps to apply in corner cases that in all probability will never arise. We're only appointing a WG co-chair, not the Internet's Supreme-Leader-for-Life. The WG can always change the suggested process later if practical experience proves it is broken or needs improvement.
Note too that there is no mention of elections or votes. This is deliberate.
(1) The IoT WG will have 2 co-chairs who serve staggered 2-year terms. (2) A co-chair cannot serve more than 3 consecutive terms. (3) Each year, the longest serving co-chair will stand down and subject to (2) may make themselves available for re-appointment. (4) The incoming co-chair will be chosen by the WG using consensus and the remaining co-chair will make the consensus determination. (5) Any circumstances not covered by the above will be resolved by the RIPE Chair whose decision will be final.
Vote early, vote often. Well OK, we don’t vote but I hope you get the point. :-)
_______________________________________________ iot-wg mailing list iot-wg@ripe.net https://lists.ripe.net/mailman/listinfo/iot-wg
Peter Steinhäuser, CEO embeDD GmbH · Alter Postplatz 2 · 6370 Stans · Switzerland Phone: +41 (41) 784 95 85 · Fax: +41 (41) 784 95 64
Hi Jim, Thanks for the proposal. I completely support the process. I think we should finish the milestone (of selecting the co-chair) for the next RIPE meeting. Sandoche. On 09/10/2018 16:27, Jim Reid wrote:
Colleagues, the selection process needs another nudge. Although there have been a few expressions of support and no objections, I’m reluctant to declare consensus because only a handful of people have spoken. I’d *really* like to declare victory so we can get on with the job of finding a co-chair. It’s uncomfortable to do this when the WG has argely been silent about how the leadership is selected.
So could you please indicate your support or opposition to the following? Thanks.
I would also ask the WG to avoid the temptation to rat-hole or over-think the selection procedure, for instance by proposing elaborate steps to apply in corner cases that in all probability will never arise. We're only appointing a WG co-chair, not the Internet's Supreme-Leader-for-Life. The WG can always change the suggested process later if practical experience proves it is broken or needs improvement.
Note too that there is no mention of elections or votes. This is deliberate.
(1) The IoT WG will have 2 co-chairs who serve staggered 2-year terms. (2) A co-chair cannot serve more than 3 consecutive terms. (3) Each year, the longest serving co-chair will stand down and subject to (2) may make themselves available for re-appointment. (4) The incoming co-chair will be chosen by the WG using consensus and the remaining co-chair will make the consensus determination. (5) Any circumstances not covered by the above will be resolved by the RIPE Chair whose decision will be final.
Vote early, vote often. Well OK, we don’t vote but I hope you get the point. :-)
_______________________________________________ iot-wg mailing list iot-wg@ripe.net https://lists.ripe.net/mailman/listinfo/iot-wg
+1 Julf On 09-10-18 16:27, Jim Reid wrote:
Colleagues, the selection process needs another nudge. Although there have been a few expressions of support and no objections, I’m reluctant to declare consensus because only a handful of people have spoken. I’d *really* like to declare victory so we can get on with the job of finding a co-chair. It’s uncomfortable to do this when the WG has argely been silent about how the leadership is selected.
So could you please indicate your support or opposition to the following? Thanks.
I would also ask the WG to avoid the temptation to rat-hole or over-think the selection procedure, for instance by proposing elaborate steps to apply in corner cases that in all probability will never arise. We're only appointing a WG co-chair, not the Internet's Supreme-Leader-for-Life. The WG can always change the suggested process later if practical experience proves it is broken or needs improvement.
Note too that there is no mention of elections or votes. This is deliberate.
(1) The IoT WG will have 2 co-chairs who serve staggered 2-year terms. (2) A co-chair cannot serve more than 3 consecutive terms. (3) Each year, the longest serving co-chair will stand down and subject to (2) may make themselves available for re-appointment. (4) The incoming co-chair will be chosen by the WG using consensus and the remaining co-chair will make the consensus determination. (5) Any circumstances not covered by the above will be resolved by the RIPE Chair whose decision will be final.
Vote early, vote often. Well OK, we don’t vote but I hope you get the point. :-)
_______________________________________________ iot-wg mailing list iot-wg@ripe.net https://lists.ripe.net/mailman/listinfo/iot-wg
participants (15)
-
Enno Rey -
Farzad Ebrahimi -
Jaap Akkerhuis -
Jelte -
Jens Link -
Jim Reid -
Johan Helsingius -
Matthias Waehlisch -
Nigel Titley -
Olga Kyryliuk -
Peter Koch -
Peter Steinhäuser -
sandoche Balakrichenan -
Taras Heichenko -
Wolfgang Tremmel