[Accountability-tf] Draft Accountability Task Force Report - Please Review

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