Draft Minutes – CoC TF Twelfth Call
Dear TF members, Here's the draft minutes from our call back in April. There's two more sets to come, I'll try to get them all sent this week. Cheers Ant * * *** ** *Draft Minutes – CoC TF Twelfth Call * 30 April 16:30 (UTC+2) *Present:* Athina Fragkouli, Antony Gollan, Brian Nisbet, Leo Vegoda *Summary:* The TF agreed to put together a discussion document on how the CoC Team will work with the WG Chairs. It was noted that this would require communication between the two groups, and it would be hard to create a detailed operational procedure until a CoC Team was in place. The TF discussed that there would need to be a way to update the CoC in the future; ideally this would not require another TF (depending on the nature of the change). The group agreed to try condensing or removing some of the lists of examples in the current draft. Looking at technical requirements, the TF discussed whether the RIPE NCC should maintain the system to receive/archive reports or if it would be better for a third-party to manage this. It was noted that the same confidentiality issues would exist with a third-party and the TF thought the RIPE NCC could be trusted to operate such a system. The TF discussed the upcoming BoF at RIPE 82 and agreed this should focus on topics relating to the process and CoC Team. The TF also agreed to seek a neutral party to moderate the discussion. *1. Minutes* Approval of the minutes was moved to the next call. *2. Agenda* There were no changes to the agenda. *3. Actions* *- (Ongoing) RIPE NCC to review reporting requirements to inform a process of improvements to the CoC (likely tooling and legal analysis).* Leo shared the document the RIPE NCC had been working on with the group. Antony explained they had been thinking of the steps that would need to happen and whether there were any legal concerns associated with them. Then they tried to anticipate how this could translate into an actual process – this latter part was where they had made the most assumptions and likely would have gotten things wrong. Once they had the document finished, the TF could let them know what parts of the process should change. *- (Ongoing) TF to think about how the CoC Team and the WG Chairs would work together to manage discussions on mailing lists.* Brian said he had been thinking in terms of active collaboration. It was important to make sure the CoC Team wasn’t compromised by a WG chair deciding arbitrarily that something wasn’t a CoC issue. At the same time, chairs shouldn’t have to make a report or go through some process before they could moderate someone on their mailing list. This would require communication when these conflicts came up. They could put things down on paper, but it would be hard to set an operational procedure until they had a CoC Team that could actually sit down with the WG Chairs Collective. He wanted the TF to avoid binding the CoC Team to a particular way of working. The CoC Team would also need the ability to escalate the issue if cooperation with the chairs didn’t work. Brian volunteered to draft something on this. Athina said she saw three steps here. The first was a report and whether this should go via the CoC Team or the WG chair first, in which case they should have the first level of filtering to decide where the issue went. The next step would be the evaluation, and whether this would be done by the CoC Team or together with the chair. The third step was the execution – here they should understand if the WG chairs would execute whatever evaluation came from the CoC Team or whether they had some discretion. Leo suggested there was an initial step where the WG chair could proactively manage the mailing list (by highlighting inappropriate behaviour). Waiting for a complaint was probably not the best approach and guiding people towards good behaviour might be better. Brian said he liked Athina’s three stages. He could use that as a framework for the document he would put together. One key principle was that anyone in the community should be able to go to the CoC Team directly, without barriers or prerequisites. *Action: Brian to draft discussion document on cooperation between the CoC Team and WG Chairs.* *- (Ongoing) TF to think about the appropriate level of process to allow further improvements to the CoC.* Leo said what they produced would not be perfect and they had a responsibility to provide some guidance on how the document could be further improved and updated. Doing this via another TF was probably not ideal. He was thinking they could ask the community for input on this at their BoF. Antony said maybe they could have some sort of periodic interaction where the CoC Team reported to the community at a defined interval. As part of this, it could make recommendations based on its experience implementing the CoC. Simple recommendations could go ahead straight away (making CoC Team contact details more prominent, for example), while more complicated ones could be handled through a more appropriate process, such as a TF. Athina asked if the PDP could be useful here. Brian said he would like it if changes could be made with less difficulty and process than their current approach, within reason. The idea he had was the CoC Team could speak to the RIPE Chair team and a decision could be made corresponding to the size of the change. Basic things like contact details could go ahead, while more substantial changes could take a more formal process. But if they encountered a problem or potential loophole, he would prefer it didn’t take six months or longer to fix. Leo said it was important to separate the code from the implementation. Adjusting the implementation should be relatively easy, while making changes to the CoC should be more difficult. Brian said it was one of those things that affected everyone. For a change to the charter of his WG, it was only the WG that had to agree. Bigger things like this needed to be decided on by the wider community/RIPE plenary. Athina said if they had a CoC that was based on principles, future changes might introduce other principles or more clarity – so they could amend the document and add details. Alternatively, they could say that previous decisions created a jurisprudence and, based on those examples, specific behaviour was/was not a violation. Antony asked if a jurisprudence approach relied on knowing the specifics of past cases, while in a CoC situation this would not be so transparent. Athina said they had something like this with their arbitration panel, where they published a summary of each case that was sufficiently broad and anonymised. Leo said he liked the idea of guiding precedent. His only concern was if that would make it difficult to provide confidentiality to people. And if the summaries were broad, they might not be enough for a different CoC Team in the future to draw from (as it might lack a memory of the case). What made a precedent work was that you could read the report – which might not be the case here. Brian said this was generally how code of conducts evolved. It wasn’t that they needed to be able to find the details behind the judgement, it was that the situation had created new needs. The case he had referenced to on their previous call (an attendee reacting in an insulting way to someone who was themselves harassing someone else) was explicitly identified as not a violation of the CoC. Making this kind of change didn’t require knowledge of the details. It was also important to note that they might want to update their CoC proactively in response to issues from other communities that they wanted to avoid in RIPE. Leo said Brian had a point there – they might need to react to a situation that hadn’t yet emerged in the RIPE community. *- Leo to draft slides for BoF (see agenda item below)* Leo said he had received feedback from the RIPE Chair Team. They wanted them to use the BoF to focus on issues relating to implementation – processes and the makeup of the CoC Team – especially in the context of having the same CoC for other meetings. For example, would they want separate teams? And what sort of volunteer requirements would be needed? They might also ask about the level of detail needed in the document. Brian asked if Leo was talking about moving some of the lists in the CoC elsewhere. Leo said that had been suggested (moving the examples currently in the CoC to the document on process). Brian said his concern was that people would only read the process document when making a report. People might miss something or wonder why this was not in the first document. It ultimately came down to what this looked like. Leo said he could appreciate that, however, the longer the document was, the less likely people were to read it. If they went from limited understanding to appreciable understanding, he thought that was a success. Brian said it depended on how much shorter this made the document and what would be removed. Leo said they could float this idea at the BoF and say that this was what they were looking at. If people wanted more illustrative examples, they would know to include them. The danger was that in doing so, you were creating a detailed list of behaviour and the incentive was to keep adding more examples. *Action: Leo to draft BoF slides* *Action: Leo to merge some of the illustrative examples in the CoC to make the document shorter* Antony said with the examples they had at the moment – they had two categories – one was positive/aspirational and the other was negative. Only those negative behaviours could constitute a violation. If they wanted to reduce the document, perhaps they could focus on condensing the first category. Leo said he was tempted to do the opposite. His concern was that every time they added a negative behaviour, they ran the risk of people saying that because another behaviour wasn’t in the list of examples, it was not a violation. An extremely short list might be a better indicator that it was illustrative rather than a complete list. Athina said she had always been in favour of being explicit about what was not tolerated and what was a violation, because this created clarity. Positive behaviours offered guidance, but she wondered if they could lead to reports on the basis of failing to show positive behaviour that were not ill intended (such as not adequately showing appreciation of someone’s work). They didn’t want to have to address one another as “excellencies” and they were often direct as a community, which was fine. But they should not be racist, harassing, insulting, etc. These were the absolute “no’s”. Leo said he would take a shot at making this less specific. For example, one of the sections talked about discrimination based on identity, and then listed a lot of identities such as “immigration status” which might be less of an issue outside of America. There might also be aspects they had missed, such as caste issues in South Asian communities – was it better to specify this or just say “anything related to identity”? Antony added that when he was editing the document, he had been tempted to remove a lot of this detail. He thought it wouldn’t be too hard to remove a lot of it while keeping a precise meaning. *- TF to review Mailing List Guidelines for RIPE Working Group Chairs * Leo said they could keep this on the agenda for the next meeting. *- TF to think about practical ways to help WG Chairs and CoC Team members collaborate to effectively support positive discussion on mailing lists, e.g. a shared Mattermost channel* The group agreed this could be merged with the above action. *4. Guidelines, collaboration, tools* Athina suggested they should use the document she and Antony had prepared and take it from there. Leo said he’d read the draft, though he didn’t want to give a lot of feedback on it now as it wasn’t final. One question he’d seen was about whether the tools/operating system should be hosted by the RIPE NCC or hosted externally. His personal feeling was that if he was making a report, he’d prefer it was hosted by the RIPE NCC and subject to some kind of technical audit rather than hosted by someone else who, while well-meaning, might not be as capable. Antony said here they had been thinking that if it was maintained by their IT department, then they would have some kind of access to the system and thus the reports themselves. The question was whether the community preferred for this to be hosted by a third party or if it was happy including their IT department within the “circle of trust” for this system. Athina added that if something happened within the community, their IT team would often be present at the meeting and would know community members. Perhaps this could make people feel uncomfortable, especially if they were present at the meeting. Leo said the fact that someone had super user access to a system did not mean they were constantly browsing through it. He thought a sophisticated organisation like the RIPE NCC could have logging to show if someone was reading the cases, and if there wasn’t a legitimate reason for them to do so, it could be a career-limiting move. Personally, he trusted the RIPE NCC to set things up appropriately. If they used a third party, they would need a lot of contracts or independent auditing to create some level of trust, or they just needed to hope that they were trustworthy. He thought the cost of generating that trust via the RIPE NCC was lower, though others might see that differently. Brian said this problem was inevitable and there were ways to mitigate these risks. He trusted the RIPE NCC and assumed it had contracts with its employees that could cover these things, and he liked that things like GDPR applied to the RIPE NCC. Leo said perhaps the RIPE NCC could do a brief presentation to show how the system was hosted and explain the controls they had in place – being open and transparent about it could support trust and allow people to raise any concerns. Athina said that was a good suggestion. *5. BoF* Leo said he had shared his slides and gotten some feedback from the RIPE Chair Team. They had suggested the BoF could gather feedback on the process steps and the CoC Team (including what would be required from volunteers and whether they would need to undergo training). Another aspect was making sure that they found the right balance between something that was fair but workable, including having some sort of appeals process. Feedback on this would be useful and could help with the next part of their work. They had also suggested finding a neutral party to chair the BoF, and had suggested Olaf Kolkman. Leo asked if the group had any thoughts on this. Brian said that all sounded good. He agreed especially with the idea of having a neutral chair for the session. From previous experience, even if the moderator remained neutral, as a member of the TF it became oppositional by nature. A neutral party sounded like a good idea. Leo said this wouldn’t be someone who was trying to progress the work and wouldn’t have an interest in moving things in a particular direction. He thought it might be good to just be able to get out his pen and take notes. He said he would ask Olaf to see if he was available. *Action: Leo to ask Olaf if he can chair BoF at RIPE 82* Leo added that they had received a request from the RIPE NCC for an agenda. He said he would share something on the list and hopefully they would agree on that by the end of next week so he could pass it to the meeting team. The updated BoF slides would essentially form the agenda. *6. Actions* *Action: Brian to draft discussion document on cooperation between the CoC Team and WG Chairs** ** **Action: Leo to draft BoF slides/create agenda** **** **Action: Leo to merge some of the examples in the CoC to make the document shorter** ** **Action: Leo to ask Olaf if he can chair BoF at RIPE 82*
participants (1)
-
Antony Gollan