<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Dear TF members, <br>
</p>
<p>Here are the minutes from the call before last. <br>
</p>
<p>Cheers</p>
<p>Ant</p>
<p><br>
</p>
<p>***<br>
</p>
<p><b>Draft Minutes – CoC TF Thirteenth Call </b><br>
</p>
<p>14 May 16:30 (UTC+2)</p>
<p><b>Attendees:</b> Denesh Bhabuta, Athina Fragkouli, Antony
Gollan, Brian Nisbet, Leo Vegoda, Salam Yamout<br>
</p>
<p><b>Summary:</b> The TF discussed its upcoming BoF at RIPE 82.
Based on feedback from the community, the TF considered whether
the CoC should contain examples of positive/negative behaviour, or
whether this should be published in a separate document. After
some discussion, the group agreed that this should be contained in
the CoC itself, recognising that there was a fairly standard
format to CoCs that included lists of behaviour, and they didn’t
need to reinvent the wheel. Leo shared that he had received an
email from a community member who asked why he did not get a
response to his feedback – Leo explained that the TF was there to
listen, and its updated draft would essentially be the TF’s
response to community feedback. It was also noted that the TF
might need to consider additional communication efforts when it
published its draft, to walk people through the details of what
had changed. <br>
<br>
<b>1. Minutes</b><br>
<br>
The minutes from the meeting before last (23 April) were approved.<br>
<br>
Salam asked if the minutes could more clearly indicate where a
decision was made. <br>
<br>
Leo said he would try to summarise the discussion at the end of
each section where possible. <br>
<br>
<b>2. Agenda</b><br>
<br>
Leo said he’d updated the agenda with an AOB to note that he’d
received an email from Hank Nussbacher. <br>
<br>
Leo said he wanted to keep the call straightforward, as the focus
would be on the RIPE Meeting next week. He had cut all of the
examples from the CoC, but that didn’t mean they couldn’t add some
of them back in if the group disagreed with this approach. <br>
<br>
Salam suggested some of the parts that had been cut could be
covered in a separate FAQ along with other details. This way the
CoC could remain a high-level document. <br>
<br>
<b>3. Actions</b><br>
<br>
<b>- (Ongoing) RIPE NCC to review reporting requirements to inform
a process of improvements to the CoC (likely tooling and legal
analysis).</b><br>
<br>
Antony said they were still working on this. <br>
<br>
<b>- (Ongoing) TF to think about how the CoC Team and the WG
Chairs would work together to manage discussions on mailing
lists. Including tools, e.g. Mattermost channel</b><br>
<br>
Brian said he would have something to share around the end of May.
<br>
<br>
<b>- (Ongoing) TF to think about the appropriate level of process
to allow further improvements to the CoC.</b><br>
<br>
Leo said a lot of this would probably be informed by the feedback
from their BoF next week. <br>
<br>
<b>- Leo to draft slides for BoF </b><br>
<br>
Leo said this was done. <br>
<br>
<b>- TF to review Mailing List Guidelines for RIPE Working Group
Chairs </b><br>
<br>
Brian clarified that the WG chairs would pick one of two
moderation options – chairs could either get access to the
moderation admin or let the RIPE NCC handle this. It was up to
each WG to decide which option it preferred. <br>
<br>
Leo said he thought there could be a third option, which he had
seen in an IETF WG that had gotten out of hand. In that case, the
chair had enabled moderation for the entire mailing list and let
through all messages that weren’t abusive at a set time each day.
This slowed everything down, but it affected everyone equally and
the slower pace drove a more considered discussion. It had also
taken some of the heat out of the space. <br>
<br>
Brian said that was covered under the first option (placing the
entire list into emergency moderation). <br>
<br>
Leo suggested that could be clearer, as it could be interpreted in
a number of ways. <br>
<br>
Brian added that this was essentially what the RIPE NCC Executive
Board had done with the Members Discuss mailing list. He had also
warned the Anti-Abuse WG list that he might do this if people
didn’t behave. <br>
<br>
Denesh said what he understood by “emergency moderation” was that
someone would review every message and let them through
(more-or-less in real time), but not slow things down as Leo had
described. <br>
<br>
Brian said they could improve the language there. <br>
<br>
Leo said it was good that they’d had this discussion, as it gave
them awareness of the various options that were available. <br>
<br>
<b>2. BoF</b><br>
<br>
Leo shared his draft slides. He said it was possible that they
would get a lot of input and wouldn’t have time to make it through
all the questions. He would let Olaf decide, because if they got a
lot of helpful feedback that identified different strands of
thought within the community, then that told them they might need
another intersessional BoF or something similar.<br>
<br>
Denesh said he wasn’t seeing anything about their timeline in the
slides. <br>
<br>
Leo said that in his message to RIPE List, he had said they would
like to publish an updated CoC by the end of June. He would rather
get it right, so if it had to be later that was fine. He said he
would mention that June was the target in the BoF. <br>
<br>
Salam asked if they could break out into separate sessions during
the BoF. Perhaps they could cover all of the questions that way. <br>
<br>
Leo said that might not be practical, as they were using Meetecho
and only had an hour. If they did something intersessional in the
future, they could look at breakout rooms, though this would
require more effort overall – as they’d need to have multiple
people chairing/noting what was discussed. <br>
<br>
Leo said he wouldn’t give a date for the process or CoC Team
documents in the BoF. This was because it would largely depend on
the community’s feedback.<br>
<br>
Denesh suggested they make it clear during the BoF that they were
there to listen to the community. <br>
<br>
Leo said he would do that and would also mention that this was why
they had invited Olaf to chair the BoF (so they could focus on
listening). <br>
<br>
<b>3. Updated CoC Doc</b><br>
<br>
Leo said he had tried to incorporate the feedback they’d received
so far by removing all of the bullet points from the draft, as
there had been some discussion that this was too much. This was
part of the tension between those in the community who wanted a
focus on principles and those who wanted examples. The question
was how much of this to put back in.<br>
<br>
Denesh said he thought they could keep it as-is and say that these
were a few examples but it was not an exhaustive list. They could
refer to another document with an FAQ or a longer list. He didn’t
think they would ever get the balance right or cover everything,
but they could give some examples and update this when needed. <br>
<br>
Leo said he liked the idea of having a very brief CoC overall with
more detailed informational that was separated out. He asked if
Antony or Athina could give some guidance about how this could be
managed – both from an editorial and a procedural perspective (in
terms of the future CoC Team wanting to update this). <br>
<br>
Antony said his first thought was that if version control and
history was important, then it was best to publish this as a RIPE
Document. If they were more flexible, then it could be a web page
and they would take care to manage it properly. Neither approach
would be very hard to manage on the RIPE NCC’s side. <br>
<br>
Brian said if they didn’t publish the examples as RIPE Documents,
people would wonder why. His assumption was that all three
documents they would develop would be published as RIPE Documents
– and what they were discussing was essentially a fourth document.
<br>
<br>
Denesh agreed with Brian. <br>
<br>
Leo said he was thinking of this in terms of the RIPE NCC’s
training material. Here, the community developed RIPE Documents
with its policies, and then trusted the RIPE NCC to use its own
judgement when communicating this information in other formats.
The RIPE NCC would have experience over multiple meetings and
mailing lists, and so perhaps they could entrust this document to
the RIPE NCC.<br>
<br>
Antony said he was thinking of people who might be worried about
the CoC being weaponised. This would essentially be a list of the
reasons why someone could be excluded from the community, and the
idea of this being updated on an ad hoc basis could concern them.
Another option could be something similar to RIPE NCC procedural
documents, which were published by the RIPE NCC but handled in the
same way as RIPE Documents in terms of version control. <br>
<br>
Brian said they should involve the RIPE Chair Team if they decided
to go in this direction. This was the community’s document and he
thought the community should own it and be invested in it. He also
wanted to avoid the perception that the RIPE NCC was somehow
gaining power or bringing down the ban hammer. This was similar to
how they said the RIPE NCC was not the Internet Police – they
didn’t want it to become the community’s police either, which was
why they would have a CoC Team. <br>
<br>
Leo said it was important that Brian had brought this up. What he
had inferred from Salam’s comment was that this would not be a
policy document – it would be something to help people understand
the policy. They could identify positive/negative behaviours and
add them to the FAQ to support understanding. He wasn’t suggesting
a RIPE NCC-managed policy document, he was thinking more in terms
of the RIPE NCC’s training material. <br>
<br>
Salam said this was roughly what she was thinking. She asked if
the current list included all the relevant aspects of identity –
an earlier version wasn’t much longer, but it had covered this
well. She suggested they could include positive behaviour in the
CoC and have an FAQ with negative behaviours that could expand
over time (without version control). <br>
<br>
Athina said if the TF or the community felt strongly that certain
behaviours were unacceptable, they should be identified in the
document. If this was left to the RIPE NCC, it might not be as
strong, or could be subject to doubt, especially as they had seen
some comments from the community that this effort was politically
motivated. She thought they should have a list of behaviours
written down clearly, and then perhaps they could say that this
list would be clarified by the actual evaluation of reports done
by the CoC Team, and that in the future this team might come up
with examples in a publication later on. And they could leave it
there. Perhaps the team would come up with an anonymised list of
behaviours that were a violation along with behaviours that were
reported but were not a violation. <br>
<br>
Denesh said he thought the TF would initially develop this list of
behaviours and, as it would be published as a RIPE Document, the
CoC Team could add to it over time (in addition to people within
the RIPE NCC and other community members). This could be a living
document and because it would be separate, it would avoid making
the CoC overly long. <br>
<br>
Leo asked for thoughts from each person on whether they should
separate the CoC from a document that would contain examples or,
alternatively, if they should go for one all-inclusive document. <br>
<br>
Salam thought they needed to have one document – the CoC. This
could be accompanied by other peripheral documents such as
training materials or FAQs. For the list within the CoC, she would
add intimidation, bullying and harassment, and instead of
aggressive communication, she would say aggressive behaviour (or
communication and behaviour). <br>
<br>
Brian said there was a fairly standard format to CoCs across
communities and they all included lists of encouraged and
unacceptable behaviour. He didn’t think they needed to reinvent
the wheel. They had good examples there, and he really thought
they should take the prior examples that were out there and
include them in the main document. They should publish this as a
RIPE Document and should stick with three documents instead of
four. <br>
<br>
Denesh said he was on the fence. His earlier comments were
intended to keep the CoC from becoming too long and could allow
the examples to be updated independently. It depended on whether
they wanted to keep the CoC short or not.<br>
<br>
Athina said she agreed with Brian. <br>
<br>
Leo said in that case, he thought they should add the examples
they had before, perhaps with some wording to clarify that they
were only examples and subject to change. <br>
<br>
Salam agreed with that approach. <br>
<br>
Leo said in that case he would add the list back in. <br>
<br>
<b>4. AOB</b><br>
<br>
Leo said he wanted to note that he had received an email from Hank
Nussabacher asking why he hadn’t received a response to his
comment on the mailing list, which noted that the CoC should list
things like spam, sharing malware, etc. In Leo’s reply to Hank, he
had said they were not planning to reply to everyone and were
taking feedback on board – their updated draft CoC would
essentially act as their response. He had also noted that most of
Hank’s examples were already illegal and referred him to the
section in the existing draft that dealt with illegal behaviour.
Leo said that when they published their updated draft, they might
need to do something extra (such as a webinar) to walk people
through what had changed and explain their rationale. <br>
<br>
Brian reiterated that the examples in Hank’s email were illegal
behaviour. He said it was worth clarifying these kinds of things
out in their communication when they shared their updated draft. <br>
<b><br>
</b><b>5. Actions</b><br>
<br>
Leo said he saw two actions coming out of the above discussion –
to update the draft CoC (adding the examples back in) and to work
with Antony on communicating the draft CoC once it was ready to
publish. <br>
<br>
<b>Action: Leo to update draft CoC (adding examples of behaviours
back in). </b><b><br>
</b><b><br>
</b><b>Action: Leo to work with Antony on communicating the
updated draft CoC. </b><b><br>
</b><br>
<br>
<br>
</p>
</body>
</html>