[ripe-list] Draft Document: RIPE Task Forces - Definition and Guidelines - v3

Jordi,

I think you are confusing the role of the task force. The TF doesn’t replace or remove the community’s role in scrutinising and approving any policy - it is merely a vehicle  to produce an analysis or proposal that can act as a starting point or input to a community process and decision. There is no exclusion of views as any community member have the right to participate in the community process, but it is in the interest of the community that the TF output is speedy in order for the community process to start.

I don’t see any of the issues you mention below. A TF is meant to be small and agile which imply that not all of the community can take part in it. We need a simple and fast process to form the TF and produce the community input. We don’t need complicated selection and appeal processes which will just produce bureaucracy and does not increase quantity or  value in community input.

- kurtis -

> On 10 Apr 2022, at 19:01, JORDI PALET MARTINEZ via ripe-list <ripe-list at ripe.net> wrote:
> 
> Hi Gert,
> 
> Clearly the goal is to get the job done.
> 
> If TF members "a, b and c" agree to work on that, but they disagree to work with "d, e and f", and "d, e and f" have no problem to work with "a, b and c", the ones that are avoiding the work to be done is "a, b and c", not the others.
> 
> So, either we form two TFs for the same and then see the results for 2 TF for the community to decide, or, because the problem to work with others is "a, b and c" they should either decide to change their view, or not joint the TF.
> 
> Further to that, are you suggesting that the Chair should ask all the possible volunteers if they are ok to work with all the others? And if not, the Chair should benefit "a, b and c" instead of "d, e and f"?
> 
> This sounds to me like extremely worrying and outrageous. It is not a clear way to say the Chair should discriminate "d, e and f" because others aren't willing to work with them? Are we going to investigate the reasons and decide based on that? Or in that case the Chair should say "if a, b and c are willing to work with the others, they are free to leave, but we will not exclude anyone". Or are we saying that the transparency, openness, inclusivity, diversity, etc., etc., from this RIR community is no longer there?
> 
> My personal way, when I'm contributing with anything related to any community is that I must take apart any differences (personal, business, others?) that I may have (if any, because I don't feel actually, I've any), and work towards the goals in the direction that I believe is best for the community. According to what you say, it looks like my personal view into "contribute to the community" is not shared by you; fine we can disagree on that, but that's not seems sufficient for trying to exclude others, it is your personal decision, not a community decision.
> 
> How many times we have disagreed with colleagues about this or that proposal or comment in the list, or whatever, and that doesn't mean that in the next minute we find a way to reach consensus in the same or another topic? And if there is no consensus (or chairs believe there is no consensus), even if we go for an appeal, never mind what is the final decision, even if we keep disagreeing and we openly express our opinions, that doesn't mean that we should not be able to continue working together, right?
> 
> If we accept your position, we are asking the Chair to discriminate one way or the other. This is unacceptable. This is not about "a, b, c, d, e, or f", is about what is the best for the community, but NEVER excluding others. If we exclude others, this is no longer open, this is no longer a community.
> 
> As you correctly say very well, if a TF is excluding one or more volunteers, then those volunteers can do the work in parallel with the TF, and they can publish it and the community will need to hear both. If the Chair disallow that, again, we are enforcing the Chair to discriminate people, but the worst is that the community will need to look into the results of both TFs (if both become "official" or not is not relevant), because all them, anyone from the community, have the right to publish any documents that they do for the overall good of the community.
> 
> Regards,
> Jordi
> @jordipalet
> 
> 
> 
> El 10/4/22, 17:34, "ripe-list en nombre de Gert Doering" <ripe-list-bounces at ripe.net en nombre de gert at space.net> escribió:
> 
>    Hi,
> 
>    On Wed, Mar 23, 2022 at 02:38:32PM +0000, Niall O'Reilly wrote:
>> Please let us know what you think, in sufficient numbers so that we can
>> understand whether the draft enjoys community consensus.
> 
>    I find v3 a reasonable description of the roles and processes of (formal)
>    task forces, and what to expect and not to expect.
> 
> 
>    I explicitly disagree with Jordi's repeated comments about the requirement
>    for a non-discriminatory participation.  TFs are not something to be voted
>    in, or to govern anything, but to get a job done - and due to human nature,
>    you'll have volunteer groups that are incompatible.
> 
>    Force-permitting someone "in" that the other volunteers refuse to work with
>    might look good on paper ("yay, we're so non-discriminatory") but will
>    just break the intent "get work done".
> 
> 
>    We shouldn't overvalue the "task force" stamp on a group of volunteers -
>    it's a formal vehicle to request support from the RIPE NCC, and to agree
>    on "this is the work we set out to do" (and volunteers are expected to
>    have time to do so).  This does not mean any *other* group of volunteers
>    couldn't just sit together, get work done, and bring the resulting document
>    up to a working group for larger consensus and publishing as a RIPE document
>    (like, the documents coming out of the IPv6 WG).
> 
>    So, no, task forces in general are not a vehicle of exclusivity that would
>    need all this hubbub about full inclusion.
> 
>    Gert Doering
>            -- NetMaster
>    --
>    have you enabled IPv6 on something today...?
> 
>    SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
>    Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
>    D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
>    Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
>    --
> 
>    To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/
> 
> 
> 
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
> 
> 
> 
> 
> --
> 
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP
URL: </ripe/mail/archives/ripe-list/attachments/20220411/92ef5fb0/attachment.sig>