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)