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