<div dir="ltr">Hi Narayan -<br>Great discussion! Thanks for circling back to individuals and the list. I agree that we do not have a good community support mechanism -- and the docs site can only go so far to help.<br><div class="gmail_extra">

<br><br><div class="gmail_quote">On Wed, Jan 9, 2013 at 11:03 PM, Narayan Desai <span dir="ltr"><<a href="mailto:narayan.desai@gmail.com" target="_blank">narayan.desai@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hi Anne. Thanks for the detailed response/questions. They have<br>
provided a lot of food for thought.<br>
<br>
Answers/comments are inline.<br>
<div class="im"><br>
On Wed, Jan 2, 2013 at 12:55 PM, Anne Gentle <<a href="mailto:anne@openstack.org">anne@openstack.org</a>> wrote:<br>
><br>
> I'm using a definition of users as described in the User Committee Points<br>
> for Review document at [1]. To distill it really far, it's an end-user,<br>
> operator, ecosystem partner, or distribution provider or appliance vender.<br>
> This is still a lot of roles -- maybe a more narrow definition would help?<br>
> What is your definition?<br>
<br>
</div>I think that the salient distinction is between the people that<br>
produce openstack and the people that consume it. I think that this<br>
ends up being a complicated discussion because people consume<br>
openstack in such a large variety of different ways.<br>
<div class="im"><br>
>><br>
>> This mission of the user committee should (IMO) flow from a few basic<br>
>> questions:<br>
>>  - How do users engage in the community?<br>
><br>
> Currently I believe they:<br>
>  - Attend the Summit.<br>
>  - Test the releases, triage incoming and log new Bugs<br>
>  - Review documentation.<br>
>  - Contribute to QA, Infrastructure, Docs through existing processes.<br>
>  - Package the projects and let the community know how to get them.<br>
<br>
</div>I think that this is the largest difference of opinion that I have<br>
with you. This model completely discounts the class of users that<br>
primarily *use* the software. I think that it is unrealistic to expect<br>
that most users will engage as deeply with the project as you have<br>
suggested here. There will absolutely be users who decide to<br>
contribute more, build packages, file tickets, contribute docs, etc,<br>
but I can't imagine this even hitting 50% of the user base.<br>
<br>
For example, consider the linux kernel user base. On the spectrum from<br>
consistent contribution to casual or embedded/invisible use, there are<br>
far more people at the latter end of the spectrum.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Ok, this was eye-opening to me for some reason. As a writer/blogger, I'm a huge fan of WordPress for example. But I never took the extra steps to update their wiki or support knowledgebase as a consumer of WordPress. Not that I didn't know how, but that I didn't choose to turn my consumer status into contributor status. There could be plenty of people like this for OpenStack -- but what I hadn't realized is that "we're there" as a project, with people on the consumer-only end of the spectrum.<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
>>  - How do we incentivize these participants to help fill the current<br>
>> gaps that exist in the community?<br>
><br>
> To me, there's a perception of gap that I'd like you to further describe.<br>
<br>
</div>I think that the gaps in the community are centered on issues that<br>
primarily concern users. The two largest are user support, and open<br>
discussion of system architecture. I'm not suggesting that these<br>
discussions aren't happening, but I think that they aren't happening<br>
enough, and the current system for contributions doesn't seem to<br>
incentivize users to improve them sufficiently.<br>
<br>
I wrote a separate email about this explicitly; it is pretty lengthy,<br>
but I think that it covers my observations about these issues at a<br>
good level of detail.<br>
<div class="im"><br>
> For example, we have established mechanisms for doc contributions, QA, and<br>
> infrastructure contributions. Possibly you don't like those for certain<br>
> reasons we could address.<br>
<br>
</div>I think that those mechanisms are fine. I think that they are aiming<br>
for the visible part of the user iceberg: deeply engaged users. My<br>
hope is that there is a large, less engaged user community that we<br>
could engage at a lower activity level than you are describing.<br></blockquote><div><br></div><div>Thierry described the steps going towards an easy-to-use walk-up support system in a follow up email. I'm all for that.<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> What additional gaps do you perceive? The User Committee is also tasked with<br>
> "consolidate user needs and present them to the technical committee and<br>
> management board to with proposed action plans" [1]<br>
><br>
> Possibly the action plans they come up with will have mechanisms you'd<br>
> prefer over the existing, not sure.<br>
<br>
</div>That is why I started this thread. I hope that the user committee can<br>
help to build processes that will help with the problems that I'm<br>
talking about.<br>
<div class="im"><br>
>>  - How do we best integrate the perspectives of users into the design<br>
>> process of openstack code?<br>
><br>
> How are the established blueprint processes not filling this need? I realize<br>
> you're looking for improvement but I need more concrete examples if you can<br>
> share.<br>
<br>
</div>Sure. The blueprint mechanism is great for developers, but I think<br>
that it is problematic for pure users for a few reasons. One issue is<br>
that users usually run released code. For example, our system is still<br>
running essex. I've heard rumors that HP is diablo-based, etc. This<br>
causes an impedance mismatch between users and blueprints, where the<br>
systems being redesigned may be quite different from deployed systems<br>
at the user. Also, blueprints without dedicated development muscle<br>
seem to wither on the vine, so users without dev resources don't have<br>
any leverage with them, unless they can piggyback on an existing<br>
blueprint.<br>
<br>
For the record, I'm not sure that the blueprint process should be<br>
changed; it seems to work pretty well to manage the development<br>
process. One way that the user committee could help here is to try to<br>
help impedance match between users and devs here.<br>
<div class="im"><br>
>><br>
>>  - How can the user committee facilitate a more productive engagement<br>
>> between these two parts of the openstack community?<br>
>><br>
> This sounds like a great first draft for a mission - but still uses phrasing<br>
> like "two parts" -- can you write a draft mission statement that doesn't<br>
> indicate this perception?<br>
<br>
</div>Particularly after writing the other email, I think that I've changed<br>
my mind on this. I think that it may be important to highlight the<br>
divisions between users and developers/contributors, and that bridging<br>
the gap is the user committee's raison d'etre.<br>
<div class="im"><br>
> Also, is the "mandate" different from a mission? Is a mission just shorter<br>
> wording than a bullet list or will the mandate fill the need for a mission?<br>
<br>
</div>This may be an issue of vocabulary on my part, but I think of the<br>
mission as being the overarching goals, where the mandate seems like a<br>
series of procedural/tactical things. This may be a word funny on my<br>
part though.<br>
<div class="im"><br>
> Funny story - I didn't even know the phrase "patches welcome" was considered<br>
> off-putting to some until about six months ago. So if I've used that phrase,<br>
> I apologize for having such a tone. Not intended to be anti-welcoming! :)<br>
<br>
</div>Of all of the folks that participate in the openstack community, I<br>
don't think that anyone would mistake you for unwelcoming of new<br>
users.<br>
<br>
Off-putting is probably a good word for it. In the context of new<br>
users, it is not unlike using the word love on a first date. They<br>
aren't even using the software yet, and you're asking them to<br>
contribute to it? I think that it signals a critical difference in<br>
mindset between people who are showing up to contribute from day one,<br>
and people who want to try things out.<br>
<br>
I think that a lot of these people could potentially be quite valuable<br>
to the user community once they are over the hump, There are precious<br>
treasures in their heads, and it is better for us if we mine that in a<br>
non-zombie sort of way ;)<br>
<div class="im"><br></div></blockquote><div><br></div><div>You're too kind, but yes, I sense that the hump is great currently and finding more ways to ease up the contribution ladder will help immensely with our onboarding and engagement.<br>

<br></div><div>(Guh, I sound like some sort of social media consultant with those last two words.) :)<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">
> I think a great move recently was to call the "OpenStack Conference and<br>
> Design Summit" the "OpenStack Summit" -- we need to keep these references<br>
> simpler. To me, this is the right direction for blurring the lines. I don't<br>
> think having a structured user committee causes a split, but I want to hear<br>
> more about why you get this sense from where you sit. If we didn't have a<br>
> user committee, would there be another way?<br>
<br>
</div>I think that a user committee is critical. I can't help but to think<br>
that there need to be more dedicated resources put into this user<br>
impedance matching problem. Your work on documentation has already<br>
been a piece of that, but I almost feel like there need to be more<br>
dedicated resources from member companies in community development to<br>
grow the user community into a largely self-supporting/self-sufficient<br>
one.<br>
<br>
The change in the summit naming and organization was definitely a step<br>
in the right direction. I think that getting everyone into the same<br>
place is a clear win. I think that sessions like Mark suggested would<br>
be a good addition. It might also be useful to have the user committee<br>
do some broad surveys for the projects in advance of the summit as<br>
well, in order to drive high level design discussions.<br>
<div class="im"><br>
> I think a mission is great - and probably needs to start with "who are the<br>
> users?" as Dave Neary also asked.  The document referenced by the committee<br>
> does have definitions, and a mandate, so maybe a distillation of the mandate<br>
> is going to be helpful to you.<br>
<br>
</div>I've been trying to reason out my gut reaction to the document as is.<br>
I feel like it is overly focused on the procedural aspects and<br>
defining an ontology for users and use cases. It talks about<br>
facilitation of communication, but not really fostering the community<br>
in a direct fashion. The more I have thought about this (and boy have<br>
I thought about it as I have written these two treatises), the more<br>
that I am most concerned with the user committee leading community<br>
development for users. There are definitely good bits in there, but I<br>
feel like they are a little bit hidden in the logistics.<br>
<br></blockquote><div><br></div><div>Reasonable reaction -- sometimes implementation jumps design, perhaps it's a similar gut reaction you have here.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Here is a stab at a strawman mission: (using my definition of users)<br>
The user committee has four main goals:<br>
 - fostering the development of the user community (including support<br>
and system design best practices)<br>
 - facilitating communication with the openstack contributor community<br>
(TC/devs/etc)<br>
 - collection of information about the openstack deployment base, as<br>
well as broad user survey conducted (per release/per year/?)<br>
 - User advocacy (both individual and on the basis of the survey,<br>
community discussions)<br>
<br></blockquote><div><br></div><div>Thanks for writing this up. I especially like the first, and will certainly help how I can with the goal. Thanks for writing it all up!<br>Anne<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


These first two points could go a long way towards addressing some of<br>
the things that I've been discussing above and in the other mail. I<br>
also think that collecting information about where the community is<br>
and where it is going is a critical function.<br>
<br>
I think that this is probably enough comment for one evening, but I<br>
look forward to your (and others') opinions on all of this.<br>
 -nld<br>
</blockquote></div><br></div></div>