<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>