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

[intrigeri]

Hi,

Antoine Beaupré:
> I have a few questions, however:

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

>  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?

Say I'm contributing to the team by triaging bugs using an untrusted
Windows XP system. For some reason I've added my SSH key on Salsa
(e.g. to contribute to random untrusted forks). I might not feel
having commit access to a bunch of sensitive Git repos, because having
these credentials would add responsibility/pressure both on myself and
on my peers (who have to be extra careful when they fetch from any of
the team's repositories).

>  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/

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

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.

>  Outside of this team, are there any other examples of any such
>  process?

I'm not aware of other teams having such formal processes in place but
Debian is big :)

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

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.

Cheers,
-- 
intrigeri