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

[Daniel Kahn Gillmor]

On Wed 2018-07-25 14:59:25 +0800, intrigeri wrote:
> Ulrike and I hereby propose that our team adopts a formal process for
> membership and decision-making, which we currently lack.
>
> The proposed text is attached.

Thank you to both intrigeri and Ulrike for leading the way on writing
this down!  I really like this work.

I'm afraid that the current proposal is unclear to me, though.

Is the proposal in a git repo someplace, where i could propose specific
amendments, or do you prefer patches to the list?

Also, i note that there is both
https://salsa.debian.org/pkg-privacy-team and
https://salsa.debian.org/privacy-team

should we try to consolidate them?

Timing
------

In particular, the timing of 2(a) is ambiguous.  what does "at the time
of the proposal" mean?  Surely, no one can "vote for" a proposal at the
time it is made.  does this mean "before the proposal's time limit
expires?  If so, are we saying that a proposal is passed as soon as
there are three votes in favor before the time limit hits (i.e. it could
happen earlier than the time limit)?  or does the proposal have to
"ripen" through the full time limit before it is adopted?

I like the idea of needing to allow some time for objections, so that
decisions can't just be rammed through by a small group.  otoh, i don't
like the idea of having to wait a long time for something that everyone
clearly thinks is a good idea.  Perhaps two weeks isn't "a long time"
though :)

If we want to be more complicated, we could have a larger number of
positive votes (e.g. 2N/3) that permits short-cutting the timeout.  I'm
not convinced that the complexity is worthwhile though.


Clarity of "votes"
------------------

Right now, i'm voicing concerns about this proposal that i hope will be
read as encouraging friendly amendments.  But it's not clear to me
whether i'm in the process of producing a "negative vote".  It's
probably not clear to you reading this either!

How about section 3.2 making it clear that a positive or negative vote
for a proposal should contain some magic language so that it is
unambiguous?  e.g., "I support this proposal" vs "I oppose this
proposal" are clear "votes", but the message i'm currently writing is
not.

Carve-outs from "decision-making"
---------------------------------

Section 3.3 appears to create a carve-out from the standard
decision-making process specifically for team package adoption.  In
particular, it looks like team members can unilaterally cause the team
to adopt a package with no delay.

That sounds fine to me!  But if this is a carveout from the
"decision-making process", maybe it should be explicitly stated as such.

Orphaning a package
-------------------

We talk explicitly about how to add packages.  But we don't talk about
how to drop them, whether that's by orphaning or filing an RM bug.  We
can't maintain an infinite number of packages, so something has to give
:)

I assume that dropping packages would be handled via the regular
decision-making process.  Maybe we should make that explicit?


All the best,

    --dkg