On 13/04/2018 12:32, William Sylvester wrote:

Task Force,

As we work towards our final deliverable, I wanted to reiterate the importance of feedback for this document. Please take some time to read it, and please return comments. If you feel this document is ready to submit to the community without changes please post on the list with that support so we know you have read this document.

William, all, Firstly, I'm afraid I won't be able to make this afternoon's call. I'm at a conference, and will be on stage at that time (introducing Athina! So she won't either). I understand that today is the "Go/No Go" call on committing to launch this document in time for the RIPE meeting. In my opinion, while this document says a lot of good things, and very well, I don't think it is currently in the state I would want it to be to release to the community. Maybe I'm being too perfectionist, but I view this initiative as very important, and given the criticism and indeed opposition we've had from some quarters, I would really want to get this document to a very high level before release in order to maximise the chance of winning community support. The main areas I see as needing improvement are not really the substantive statements made, but the "meta" description of how the document (and the process, and the need for it, and what we achieve if we get community support), are presented. So I would advocate, at minimum, * Adding a new, replacement introduction that expresses support for existing community culture and process. In particular, though, we need to make a clear, explicit and prominent argument that documenting core principles is necessary for specified reasons. (Such reasons include - guiding leaders (effectively, WG chairs) - assisting leaders in defending their decisions, by giving them something to point to - training new/future leaders, allowing fresh blood to be brought in without risking dissonant values/assumptions being disruptive - educating new community members, on what to expect, and so they will become effective advocates and defenders of the RIPE approach in time, and indeed leaders themselves in due course) - educating outside stakeholders) * Changing the order of existing introductory material, to radically de-emphasise the reference to ICANN transition: the message should be that this process is being done by us, because we think it is valuable to us (oh, and by the way others are going through this too), not that ICANN did this and now the spotlight is on us (i.e. that we're on the defensive, and responding to ICANN demands). * More of what I call "Reader support": stuff that helps the reader cope with reading a big, weighty document by separating out the various chunks and *explaining* that they've been separated, and how, and why. - So for example, the section on defining "Rough Consensus" is really in a different category to the section that catalogues the different entities and structures and reviews whether we've found documentation. But the reader is just left to discover this, with no warning. * The Recommendations section, as it stands, is a very bare list of demands, with almost no discussion of what is meant or why those recommendations are made, or how we would expect RIPE to approach implementing them. - To be honest, this is more "note form" from our discussion, than something we can expect a neutral, let alone sceptical, outside reader to engage with and support - We certainly risk being accused of asking for endless process documentation, exactly what our critics accused us of at the start of this project. - To some extent, this could probably be cured by simply expanding each point with a few sentences of explanation of what is intended and why it would be helpful, and avoiding the bare term "documentation". - In any case, we haven't really discussed these in depth, and if we get challenged as to what is meant, I don't think we'll have a consistent or coherent answer. * This is supposed to be published for community consultation, but as yet we have no rubric about that. - Adding a bit of rubric is easy enough, but a proper consultation should clearly distinguish between those aspects that we clearly believe, and for which we simply ask the community's support (such as the notion that RIPE is a principles-based decisionmaking, that the core principle is rough consensus, and that rough consensus is judged by the chair by applying a set of community-wide principles) from those on which we're only offering a tentative suggestion, on which we really want community input (e.g. what is the content of those community-wide principles that the WG chairs are supposed to apply e.g. Is the Internet is for everyone really a RIPE principle, and if so, what does it mean in a RIPE context? Surely something different to what it means to ISOC). - Doing this properly means both explaining the divide between our core approach and tentative suggestions, and developing broad questions for the first (Do you think we're basically right about this) and questions seeking more specific answers/commentary for the second). All the above said, I recognise the pressure to release in time for the next meeting. So there's a separate question, can we be sure now that if we commit today to release within the next couple of weeks, we can between now and then do sufficient work that we will meet the standard I think is necessary? My own sense is that I doubt it. And, as I say, I place a very high premium on getting this "right first time"; recognising that nothing will ever be perfect, I still think we need to win the community's support first time that we're basically on the right track, or we risk getting shut down on the spot. For these reasons, I am tentatively recommending that we call it "No Go" today. Instead, I recommend that we present at the RIPE meeting that: (a) we've concluded, or are in a wrapping up phase, on the substantive commentary, but (b) we're just starting on the (all the above), and explain why we think doing all that first is important. This is an engineering community, and they understand the difference between rough prototype and something that's been productized. In my view, we have a viable prototype from which to build. If the Taskforce still thinks we should go ahead, perhaps with Antony addressing the above as best he can in the next two weeks, I understand the competing pressure. And I'll try to offer what support my diary allows (very little this week and next, perhaps a bit more later). But my advice is to give ourselves another quarter. Kind Regards, Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd Monument Place, 24 Monument Street London EC3R 8AJ Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA