This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[ripe-list] PDP Appeals Process
- Previous message (by thread): [ripe-list] PDP Appeals Process
- Next message (by thread): [ripe-list] PDP Appeals Process
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Shane Kerr
shane at time-travellers.org
Mon Apr 12 10:15:36 CEST 2021
Daniel, My own feeling is that the appeals process worked basically well enough the first and only time it has been used, and that we would not be able to get any significant gain by a redesign at this point. Since we've only had 1 appeal since the process was actually documented 6+ years ago, maybe we should wait to see if the appeals process is actually broken before scrapping it? More thoughts inline and at the end... On 11/04/2021 10.31, Daniel Karrenberg wrote: > Randy, colleagues, > > we are already past the station where we wonder whether to review the > appeals process. Our chairs collective is already actively thinking > about significant tweaks. This is what prompted my reaction. I wouldn't call the proposed changes significant: 1. Clarifying who should recuse themselves. (This was already implicit, but to quote the Zen of Python: "explicit is better than implicit".) 2. Setting deadlines. 3. Clarifying the role of informal discussion before policy proposals. In fact, I don't see any much work at all there. > To make my point clearer let’s look at this from the perspective of cost > to the community: The chairs are proposing costly tweaks to the existing > procedure, such as writing and agreeing on a playbook and giving courses > to WG chairs that may never use the PDP. I ask whether we should > fundamentally review the procedure instead. That has a cost too. I > expect this cost to be less or equal to the cost of the proposed tweaks. > I also expect that we can come up with a good procedure that costs > significantly less to *run* each time than a tweaked procedure. My > message gives the general idea on how I propose to achieve that. This is > the question we have to answer first. > > The engineering comes after that. And, as always, the engineering will > include trade-offs: the less costly the execution of the procedure is, > the lower the threshold to invoke it can be and vice-versa. > > Again: Should we go beyond tweaking and fundamentally review the PDP > appeals procedure? We now have N=1, since we've had exactly one appeal. I was the one who facilitated the process and wrote the draft of the response after a special meeting of the working group chairs collective (WGCC) to discuss the appeal. We had a relatively small number of chairs who actively participated in the process. I suspect that any handling of an appeal would look pretty much the same, although possibly with different people. I don't think we would save work by picking different people to handle the appeals process; we would just shift it around. As for including people who did not sign up for this task, the role of the WGCC in appeals was set in the PDP in 2014 (ripe-614), so this is hardly new (although I see that when we updated the working group chair job description in 2017 we missed that bit; technically redundant but really it should be there). In the end we basically have the same unpleasant options we usually have for such things: either re-use a body that was not designed for this purpose or create a new one. Both options kind of suck. In principle the appeals procedure could be used as a denial-of-service attack on the RIPE community by bad faith actors. But I think that the RIPE community is highly resistant to such problems and I trust that our RIPE Chair will be able to handle any such situation in a common sense manner. Cheers, -- Shane -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x3732979CF967B306.asc Type: application/pgp-keys Size: 11589 bytes Desc: not available URL: </ripe/mail/archives/ripe-list/attachments/20210412/ae61a25e/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: </ripe/mail/archives/ripe-list/attachments/20210412/ae61a25e/attachment.sig>
- Previous message (by thread): [ripe-list] PDP Appeals Process
- Next message (by thread): [ripe-list] PDP Appeals Process
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]