[coc-tf] Draft Minutes – CoC TF Sixteenth Call

Dear TF members,

Here are the draft minutes from our last call.

Cheers

Ant


*****

*Draft Minutes – CoC TF Sixteenth Call*

8 October 15:30 (UTC+2)

*Attendees:* Denesh Bhabuta, Athina Fragkouli, Antony Gollan, Brian 
Nisbet, Leo Vegoda

*Scribe:* Kjerstin Burdiek*
*

*Summary: *Now that the updated Code of Conduct had been published as a 
RIPE Document, the TF discussed the next steps (defining the procedural 
aspects and CoC Team). The TF decided it would need to look at the 
process first to determine what form the CoC Team would need to take. 
The TF decided to look at other existing implementations for 
inspiration, such as the ICANN ombuds process, the RIPE NCC arbitration 
process, and the Python community. Regarding the team requirements, the 
group decided that geographical diversity was necessary but that the 
geographical spread did not have to be extremely broad. The TF also 
identified a need to determine how the CoC Team would interact with the 
community, particularly with WG Chairs. The TF identified four next 
steps: planning the CoC Team lifecycle, deciding on the team size, 
setting up the report management process, and determining how the CoC 
Team would work with the community.


*1. Minutes*

There were no minutes to be approved.

*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 said that this had been done and could be removed from future agendas.

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

Leo said that this was ongoing as the TF looked at process and the size 
of the team, which would affect it. This was an action on everyone.

*- (Ongoing) TF to think about the appropriate level of process to allow 
further improvements to the CoC.*

Leo noted that there had been a discussion about this in their webinar. 
The RIPE community would continue to review the CoC every two years. The 
process document needed to be reviewed more often, possibly every year.

Brian said it was good to have a regular process to get feedback and one 
year was a reasonable frequency for that.

Leo agreed that one year was a good starting point for this review.

*- Leo to add more history/background to the CoC introduction.*

Leo said that this was done.

*- Leo to add in text about weaponising the CoC from GeekFeminism wiki.*

Leo said that this was done.

*- Leo to check who can make a meeting on 11 June to decide if there is 
consensus on the updated document.*

Leo said that this was done.

Leo said that all action items except for the two ongoing actions could 
be removed from the agenda for future meetings.

*4. Planning*

Leo said that with the CoC published, the team must now develop process 
requirements and team requirements. They should do some planning about 
this. He asked how people would like to work.

Antony asked if they were planning to develop these at the same time or 
separately.

Leo said that was a key point. The size of the CoC Team would influence 
the amount of process. A smaller team only needed a small amount of 
process, and vice versa for a larger team because different team members 
could be assigned different duties.

Antony suggested focusing on the process first so that it was clearer 
what the team requirements would be.

Athina said this made sense. The CoC gave an idea of requirements. The 
criteria should touch on the CoC and potential violations of it. 
Criteria for the process were also needed; for instance, if they needed 
someone with experience to look into violations, that process would show 
what criteria, such as length of time, were needed for that person to do 
so. After implementing the process, they could come up with criteria 
that correspond to it.

Leo said if they looked at the process first, they should look at 
equivalent processes, such as those of the Python community. They could 
also look at other communities and extract relevant parts of processes. 
They could then get a set of references to review and work from. He 
asked if there are any other communities besides Python and Geek 
Feminism to look at for ideas.

Brian says he was not very familiar with formal team-building processes. 
He was more familiar with convention planning, which is less formal. 
There were interviews for people involved at conventions, but not 
elections done by the community. He asked how much of this was 
centralised, i.e., the RIPE Chair choosing the people involved, versus 
the RIPE community having a voice.

Leo said this was helpful because they had leaned on software language 
communities for the CoC, but he suggested maybe they need to look at 
other communities for process. If a conference for Python was not right 
for their process, maybe they should look at the IEEE or ICANN or 
another body with formal processes. They could still adjust the 
processes but be informed by them.

Antony suggested they look at ICANN’s ombudsman process for inspiration, 
or even ideas of what not to do.

Athina reiterated that although the arbitration process was not exactly 
the same, it might be a good place to look for inspiration. She shared a 
link for the arbitration process 
(https://www.ripe.net/publications/docs/ripe-691).

Brian said he had looked at the ICANN website and did not see much 
information about how the ombuds were chosen.

Leo said the ombuds were on a contract with the ICANN board, not the CEO.

Antony said he was thinking in terms of how to make a report to the 
ombuds and how they respond.

Leo said he did not know.

Brian said there was a lot of available information on how to deal with 
reports. He added that there were many communities to look at for this. 
He suggested looking at a book that addressed how to handle CoC reports, 
which had been written by someone involved with the original Geek 
Feminism wiki CoC 
(https://frameshiftconsulting.com/resources/code-of-conduct-book/).

Brian said their bigger question was more about what the process for 
team selection and development should be. Although they did need to make 
sure their reporting structure and feedback times worked for the 
community and the team, there was more information out there on that 
subject that was easily reusable, as well as more business continuity 
practices that could be applied from somewhere else. He said the 
team-building process was more important, such as who reported to whom. 
He asked if the CoC Team reported to the RIPE Chair team.

Antony asked if they needed to split up the process into subcategories. 
There seemed to be separate processes for how to file a report, who 
reported to whom, how these people were selected, and how the CoC Team 
conducted its investigation.

Athina said she was also confused about that. She agreed there was the 
process for reporting a violation, which included how it reached the CoC 
Team, how the CoC Team evaluated it, how it come to a conclusion, and 
where it reported to. Then there was the process for recruiting the CoC 
Team. She said it seemed as though they were discussing the first 
process, but now they had switched to discussing the second.

Brian said he might have changed the topic. One of the documents they 
were looking at was about the team and how it was constituted. However, 
there should also be a single process document about how a community 
member made a report, what they should expect and so on.

Athina suggested the arbitration procedure would be a good example of 
the structure to use for laying out a process, as it had descriptions 
about the arbiters’ scope, eligibility, onboarding and dismissal, as 
well as the overall arbitration process.

Leo said they needed to plan how they recruited a team and the process 
framework for that team – that team would later suggest process 
refinements to improve it. They then needed to decide the size of the 
team and how it would interact with the community, especially WG chairs. 
He said that was four pieces to look at. He said the list traffic 
analysis by the RIPE NCC would help them know how big the team should be 
as it will show how the community interacts.

Denesh suggested the size of the team should lead the other processes. 
He said people often preferred teams to be as lean as possible, but the 
CoC Team should have variety, such as differences in geography, culture, 
language, age, and experience. The should look at team size first so 
they did not get too lean of a team; looking at process might just lead 
to a lean team.

Leo said that made sense. If they had a team of just three people, they 
would need a lean process, and vice versa if it was a larger team of 
around seven people. He agreed that this was an important discussion to 
have and suggested they use the list traffic analysis to help with this.

*5. List Traffic*

Leo shared the list traffic analysis the RIPE NCC had put together. He 
noted that weekends averaged about 10% of list traffic, which went up 
during meeting months. Additionally, one in six messages was sent at 
night. This was relevant for their decisions about the geographic spread 
of the team. He asked if the weekend and overnight traffic was 
significant enough to warrant having one team member based in the east 
and one in the west.

Antony asked if something bad happening on the list was really so urgent 
that they needed someone available to answer immediately. If it was, 
they might need to tell the RIPE NCC to address the issue off the list. 
He also noted that a lot of these late night messages were from a 
handful of people.

Brian said they didn’t need broad geographical coverage to allow 24/7 
list coverage. He agreed that sometimes issues appeared on the weekend 
or at night, but these messages were generally not so urgent that they 
had to be answered right away or required the team to be available at 
that time. He said it would be nice to have but not needed.

Leo asked if they were going to start with this, should they start with 
a smaller group because they didn’t need the geographical diversity? Or 
was geographical diversity not that relevant to group size?

Denesh said that geographical diversity was necessary but it wasn’t tied 
to team size. He asked Athina how quickly a legal issue on the list 
would need to be attended to.

Athina said that in general they should work with the team and process 
planning at the same time. Geographical diversity of team members was 
for the cultural reference – this would make it easier for a team member 
to know if something was a violation or a cultural difference. If there 
was a legal infringement, it was a matter for the authorities rather 
than the CoC Team. They had the capacity to handle this; RIPE NCC staff 
were available and could act, and if it was urgent they could work after 
hours. Physical meetings (rather than mailing lists) were where 
Immediate reactions might be necessary. If there was a serious violation 
of the CoC at a RIPE meeting, then an immediate response made sense. 
While geographical spread helped with understanding cultural 
backgrounds, they mainly needed a team member to be present. She 
suggested one criterion might be having team members that were able to 
attend the RIPE meetings.

Brian agreed with Athina about having people at the meetings, but not 
necessarily the whole team – as long as there was cover. He noted that 
at conventions he attended, there was a phone given to someone to answer 
in case of emergencies. The phone was rarely used, but attendees were 
aware of it just in case. They did need geographical diversity but not 
necessarily a broad spread. Someone on the team carrying an emergency 
phone would help solve these issues. Everyone on the team would need to 
agree to this, so it should be in the initial criteria.

Denesh said that whatever they did now could be updated in a year once 
they had more experience. If something needed to be changed, they could 
add it to the change process for the next update.

Leo said that was good. He concluded that they need to work on four 
parts of process in parallel, looking at team size and composition. He 
noted that they were in consensus about team geographical diversity 
being important but not for accommodating widely-varied time zones. He 
asked if they had any standardised breakdown of the RIPE region they 
could use as a starting point. He noted that some particular regions 
have cultural similarities, such as the Nordic countries.

Antony suggested they think of the ENOG, MENOG, and SEE regions as a 
starting point. He said Nordic countries might be more similar to 
Western European countries than other regions. He added that they could 
then further divide these regions if needed, such as between the Gulf 
and Levant countries.

Leo said they do didn’t need to go into too much detail regarding 
geographical breakdown, because this would make recruitment difficult, 
among other issues, such as dividing people too much. He said they 
should consider understanding rather than representation.

Brian said this made sense and they could get very granular with 
cultural differences. He suggested the model the PC uses (rather than 
the process), considering their desire for the team to have 
representation from certain places and to be a group of people from 
across the community. He noted that there were some flaws with this and 
that they shouldn’t replicate having different regional NOGs appointing 
people, but he found the spread of representation to be good.

Antony noted that some corner cases might need attention, for example, 
whether a Russian speaker could freely travel to Ukraine. But this could 
be addressed later.

Leo said these issues would become important over time, but they should 
start with a broadly workable process. He said they now have a good idea 
from the list traffic analysis. He also pointed out they now have four 
broad process areas to work on, as well as an idea about the requirement 
for geographical diversity. He asked if there was any other business to 
discuss.

*6. AOB*

Antony brought up the document about technical requirements he and 
Athina produced. In the past they had said they should wait until Athina 
was on a call to discuss this, but he didn’t know if this had happened.

Leo said they should schedule that for a review. He also added they 
should get some of the process up and running and compare it to the 
technical requirements. These requirements should inform the process but 
not control it.

Brian they needed to figure out their timeline expectations for the next 
steps. He wondered when they would have the process ready to present to 
the community.

Leo agreed they need to develop a timeline but that they could not 
produce it yet. They needed to gather the input documents and see what 
they could reuse, how many changes are required, and how long that would 
take.

*7. Actions*

Leo identified an action to look at external documents such as those 
from the ICANN ombuds process, the RIPE NCC arbitration process, and 
possibly another document. He asked if there were any others.

Brian asked if they were looking at those two documents as guidelines 
for the mechanics of the CoC Team, e.g., recruitment and so on.

Leo said he thought they were looking at the arbitration process for 
recruitment and team lifecycle management and at the ICANN one for 
reporting management. He noted that the ICANN ombuds process was a 
contracted, paid position – very different from what they could do.

Brian said that was fine. He suggested they look at the book he 
suggested for how to manage reports 
(https://frameshiftconsulting.com/resources/code-of-conduct-book/). He 
also suggested the Python community’s document for how to report 
violations (https://www.python.org/psf/conduct/reporting/) as a possible 
guide.

*Action: TF members to review external examples/docum (e.g. RIPE NCC 
arbitration process, ICANN ombuds process) *

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/coc-tf/attachments/20211021/8eb8f0a1/attachment-0001.html>