openstack team mailing list archive

[Christopher B Ferris <chrisfer@xxxxxxxxxx>]

Speaking of the User Committee as proposed in the draft governance docs, I
can
certainly see value in having the committee chair chosen by the board.
However, as
currently proposed, there is a convoluted process for appointing the
representatives
of the committee. Frankly, if you want to give a voice to the end users,
the user
committee should be open to all who use the technology and wish to
contribute their
voice.

My $0.02 USD

Chris

Sent from my iPad

On Jul 16, 2012, at 12:10 PM, "Thierry Carrez" <thierry@xxxxxxxxxxxxx>
wrote:

> David Kranz wrote:
> > Going forward, and this may be controversial, I think these kinds of
> > issues would be best addressed by following these measures:
> >
> > 1. Require each blueprint that involves an API change or significant
> > operational incompatibility to include a significant justification of
> >     why it is necessary, what the impact would be, and a plan for
> > deprecation/migration. This justification should assume that the remedy
> >     will have to be applied to a large, running OpenStack system in its
> > many possible variations, without having to shut down the system
> >    for some unknown amount of time.
>
> That would be useful. Strengthening a bit the feature proposal process
> definitely can't hurt.
>
> > 2. Require such blueprints to be approved by a technical committee that
> > includes a significant representation of users/operators. The tradeoffs
can
> > be difficult and need to be discussed.
>
> The Foundation bylaws propose that a "User committee" be set up. I hope
> that the User committee can be quickly set up, gets respected people on
> it and manages to be representative of all the users/operators of
> OpenStack. If done properly, such a committee can get very influential
> and its public "recommendations" cannot be easily ignored by the
> developer side (the "technical committee").
>
> > 3. The technical committee should declare that the bar for incompatible
> > changes is high, and getting higher.
> >
> > Some might argue that this is too much of a burden and takes authority
> > away from PTLs, but I think the statement of stability to the
> > community (and others) would more than compensate for that.
>
> Using the "user committee" setup, you don't really need to take
> authority away from the PTL. You increase the influence of the "users"
> on technical decisions. You just provide a clear and official mechanism
> to represent the interests of "the users" as a whole. Once you have
> that, if the PTL or technical committee decides to ignore it, it's a
> rather strong decision that better has to be well justified. Its better
> than having some arbitrary percentage of "users" in a single committee
> and then have most decisions won by the most largely represented party.
>
> If the user committee is an active and respected group, it provides nice
> checks and balances against developers living in developer bubbles. Most
> issues we have right now with deployer-friendliness are linked to the
> fact that "the users" don't have a clear or official voice.
>
> The trick is, of course, to manage to set up such a committee in a way
> that represents all the users and deployers. It will be all the more
> influential if it is seen as representing all the users, rather than
> just a loosely-tied pre-determined subset of large users.
>
> --
> Thierry Carrez (ttx)
> Release Manager, OpenStack
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>