<html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <meta name="Title" content=""> Dear task force members, Here are the notes from last week's call. There was a good discussion between points 2) and 3) - please check that I noted your opinion correctly. Cheers Antony RIPE Accountability Task Force Meeting Notes<o:p></o:p> <o:p> </o:p> 3 April 2017<o:p></o:p> <o:p> </o:p> Attendees: Athina Fragkouli, Antony Gollan, Malcolm Hutty, Peter Koch, Nurani Nimpuno, Paul Rendek, Wim Rullens, Carsten Schiefner, Marco Schmidt, William Sylvester, Filiz Yilmaz.<o:p></o:p> <o:p> </o:p> 1) Welcome, finalise agenda, adopt minutes<o:p></o:p> 2) Review of accountability mapping document<o:p></o:p> 3) Draft scope - feedback from mailing list 4) Review of timeline 5) RIPE 74 preparation (presentation and tf meeting)<o:p></o:p> 6) Review of action items 7) AOB<o:p></o:p> <o:p> </o:p> 1) Welcome, finalise agenda, adopt minutes<o:p></o:p> <o:p> </o:p> There were no changes to the agenda. The minutes were adopted without comment. <o:p></o:p> <o:p> </o:p> 2) Review of accountability mapping document<o:p></o:p> <o:p> </o:p> Antony ran through the changes to the accountability mapping document. He said that after looking at this, they had decided it would be worth evaluating the importance and quality of the existing documentation that they had already identified and so had added columns for this. This could help the TF to prioritise which issues they should focus on. <o:p></o:p> <o:p> </o:p> He said they had also been thinking that another important aspect was whether the “output” that resulted from the performance of a certain function was also documented. For example, while the RIPE Chair’s authority to determine the location of RIPE Meetings was well documented, from an accountability perspective it might also be important that the individual decisions were themselves documented.<o:p></o:p> <o:p> </o:p> Most of the links supplied in this column were examples, as these were often singular instances (e.g. a specific mailing list announcement). <o:p></o:p> <o:p> </o:p> When it came to documenting things that took place at RIPE Meetings, they had provided an example of a Daily Meeting Report, Steno Transcript and a Video Archive – but they weren’t sure if this indirect or ad-hoc documentation was adequate for some areas, such as decisions taken by the plenary. <o:p></o:p> <o:p> </o:p> Athina continued and said that for certain bodies, some powers were implied but not explicitly given in the documentation. For example, for the WG Chairs, there was a power to assign action items to the RIPE NCC – however this power wasn’t explicitly documented anywhere. She wanted to flag that there could be instances where a WG assigned a task to the RIPE NCC, but the Executive Board disagreed. What did this mean in terms of accountability? <o:p></o:p> <o:p> </o:p> The procedure to replace WG Chairs differed between WGs and was of varying quality. <o:p></o:p> <o:p> </o:p> For the plenary, it was not entirely clear which parts it was responsible for or where the power of the RIPE Chair ended and the power of the PC began. <o:p></o:p> <o:p> </o:p> Regarding the role of RIPE Meeting attendees, remote participation in PC elections was allowed, but you needed to physically attend a RIPE Meeting to vote in NRO NC elections. <o:p></o:p> <o:p> </o:p> She noted that task forces were defined in ripe-004 but this document was obsolete. <o:p></o:p> <o:p> </o:p> Filiz said this was great work – it was structured and would help them to identify gaps. In the past the RIPE PC had tried to categorise what ran into the plenary, and they had encountered these kinds of issues – what were BoFs, and what were task forces, etc. If they continued with this documentation approach, they should note down the highlights of the analysis – what was missing in general. <o:p></o:p> <o:p> </o:p> William noted that after a discussion with Antony the previous week, they would send around an updated version of the document after the call with the various parts numbered – this would make it easier for the TF to discuss and track specific changes to the document.<o:p></o:p> <o:p> </o:p> Nurani said it was good to get this document and it showed some gaps they were not aware of – for example she would have thought they had adequate documentation for task forces. In other communities, there was a tendency to become overly bureaucratic once you started looking at these kinds of things. There was a tendency to think that you needed to document everything to achieve accountability. This could be counterproductive. In ICANN for example, if you were an expert in procedures you did fine – but if you didn’t know them you often found it difficult to get work done. For the RIPE community it might be fine or even desirable that some things were loosely documented. <o:p></o:p> <o:p> </o:p> Peter shared some of Nurani’s concerns, particularly given some of the feedback they had received. He said they should also consider whether these gaps had ever caused a problem. But looking at these documents, maybe it was important to consider also where some of these documents had come from – e.g. the RIPE Meeting code of conduct hadn’t been approved by the RIPE community but rather by the WG Chairs and the PC. Some changes to the PDP had come from the WG Chairs collective and might not have made the rounds through the community. He added that he was pretty sure that there had been adequate task force documentation in the past, but maybe it hadn’t survived an earlier website redesign. <o:p></o:p> <o:p> </o:p> Paul and Carsten also supported Nurani's point. Filiz agreed with Nurani's point regarding unnecessary complexity but said the importance and quality columns in the document would help to prevent this. She said they were still in the stocktaking part of the process. Malcolm agreed with Nurani, but said it would be helpful for newcomers to find documentation that explained things that “old timers” in the community already knew. <o:p></o:p> <o:p> </o:p> Filiz noted that several RIPE Chair roles were “pending” in terms of the documentation – she asked what that meant. <o:p></o:p> <o:p> </o:p> Antony clarified that this referred to the Draft RIPE Chair Function Description and the Draft RIPE Chair Selection Procedure that were currently circulating for community comment. As they had noted in the mapping document, if these two documents were accepted by the RIPE community, then most of the current gaps relating to the RIPE Chair function would be filled.<o:p></o:p> <o:p> </o:p> Filiz asked that a link to these draft documents be included there. <o:p></o:p> <o:p> </o:p> Filiz noted that WG Chairs also had the power to make additional consensus decisions on anything in their WG and this wasn’t included in the document. <o:p></o:p> Athina said they could add that. Peter noted that not all WG outputs would be "best practice documents" as the document currently indicated. He added that the publication of RIPE Documents might have some gaps. <o:p></o:p> 3) Draft scope - feedback from mailing list Filiz said they needed to respond to Daniel's feedback on the RIPE Discussion List. <o:p></o:p> Nurani said she didn't think anyone in the TF thought they needed to produce new processes for the community. She did take his point about the timeframe. If they hadn't been clear enough, they could improve this. They shouldn't be making this overly complex - but that didn't mean they couldn't map out what was already there. And procedures could also be simple – something could be as simple as "a Chair declares consensus in a room". Athina said the crux of the issue seemed to be the second bullet point - "Document existing RIPE community structures or processes where needed." She thought that where they had an easily accepted practice, the TF could produce something documenting this. This seemed to be what he was objecting to. She noted that TFs had documented procedures in the past. She thought they should clarify what they intended to do around this point. The concern was that the TF might create a document and the community would have no idea where it came from, but this could be solved with clear communication and regular updates. Malcolm said he thought the key point with that bullet point was "existing". Peter said he believed that Daniel's wider point was about applying formality to a community that generally believed "in the absence of rules, common sense will prevail". They needed to clarify that they didn't have to fill in all of the gaps they found. He could see where Daniel was coming from here. Filiz said the draft scope wording might be problematic but what they were attempting to do was not - their main purpose was to review existing accountability, and identify gaps that would be worth filling, and document them in a way that would help the community to discuss the issue. Carsten said it might be a good idea to offset this a little bit, where the first part was the work to be done, and the second part was the results they were trying to achieve. Peter said he'd rather not see them do a pure paper-status evaluation - they weren't certifying RIPE for an ISO standard. The important part was to map the reality to the documents and vice versa. It was about looking at the PDP or the WG Chair selection processes and how things worked in practice. Maybe this was already covered in the scope, but he didn't read it that way. He'd like to have the reality-check aspect included in there rather than just producing papers and having others produce papers. Filiz asked Peter to elaborate. He said that looking at what was documented was valuable – but there was a real life component that they might miss if they only looked at accountability in terms of documents. The PDP was used in various WGs, and the way it was lived and mapping this against how it was documented seemed to be the real task in front of them. He didn't see this reflected in the current scope. Filiz asked if he was looking for a more detailed scope. She added that they should change "ensure" in the first bullet point to "verify". Peter said if they just looked at the documentation they could find that everything was fine and safe. Accountability meant more than that to him. The bullet points to him seemed to be about producing documentation. Nurani understood Peter's point that just mapping and documenting didn't in itself improve accountability. But she needed to separate the mandate of the TF from the community. She thought the TF did have the mandate to fix some things. If they saw that something was broken, they could either point this out to the community and ask what they thought, but in some cases, it might be a simple fix where they could come up with a recommendation. But it wasn't up to them to try and fix all the broken processes in the community. In some cases the community might say "we are fine with this broken process, go away" and that would be fine. Malcolm said they clearly didn't have the authority to change processes, they could only raise things with the community which would include recommendations of why and what – and maybe recommendations of how to change things. He didn't think it was out of their mandate to recommend something. He thought that this was ultimately a small detail and they shouldn’t get hung up on it. He said they all agreed that they wouldn't be dreaming up incredibly complex new processes, but they might be able to say to the community "here are some things we've found and here are some recommendations to get the ball rolling". William said if there were any more comments, TF members should share them on the list sooner rather than later, as they needed to wrap this up. 4) Review of timeline Antony ran through the draft timeline he had prepared: <a class="moz-txt-link-freetext" href="https://calendar.google.com/calendar/embed?src=89m7nafm0qmn2dk1phn76ek48c%40group.calendar.google.com&ctz=Europe/Amsterdam">https://calendar.google.com/calendar/embed?src=89m7nafm0qmn2dk1phn76ek48c%40group.calendar.google.com&ctz=Europe/Amsterdam</a>  <o:p></o:p> He said the idea was just to create a series of regular deadlines for work to be passed between the RIPE NCC and the TF, structured around a call on the first Monday of every month. He said the RIPE NCC could maintain this and TF members could email him with anything they wanted to add. <o:p></o:p> There were no comments. 5) RIPE 74 preparation (presentation and tf meeting) Filiz said the RIPE NCC had helped to prepare some draft slides that she had submitted to request a slot. They had gotten 30 minutes on Tuesday morning at 9am. She said they would try to keep the presentation to a bare minimum and gather comments from the audience. She said she would like to be able to share their draft mapping document with the community ahead of this session with most of the fields completed.<o:p></o:p> Antony ran through the organisation of the TF’s face to face meeting at RIPE 74. He said it would be during the Tuesday lunch break and he would send around a poll to get attendance numbers for the catering. Athina asked if they should enable remote participation options for the meeting. William said could ask this in the poll and decide when they had an idea of attendance. 6) Review of action items 20171801-02: RIPE NCC to come up with draft timeline for the TF.<o:p></o:p> <o:p></o:p> William said they could close this action. <o:p></o:p> <o:p> </o:p> ***Action: Respond to community comments on ripe-list regarding draft scope.*<o:p></o:p> <o:p> </o:p> ***Action: TF to revise draft scope.*<o:p></o:p> <o:p> </o:p> ***Action: RIPE NCC to send around poll for face to face meeting at RIPE 74.*<o:p></o:p> 7) AOB William said next meeting would be in one month. In the meantime, he encouraged TF members to comment on the document that would be circulated after the call. <o:p></o:p> <o:p> </o:p> Paul said he wanted to make sure they were on the same page about how they presented the mapping document to the RIPE community. He said it was quite a lot to digest and they needed to find a way to distil the findings in the document down to something that could be understood easily. <o:p></o:p> Malcolm said the document was just a working material they had come up with to help them to identify what needed to be worked on. They were just starting out and this was all this document represented. Filiz agreed with Malcolm but saw Paul's point. She said the decision about what to do at the RIPE Meeting seemed to be the correct one – she said previously the idea was just to give an update, so in that 30 minutes just to give a status update to show the community where they were, and they had a document they were digging into to get them to the next phase. She agreed that they needed to communicate this well – because this was not the output. She said they would work with Antony and Paul about how they should message this. William thanked everyone and said they should continue this on the ML.<o:p></o:p> <o:p> </o:p> Action Items<o:p></o:p> <o:p> </o:p> 20170403-1: Respond to community comments on ripe-list regarding draft scope.<o:p></o:p> <o:p> </o:p> 20170403-2: TF to revise draft scope.<o:p></o:p> <o:p> </o:p> 20170403-3: RIPE NCC to send around poll for face to face meeting at RIPE 74.<o:p></o:p> <o:p> </o:p> 20170306-1: RIPE NCC to further develop accountability mapping document with task force input.<o:p></o:p> <o:p> </o:p> 20170306-2: Task force members to review and comment on accountability mapping document.<o:p></o:p> <o:p> </o:p> Closed Action Items<o:p></o:p> <o:p> </o:p> 20171801-02: RIPE NCC to come up with draft timeline for the TF.<o:p></o:p> <meta name="Keywords" content=""> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="ProgId" content="Word.Document"> <meta name="Generator" content="Microsoft Word 14"> <meta name="Originator" content="Microsoft Word 14"> <link rel="File-List" href="file://localhost/Users/agollan/Library/Caches/TemporaryItems/msoclip/0clip_filelist.xml">  <link rel="themeData" href="file://localhost/Users/agollan/Library/Caches/TemporaryItems/msoclip/0clip_themedata.xml">  <style>  </style> </body> </html>