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/ripe-list@ripe.net/
[ripe-list] Proposed Changes to the Draft Code of Conduct Process
- Next message (by thread): [ripe-list] Is NRO trying to make RIR into an ITU sister today?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Daniel Karrenberg
dfk at karrenberg.net
Mon Oct 3 12:13:42 CEST 2022
Leo, task force members, let's remember that we have consensus on the code of conduct itself and that we are discussing the implementation. Not all ist lost. ;-) I observe some pretty strong reactions requesting 'due process' from long standing, constructive and productive members of the community. This is serious. There is a risk that some of these good people might stop contributing if we proceed with this draft procedure document. We do not want to loose good people for the sake of being more inclusive. Upon reflection it appears to me that the requests for 'due process' may not come from a desire for a quasi legal process but from a *perception* that the the *process*, not the code, is biased against the community member whose behaviour is being reported. Here are a number of suggestions to address this: 1. Make it explicit that it is part of the process to apply the 'Discretion to Reject Reports' from the code. It may be sufficient to just mention this at the part of the assessment process in step 3. 2. Re-draft the process to focus on stopping the *behaviour* that is violating the code of conduct and not on sanctioning people. This is an important difference. 3. Add more explicit mechanisms for the person whose behaviour is being reported to be heard. This is especially important if more serious actions are being considered. Maybe offer them to choose a member of the CoC team to hear their side of the story and add that member to the assessment team? Less important but worth considering: if I understand the proposed process correctly, each and every report would lead to the creation of a new assessment group. I perceive this as very heavy and resource intensive. A perfect DoS target! In my opinion the process should allow for some sort of triage should the load get too high. Pragmatism should be explicitly allowed. For instance if the load gets high a screening team could be assembled from members of the CoC team at least for each RIPE meeting or maybe for a certain time period. This screening team could then filter out obviously spurious reports and maybe quickly deal with minor incidents. Nit: Improve the 'Introduction' sections with explicit references to the other relevant documents such as the CoC itself and a clear scoping of the document itself. Maybe rename it 'Scope'? I appreciate your personal efforts and the efforts of the task force. Daniel
- Next message (by thread): [ripe-list] Is NRO trying to make RIR into an ITU sister today?
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]