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 > <[email protected]> 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" > <[email protected] en nombre de [email protected]> 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://lists.ripe.net/mailman/listinfo/ripe-list > > > > ********************************************** > 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://lists.ripe.net/mailman/listinfo/ripe-list
signature.asc
Description: Message signed with OpenPGP
-- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/ripe-list
