[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Procedure for submitting requests for clarification to the committee



>  Raul> Standards set up without any real experience are almost always wrong.
>  Raul> Manoj Srivastava <srivasta@debian.org> wrote:

Manoj Srivastava <srivasta@debian.org> wrote:
>  >> We are not talking about standards here, for gods sake. We are
>  >> not even talking Policy. We are twalking about setting up guidelines,
>  >> and something that can be adapted as we go along. Jumping in without
>  >> even tinking about scalable methods is unwise. 

>  Raul> Scalable?  If the technical committee needs to scale up that
>  Raul> means that Debian's technical standards are changing incredibly
>  Raul> rapidly.

Manoj Srivastava <srivasta@debian.org> wrote:
>         Rubbish. It may ,erely mean that some clowns have discovered a
>  way to second guess evbery other decision making porocess in the
>  project, and are swamping us with frivolous requests. How *do* you
>  propose to handle frivoulous request? pretend we don't exist? 

You mean like the occasional message which should have gone to
debian-user?  We have the option of politely telling them where
to go, or we have the option of ignoring them.  I'd suggest that
we deal with such cases on a personal level (only one person needs
to let them know how to do better), and not deal with such things
as a committee.

>  Raul> Even if this were an issue, it's very likely that the best way
>  Raul> to handle such a situation would involve proceeding at a sedate
>  Raul> pace.

>         I see. I guess this explains why official processes in the
>  project seem to be dead air (all teh noise I hear about the new
>  maintainer group, the ftp group, etc, is just people proceeding at
>  glacial pace. Sorry,, hiding my head in the sand is not really an
>  option I care to exercise.

Now you're confusing two completely different issues:  You asked what
the committee should do if we're swamped and you've suggested that
this is somehow relevant to other areas with different procedures
which already are swamped.

The rules laid out in the constitution for the committee seem designed
to allow us to deal with issues fairly rapidly.  Reading between the
lines, we get to decide on what issues are priority issues and what
issues are less important.  We're supposed to use the standard
resolution protocol, but quorum is 2, voting period is 1 week (max),
and there's no minimum discussion period.

Also, we're explicitly not supposed to do detailed design work --
that means that if such work needs to be done, it must already be
done by the submitter.  That makes it pretty easy for us, don't you
think?

If someone submits something to us that's not basically done, we
need to reject it.  It would be a good idea to be clear about why
(especially on ideas that have some merit), but we really don't 
have any obligation to do anything in such cases.

>  Raul> Also, remember that the committee isn't a design body, it's an
>  Raul> approval body -- someone needs to submit a completed proposal
>  Raul> to the committee.  The committee has some latitude on what they
>  Raul> do with a proposal (and, I suspect that the most useful work
>  Raul> the comittee will do involves sending proposals back to the
>  Raul> submitter with recommendations and/or criticisms), but it's not
>  Raul> like the debian-policy list where people are hashing out the
>  Raul> details of policy.
> 
>         I assume you are familair with the powers imparted to the ctte
>  in the constitution. 

I like to think so.

>  Raul> Except that (a) there are no venture capitalists involved (a good
>  Raul> thing too), (b) we already have an extensive set of guidelines laid
>  Raul> out in the constitution.
> 
>         I say no guidelines for proposing anything to the ctte --
>  including what you said above about comlete proposals. Where are you
>  gettihng that from? 


Reply to: