Re: Manifesto for the Debian Project leadership
I'm quite happy to have an email debate.
I do hope this DFSG example doesn't get out of hand. This is just one
case where I think a more formal procedure would have helped. I'll
continue to discuss it as an example ...
Regarding the DFSG issue Manoj wrote:
> *Sigh*. Can't we ever decide on *anything*? I think we talked
> about this long enough the last time around. No matter what the final
> document would be, there would be people who disagree with parts. I
> don't think we can ever achieve a true consenesus (where nobody feels
> a compromise was required) with the size we have now. If you try to
> please everyone, you end up with an unwieldy and fuzzy document.
I'm not trying to please everyone; nor am I trying to create a
situation where issues cannot be closed.
I want to create a situation where people feel that their views have
been considered, and if they were rejected they were rejected
(in the case of political decisions) democratically by the other
developers rather than autocratically by the leader.
At the moment if I were to tell you what the issue was that I wanted
changed in the DFSG you would have no basis for telling me to shut up
because the issue had already been decided - because (IMO) it wasn't
considered properly, and the project leader essentially made an
executive decision on what to put in the final version.
I.e., we don't _know_ what the opinion of the developers on this
change would have been because the change was never put to a vote.
What I'm planning to do is make an arrangement whereby a sufficient
number of developers can force a vote on an amendment. The votes on
all the amendments would be done together when they'd all be
collected, at the same time as the vote on the resolution itself, so
you'd still just cast one ballot at the end, but it would have more
than just `yes/no' on it.
The vote that was held on the final version of the DFSG is a bit like
the US president signing a bill into law - there's not a great deal of
power there to control individual bad parts of laws they generally
approve of.
...
> We need something solid to anchor our distribution on, and I
> would not like to see this issue being reopened either because one
> persons changes did not make it into the document or someone feel the
> procedure culd have been improved.
This is not about my changes not going into this document. It's about
the document (amongst others) not having been properly settled on,
because there was no opportunity for anyone but Bruce to have any real
_control_ over its content (as opposed to influence exerted by
persuading Bruce).
...
> Sorry. We are not sheep that ratified a manifesto just because
> the leadership said it was so (Is that truly your view of the
> developers? that we are so easily swayed?).
We ratified the DFSG because the alternative - voting it down - was
worse. That's not being sheep, but it's not making a real choice
either. I'm not saying we should have voted it down; I'm saying that
given that voting it down would have been such a bad thing its passage
was pretty much inevitable, and Bruce had complete control over what
went into it.
> > I therefore propose to put the DFSG through the procedure I shall
> > set up, after that procedure itself has been approved by the
> > membership.
>
> I think you should first find out if the membership want you
> to do this in the first place.
Is this some kind of parody ? It's hard to tell.
If I am voted into office I shall put the DFSG through the procedure,
once the procedure itself has been ratified for the making of
such decisions. If the developers don't want to do this they can either
not vote me into office or simply rubber stamp the DFSG when it comes
round.
Ian.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: