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