[Pkg-privacy-maintainers] Proposal: membership and decision-making process

[u]

Hello!

intrigeri:
> Antoine Beaupré:

>>  1.3.a) How will the contacting process work? This adds a hard work
>>         overhead for someone in the team to contact everyone in the
>>         list, and keep a tally of who's active...
>>         While I see where this is coming from, changing this from
>>         a WILL to a MAY could make things easier to manage...
> 
> Right. If ~two people take turns to go through this process (each of
> them every second year or so), this should not add *that* much
> overhead. I could be one of these two people. Alternatively, this
> process can be triggered only whenever we feel the list of members
> does not accurately reflect real activity *and* this causes actual
> problems (e.g. power over vs. power to). Therefore, I would gladly
> vote in favour of a proposal with s/will/may/ there, either as an
> alternate proposal or as a future amendment.

Ack for the MAY. Currently there are 4 team-administrators, I can be
another person taking care of this ping.

>>  3.1.a) I am not sure I understand the point of "least privilege" here
>>         if it's decided by the member and not its peers. Why would
>>         anyone choose to partially (or even less fully!) opt-out of the
>>         resources?

You could also want to simply contribute to one package but not all of
them, in the end they're not necessarily written in a language everybody
understands.

>>  1.2) It might be useful to define some guidelines to explain why a
>>       member could be explained. I have worked on other free software
>>       projects in the past where we base this on
>>       contributor-covenant.org but another code of conduct (Debian's??)
>>       could be cited as an example here, maybe?
> 
> (Assuming s/explained/expelled/ :)
> 
> Good question! I'm fine with pointing to a code of conduct as an
> example but:
> 
>  - we're already operating under Debian's code of conduct;
> 
>  - in my experience, reaching agreement on a code of conduct can be
>    a long process, that takes lots of energy, and de facto excludes
>    team members with less free time (which "incidentally" overlaps
>    with the set of members of under-represented social groups in
>    FOSS); not to say we should not try but let's be aware of
>    this caveat; unsurprisingly I like this one:
>    https://tails.boum.org/contribute/working_together/code_of_conduct/

+1!

>  - let's also avoid creating "an exhaustive list of things that you
>    can't do"; there are plenty of subtle ways to be toxic and make
>    other people want to cry or disappear, that are not covered by the
>    typical list of truly-really-obviously-unacceptable behaviour.

Ack with this.

> If someone is interested in leading this process, I'm happy to
> contribute a little bit to it. I'd rather see this process not block
> the current proposal though, but instead be a future amendment
> assuming this one passes.

Same here.

>>  It would be useful to share this with the rest of the Debian
>>  team
> 
> Pointing individuals/teams that often do conflict resolution of some
> kind (anti-harassment, DAM, DPL) to this document may be useful:  in
> some cases they might want to suggest other teams to set up some
> (possibly similar) processes when the lack thereof causes problems.

Ack.

> But wrt. publicizing this more broadly, personally I'd rather see this
> process field-tested in the context of our team before I point many
> more eyes to it.

Ack.

<3
u.