[coc-tf] 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*

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ripe.net/ripe/mail/archives/coc-tf/attachments/20210531/2faf3e60/attachment-0001.html>