Re: Proposal - Project infrastructure team procedures
On Wed, Apr 30, 2008 at 11:54:13PM -0500, Manoj Srivastava wrote:
> >> What bothers me about all this is that we had a nicely detaled
> >> document that spells out who has what rights, and it seems fairly
> >> clear to me that all powers in Debian stem from the powers laid down
> >> there; but that nicely detailed document is not enough.
> >>
> >> What makes one thing that any non-supermajority GR which says
> >> essentially the same thing as the constitution will have any weight?
>
> > The Constitution is nicely detailed, but it doesn't recognize
> > infrastructure teams. It doesn't have a generic handler (so to speak)
> > for groups of developers - it does handle delegations which can expand
> > into N developers, but this is done in a completely impractical way,
> > judging by history.
>
> Are teams of delegates not just multiple delegated developers,
> who are individually covered by the constitution?
Well, if a team decides to expand on its own, which they do normally, this
is simply not covered by the constitution, at least not AFAICT - section 8
doesn't mention any such thing.
So, even if we assume here that the constitution made all team members
implicit delegates at one point, all further decisions by those original
delegates to share their work with others effectively make those other
people delegates, but they can't be replaced by the leader because a) the
leader never appointed them and b) it would be overriding a decision made by
a delegate. And the leader can't get those other people's permissions
revoked via proxy, because the proxy is the implicitly delegated sysadmin
team, whom they can't command. D'oh!
Yet, there is a workaround - the leader can post res delegate and then
immediately undelegate the same thing to/from those people. The first
part can contradict the second sentence of the general rule 2.1.1.,
but the second part is allowed by the third sentence of the same rule.
But in any case, this whole idea is plain ugly.
The other part of my impracticality complaint is the simple fact that it
doesn't actually properly describe the situation as it is, because,
to my knowledge, not only haven't the delegations been done as described,
but the leader never actually replaced people in any of them (8.2),
and the developers never made or overrode their decision (4.1.3),
or delayed their decision (4.2.2).
About the only thing in the constitution that is relevant for the
infrastructure teams in general is 8.3 - that they make decisions
as they see fit. That's not a good coverage.
> >> Are people who were grandfathered by the constitution (or some such
> >> equally silly argument) not also grandfathered by this forthcoming
> >> GR? What changes?
>
> > That's a good question, and the reason why I initially proposed that
> > we don't try to force the delegation/undelegation system as it is - it
> > doesn't seem entirely appropriate for the teams because some things
> > simply predate the notion of a project leader, it will easily seem
> > anachronistic and pretentious for the leaders to be able to undelegate
> > someone's access to something they've created and maintained for a
> > decade, without requiring any sort of a criterion to base that
> > decision on.
>
> > But others don't seem to mind that...
>
> Err, no one has an absolute right to project resources, even if
> they have maintained the resource for the project for a decade. And no,
> I don't think a lot of people have a problem with that. I certainly do
> not.
>
> These are not individual resources, they are _project_
> resources. Access to project resources is governed by the
> constitution, and is delegated to individuals for a certain period. The
> resource ownership remains with the project, and it can, by mechanisms
> detailed in the constitution, take the delegated pwoers away. No matter
> how long the delegation has lasted.
>
> The lack of major upheaval in reaction to the recent delegations
> certainly point to the fact that all the fear, uncertainty and and
> doubt people had about what would happen if you added people to core
> teams were somewhat overblown.
Notice that that recent action was adding, but we have never seen any
removing, which is what I described above.
--
2. That which causes joy or happiness.
Reply to: