<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Dear TF members, <br>
    </p>
    <p>Here's the draft minutes from our call back in April. <br>
    </p>
    <p>There's two more sets to come, I'll try to get them all sent this
      week. <br>
    </p>
    <p>Cheers</p>
    <p>Ant<br>
    </p>
    <p><b><br>
      </b></p>
    <p>***<br>
      <b></b></p>
    <p><b>Draft Minutes – CoC TF Twelfth Call </b><br>
      <br>
      30 April 16:30 (UTC+2)<br>
      <br>
      <b>Present:</b> Athina Fragkouli, Antony Gollan, Brian Nisbet, Leo
      Vegoda<br>
      <br>
      <b>Summary:</b> 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. <br>
      <br>
      <b>1. Minutes</b><br>
      <br>
      Approval of the minutes was moved to the next call. <br>
      <br>
      <b>2. Agenda</b><br>
      <br>
      There were no changes to the agenda. <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>
      Leo shared the document the RIPE NCC had been working on with the
      group.<br>
      <br>
      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. <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.</b><br>
      <br>
      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. <br>
      <br>
      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. <br>
      <br>
      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. <br>
      <br>
      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. <br>
      <br>
      <b>Action: Brian to draft discussion document on cooperation
        between the CoC Team and WG Chairs.</b><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 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. <br>
      <br>
      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. <br>
      <br>
      Athina asked if the PDP could be useful here. <br>
      <br>
      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. <br>
      <br>
      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. <br>
      <br>
      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. <br>
      <br>
      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. <br>
      <br>
      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. <br>
      <br>
      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. <br>
      <br>
      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. <br>
      <br>
      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. <br>
      <br>
      Leo said Brian had a point there – they might need to react to a
      situation that hadn’t yet emerged in the RIPE community. <br>
      <br>
      <b>- Leo to draft slides for BoF (see agenda item below)</b><br>
      <br>
      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. <br>
      <br>
      Brian asked if Leo was talking about moving some of the lists in
      the CoC elsewhere. <br>
      <br>
      Leo said that had been suggested (moving the examples currently in
      the CoC to the document on process). <br>
      <br>
      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. <br>
      <br>
      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. <br>
      <br>
      Brian said it depended on how much shorter this made the document
      and what would be removed. <br>
      <br>
      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. <br>
      <br>
      <b>Action: Leo to draft BoF slides</b><br>
      <br>
      <b>Action: Leo to merge some of the illustrative examples in the
        CoC to make the document shorter</b><br>
      <br>
      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. <br>
      <br>
      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. <br>
      <br>
      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”. <br>
      <br>
      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”? <br>
      <br>
      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. <br>
      <br>
      <b>- TF to review Mailing List Guidelines for RIPE Working Group
        Chairs </b><br>
      <br>
      Leo said they could keep this on the agenda for the next meeting.
      <br>
      <br>
      <b>- 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</b><br>
      <br>
      The group agreed this could be merged with the above action. <br>
      <br>
      <b>4. Guidelines, collaboration, tools</b><br>
      <br>
      Athina suggested they should use the document she and Antony had
      prepared and take it from there.<br>
      <br>
      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.
      <br>
      <br>
      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.<br>
      <br>
      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. <br>
      <br>
      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. <br>
      <br>
      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.<br>
      <br>
      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. <br>
      <br>
      Athina said that was a good suggestion. <br>
      <br>
      <b>5. BoF</b><br>
      <br>
      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. <br>
      <br>
      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. <br>
      <br>
      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.<br>
      <br>
      <b>Action: Leo to ask Olaf if he can chair BoF at RIPE 82</b><br>
      <br>
      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. <br>
      <br>
      <b>6. Actions</b><br>
      <br>
      <b>Action: Brian to draft discussion document on cooperation
        between the CoC Team and WG Chairs</b><b><br>
      </b><b><br>
      </b><b>Action: Leo to draft BoF slides/create agenda</b><b><br>
      </b><b> </b><b><br>
      </b><b>Action: Leo to merge some of the examples in the CoC to
        make the document shorter</b><b><br>
      </b><b><br>
      </b><b>Action: Leo to ask Olaf if he can chair BoF at RIPE 82</b><br>
    </p>
  </body>
</html>