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

Re: Draft proposal for resolution process changes



>>>>> "Russ" == Russ Allbery <rra@debian.org> writes:
    Russ> Procedurally, I don't believe we should automatically start a
    Russ> GR because I think there's benefit to going through the normal
    Russ> GR process.  For example, who is the proposer of the GR for
    Russ> the purposes of making subsequent ballot option changes?  This
    Russ> special type of GR would add a bunch of complexity that we'd
    Russ> have to spell out, and I don't think it's worth it.
I agree with you that a GR should not automatically be triggered.  The
TC may want to word the GR differently, and it may be obvious that some
of the options on the TC ballot do not need to be proposed in a general
GR.


However, I think we already have the complexity you are worried about:
4.2.1 permits both the DPL and the TC tto sponsor a resolution without
additional developers.

I think that it's not too hard to make this useful.
Under section 6.3,
say something like
"When the Technical Committee proposes a general resolution to the
project, it may delegate the authority to accept amendments and withdraw
ballot options to one of its members."


If the TC didn't choose to delegate such authority, it would presumably
have to vote on amendments.

In many cases, I think individual TC members will find it easier to
simply propose a resolution themselves.  However, I think there are
cases where having the TC bring an issue to the project could lend
legitimacy to the decision making process and I would prefer not to
remove this power from the TC as part of this process.

--Sam


Reply to: