Re: Initial draft proposed consitutution (v0.2)
Executive summary: v0.2 at
http://www.chiark.greenend.org.uk/~ian/debian-organisation-0.2.html
Reminder: reply to the list, not to me.
Manoj Srivastava writes ("Re: Initial draft proposed consitutution (v0.1)"):
> When the document says 2:1 vote etc, does it mean 2:1 of the
> total voting membership, or 2:1 or the set of people who actually
> voted?
The latter. I have added some rationale.
> Secondly: I think we need to have the constituition mention
> the DFSG.
No, that's not the point of the constitution. The DFSG will be passed
in accordance with the constitution.
Raul Miller writes ("Re: Initial draft proposed consitutution (v0.1)"):
> Ian Jackson <leader@debian.org> wrote:
> > <URL:http://www.chiark.greenend.org.uk/~ian/debian-organisation.html>
> >
> > Please comment on it - here on debian-devel, please, rather than by
> > private email.
>
> (1) I don't see anything about testing this mechanism before committing
> to it. I'd like to see something along this line. Perhaps only that
> we have a suspension of rules for one week to obtain a consensus on
> how it's working -- perhaps after using it for a month, and again after
> a year?
I propose to run the mechanism itself through itself, IYSWIM, and to
test it on the DFSG and Social Contract and a new Project Goals
document.
> (2) It seems to have a flaw: it assumes that we can know who the
> developers are. Since we never meet, I'm not sure this is a valid
> assumption. It would be fairly easy, for instance, for somone to set
> up multiple email addresses, multiple pgp keys, and maintain multiple
> packages (one from each account). [Personally, I have a variety of
> email addresses in a variety of domains, though I've never used them in
> this fashion.] Another risk is inert memberships: does the whole thing
> come grinding to a halt if we have a lot of developers who are only
> occasionally active? Having deadlines and procedures is probably good,
> putting much significance on counting ids probably isn't.
>
> Or maybe we don't care?
Well, it would be nice to have better verification. However, we do
currently have a new-maintainer verification mechanism which aims to
prevent `fake people' from becoming maintainers.
On the other hand: suggest a better way of making the kind of
important decision I'm suggesting would be done by vote. Previously
we had flamewar-followed-by-fiat, which I don't think worked
particularly well.
> (3) The technical committee's voting requirements do not make sense.
> First, the "Standard Resolution Procedure" seems designed for
> potentially controversial decisions involving a large number of people
> -- the technical committee has a maximum of 8. Also, technical decisions
> are better handled using the "rough consensus and working code" model,
> in my opinion. Second, there's no minimum time for the vote to take
> place, no minimum number of people required to vote -- how is this
> supposed to work?
It works like this:
* discussion on debian-policy or elsewhere about something
* technical ctte is asked to or decides participate on a matter
* tech ctte members sound each other out about the options (which
are supposed to have been discussed elsewhere)
* one tech ctte member says `I propose the resolution X and call for
a vote'
* the other tech ctte members each say `I agree' until the `agree's
outnumber the abstentions.
I see that I must have accidentally cut out the part where the voting
periods were specified !
Drake Diedrich writes ("Re: Initial draft proposed consitutution (v0.1)"):
> On Thu, 19 Mar 1998, Ian Jackson wrote:
>
> > Please comment on it - here on debian-devel, please, rather than by
> > private email.
>
> Just scanned it, first comments:
>
> Section 6.2.4, Technical Committee Overruling a developer:
> If no one is willing to implement the bug fix or take over maintenance
> of a package, I believe the developer should still retain the last word.
> Perhaps such bugs could be downgraded to Wishlist.
Well, the developer can always refuse. It'd be (ahm) interesting to
see what happened then.
I've added a paragraph saying that there is no obligation to act.
> The Secretary appears to be a single point of failure. It looks like a
> rather large job. If the secretary is temporarily unavailable, no one is
> authorized to fill in, and any votes must wait on their return or a new
> appointment. Perhaps an Assistant or Delegate could be authorized to take
> minor votes (resolutions).
Fixed this.
> I'm a bit unsure of the intended role of Delegates. Could you
> elaborate on the types of tasks you see them performing?
Well, sysadmins, mailing list managers, that kind of thing, if they
want some kind of formal basis.
Also, the new-maintainer people (who are the gatekeepers to being a
developer) need formally defined authority.
> s/seperate/separate/ :)
Fixed.
> Section 9.2.2 appears to be missing a "no".
Fixed.
> Is the Standard Resolution Procedure intended to replace the informal
> discussions and policy changes currently held on debian-policy? It looks
> like SRP would be much slower (which might be a good thing).
No, but you could force the SRP to be used within the technical
committee by going and arguing a lot ! Technical decisions will not
be voted on by developers at large.
Tyson Dowd writes ("Re: Initial draft proposed consitutution (v0.1)"):
> On 19-Mar-1998, Ian Jackson <leader@debian.org> wrote:
> > I have put my first draft of a constitution (decisionmaking procedure)
> > up on the www at
> > <URL:http://www.chiark.greenend.org.uk/~ian/debian-organisation.html>
> >
> > Please comment on it - here on debian-devel, please, rather than by
> > private email.
>
> I have a few comments.
>
> In 6.3:
>
> 4.No detailed design work.
>
> Then Technical Committee does not engage in design of new
> proposals and policies. Such design work should be carried out
> by individuals privately or together and discussed in ordinary
> technical policy and design forums.
>
> The Technical Committee restricts itself to choosing from or
> adopting compromises between solutions and decisions which have
> been proposed and reasonably thoroughly discussed elsewhere.
>
> I assume this is supposed to stop the committee doing designs as
> "the committee". If individuals *that are in the committee* are
> still free to work on design/policy outside of their committee role,
> perhaps this should be stated a little bit more explicitly.
Indeed.
> 5.Technical Committee makes decisions only as last resort.
>
> The Technical Committee does not make a technical decision until
> efforts to resolve it via consensus have been tried and failed.
>
> This conflicts with 6.1 which states that the tech. committee can
> make decisions when asked to, and can overrule developers, etc.
>
> Perhaps it should be made clear when the tech committee is the natural
> decision maker, and when they need to be the decision maker of
> last resort. I'm not clear on when they are expected to make decisions.
> Also, some definition of "tried and failed" seems needed, although
> it need not be formal.
I think I've clarified this somewhat now.
> Also, I'm not clear on the role of Delegates -- what is with them
> kicking people out? Why can't the PM do that? Do the developers
> get a say in that? I'm not saying it's wrong, but some rationale
> might be good for this.
The developers don't get a say except that of course they can override
the delegate's decision - s.4.1(3).
> Otherwise it seems like it's coming along nicely. Would you
> expect a degree of automation/process to vote calling/vote
> counting? Should that be in this document or elsewhere?
That's out of the scope of the document.
Ben Pfaff writes ("Re: Initial draft proposed consitutution (v0.1)"):
...
> At one point you say the delegates may `vet' developers. Is this a
> Britishism? It's not in *my* vocabulary, at least. Perhaps a
> misspelling of `veto'?
`vet' means to check up on and then to approve or not. I've changed
the wording.
> What is a `casting vote'?
s.A.5(6).
> Why can't the Project Leader withdraw a delegation? There should be
> some procedure for withdrawal, at least, even if he can't personally
> withdraw the delegation.
They can't withdraw a delegation of a particular decision once the
decision has been made (to stop abuse of authority). If clarified
this somewhat.
Nils Lohner writes ("Re: Initial draft proposed consitutution (v0.1) "):
...
> 1. The purpose of the constitution should be stated somewhere. Section 0
> maybe?
>
> This ensures that the document itself evolves around its purpose and does
> not grow randomly. It will also make the document more readable for a first
> time reader because he will know what its purpose is.
>
> Something along the lines of:
> "This constitution intends to define the Debian organization, its
> structure, goals, and its operation."
I thought I'd already done that. I've made it clearer.
> 2. Need a more logical order of the document.
>
> Begin with the introduction, then list ths SPI ties, then list the basic
> goals. At this point the basics of who/what Debian is is defined. Next, go
> into more details of the goals and how they are to be accomplished.
That's not the purpose of the document.
> At this point, any first time reader knows what debian is, what its about,
> and how it plans to accomplish its goals.
>
> Then go into the organizational structure, procedures, and politics. Not
> everyone who reads this document will necessarily be interested in these
> topics, and the people who are will look for them.
This document is the definition of the organisational structure,
procedures and politics. The other stuff (DFSG et al) can go
elsewhere.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: