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-t... > > 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-t.... > > 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-t... 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