[ripe-list] LAST CALL EXTENDED to 18 Feb: Draft Document: RIPE Task Forces - Definition and Guidelines

Colleagues

I almost decided not to send these thoughts. But after a couple of
other related emails this weekend I decided to go ahead with it. I
hope they are received in the same good faith they were written in.

This document on Task Forces (TF) is interesting, but one problem is
that it assumes that a TF will always achieve it's goals. But what if
it doesn't? There are many reasons why it may not do so. The goals may
be unrealistic or unachievable. The scope may be too wide. The TF
members may not have all the necessary skills. The TF may go off in
the wrong direction or produce something that wasn't expected. This
document does not include any option for a review or even a reset
during the course of a TF's operation. Who would call for such a
review and who would do it? It assumes the TF will simply run to it's
own conclusion and then whatever it produces will become a RIPE
document by default. This document will then be considered as the
fulfilment of the TF goals.

A TF should not work for long periods of time in a quiet, background
mode. Keeping the community well informed of it's work and progress
are important elements of a TF. You mention that a TF must have a
mailing list for community feedback. I would add that it should be an
open list. If the community cannot post to that list it is not a
mailing list, it is an announcement board.

Criticism is a part of life. Most people in most areas of work have
their work periodically reviewed, by a manager or senior. Scientific
and engineering papers are often peer reviewed, before or after
publishing them. This is what keeps developments moving forward. In
this community people who offer an honest, objective, professional
critique are themselves sometimes criticised for being critical. To
suggest something didn't achieve it's goals (sometimes a polite way of
saying it failed) is often considered unacceptable. To criticise a
piece of work can be seen as criticising the author, who may then feel
offended. Everything that has ever been written has one or more
authors, editors, contributors. If we can't criticise a piece of work
for fear of offending the author then we can never criticise anything.
TFs are no exception to this. Criticising the work of a TF in good
faith should not be seen as criticising any member of the TF. The
active element of this community is not very large. You may well know
all the members of a TF and have a high regard for them as
individuals. That does not obligate you to accept every piece of work
they ever do. If it is wrong, it is wrong. It should not be wrong to
say so. If criticism has a good foundation and strong arguments, then
it doesn't matter how extensive the criticism is. It is the piece of
work that is being criticised, not the people who produced it. If we
can't accept that difference then we are in trouble. A TF is not about
being praised for effort. On a personal level that is nice, but if you
join a TF it is also expected. A TF is about achieving the stated
goals. If they are not achieved it should be OK to say that. To praise
a piece of work, that you don't believe is correct, simply because of
the effort put into it, does not benefit anyone.

This is why it is important for a TF to have regular communication
with the community, especially over a long period of operation. When
criticisms are made a TF should address those concerns. By saying
'address' it does not mean they must agree with the criticism. But
they must acknowledge it and either accept it or provide arguments
against or justify dismissing the criticism, just as we would in a
policy proposal discussion. For a TF to ignore criticism is not
acceptable. Someone needs to oversee this. If a TF does not address
criticism, that in itself needs to be addressed.

This document covers the issue about not meeting the deadlines for the
TF operation. But what about a TF that does not follow it's
methodology or charter? Who should monitor this and what actions
should be taken?

Looking at the various TF web pages they are all different. They have
similar sections but with different headings. In some cases it is not
easy to determine the goals of the TF. These pages need to be
standardised.

You refer to RIPE NCC staff members as 'support staff'. Why can they
not be full and active members of a TF? For the Data Protection TF,
Jochem and I were full members of the TF. At the time we were staff
members. Chairs should also be eligible as TF members if they have the
appropriate knowledge, experience and/or skills, even if the TF
relates to their own working group. TF members should always be listed
on the web page.

You say TF members should make the RIPE Chair aware of any potential
conflicts of interest. These should be published on the TF web page
for transparency.

You say the TF should give regular updates to the RIPE Chair. They
should also regularly update appropriate working group chairs.

You only refer to consensus in terms of the final report or a
community document. There is no acknowledgement that a TF may need to
build a clear community consensus at various stages of it's work.
Especially when the absence of such consensus may mean the TF is
making fundamental decisions which may affect the validity of the
later work. Where consensus is needed on a significant point in the
work of a TF, that should probably be discussed in a relevant working
group with the chairs determining consensus.

I am not trying to put people off being part of a TF, but we do need
to define what it means to be a part of one...and accept that a TF may
not always be successful, no matter how much effort you put into it.

cheers
denis
co-chair DB-WG



>     Dear colleagues,
>
>     I believed I had sent this message to you all on 21 January, but
>     discovered only today
>     that I had picked the wrong recipient, from the list of those beginning
>     with “RIPE”
>     which my mail app presented.
>
>     At that time, Mirjam and I felt that a two-week extension to the last
>     call would be
>     appropriate, as the suggestions received in advance of the original
>     deadline
>     appeared uncontroversial, but ought of course to be subject to community
>     review.
>
>     This extension would have expired tomorrow.
>     This would clearly be unreasonable, so we have set 18 February 2022 as
>     the new deadline,
>
>     Please accept my apologies for my mistake.
>
>     On 16 Dec 2021, at 15:21, I (Niall O'Reilly) wrote:
>
>     > On 19 Nov 2021, at 8:48, Mirjam Kuehne wrote:
>     >
>     > Based on experiences and feedback received from existing Task Forces
>     > and
>     > other community members, we put together a document describing what a
>     > RIPE Task Force is and how it usually operates:
>     >
>     > https://www.ripe.net/publications/docs/ripe-documents/other-documents/ripe-task-forces-definition-and-guidelines/
>     >
>     > Please let us know if you have any questions or suggestions. This will
>     > be published as a RIPE Document.
>     >
>     > Mirjam and I have updated our draft in line with the suggestions we
>     > received.
>     > The new version has been placed at
>     > https://www.ripe.net/publications/docs/ripe-documents/other-documents/ripe-task-forces-definition-and-guidelines.
>     >
>     > We consider that it is now time to make a LAST CALL for further
>     > comment,
>     > with a deadline of 17:00 UTC on Friday, 14 January 2022.
>     >
>     > Shortly after this deadline, we plan to declare that this document has
>     > Community Consensus and to arrange for its publication as a RIPE
>     > Document.
>
>     We have updated the text to take account of some suggestions received
>     during the last call period, and are therefore extending the last call
>     period until 17:00 UTC on Friday, 18 (not 4) February 2022 to allow
>     comment
>     on the latest changes only.
>
>     Updated draft:
>     https://www.ripe.net/publications/docs/ripe-documents/other-documents/ripe-task-forces-definition-and-guidelines
>     Tracked changed (PDF):
>     https://www.ripe.net/resolveuid/4ce5895954d249f59bbb5aaa9f71a421
>
>     Thanks to Cynthia Revström and Randy Bush for their helpful
>     suggestions,
>     and to Boris Duval of the RIPE NCC for preparing the updated document.
>
>     Best regards,
>
>     Niall O’Reilly
>     RIPE Vice-Chair
>