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

[u]

Hi Daniel!

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?

Let me upload that to
https://salsa.debian.org/pkg-privacy-team/team-processes … Done.

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

I'll ask Ximin about it later, he seems to be the one who created the
latter.

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

Specifically in 2(a) "at the time of the proposal" means that at the
time the proposal is made, either 1/3 of the current members or 3 people
are needed to vote.

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

The proposal can ripen before it is adopted. Full time limit required.

> 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 :)

But you can prolong these two weeks, see 2(c).

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

I think that clearly becomes too complicated.

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

Improving/patching the proposal does not sound like a negative vote to me :)

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

Thanks for field-testing :)

I agree with your amendment. Should I add that to the proposal or will
you propose a patch?

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

Fine with me.

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

Good idea.

However it seems to me that the status quo of work in the privacy team
is that despite being team maintained, packages are taken care of by
specific individuals. I'm in favor of shifting this status quo to real
team maintenance at some point.

So let's explicit this point. Will you take care of this or should I?

Cheers!
u.