Open Stack

Hi Narayan -
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.


On Wed, Jan 9, 2013 at 11:03 PM, Narayan Desai <narayan.desai at gmail.com>wrote:

> Hi Anne. Thanks for the detailed response/questions. They have
> provided a lot of food for thought.
>
> Answers/comments are inline.
>
> On Wed, Jan 2, 2013 at 12:55 PM, Anne Gentle <anne at openstack.org> wrote:
> >
> > I'm using a definition of users as described in the User Committee Points
> > for Review document at [1]. To distill it really far, it's an end-user,
> > operator, ecosystem partner, or distribution provider or appliance
> vender.
> > This is still a lot of roles -- maybe a more narrow definition would
> help?
> > What is your definition?
>
> I think that the salient distinction is between the people that
> produce openstack and the people that consume it. I think that this
> ends up being a complicated discussion because people consume
> openstack in such a large variety of different ways.
>
> >>
> >> This mission of the user committee should (IMO) flow from a few basic
> >> questions:
> >>  - How do users engage in the community?
> >
> > Currently I believe they:
> >  - Attend the Summit.
> >  - Test the releases, triage incoming and log new Bugs
> >  - Review documentation.
> >  - Contribute to QA, Infrastructure, Docs through existing processes.
> >  - Package the projects and let the community know how to get them.
>
> I think that this is the largest difference of opinion that I have
> with you. This model completely discounts the class of users that
> primarily *use* the software. I think that it is unrealistic to expect
> that most users will engage as deeply with the project as you have
> suggested here. There will absolutely be users who decide to
> contribute more, build packages, file tickets, contribute docs, etc,
> but I can't imagine this even hitting 50% of the user base.
>
> For example, consider the linux kernel user base. On the spectrum from
> consistent contribution to casual or embedded/invisible use, there are
> far more people at the latter end of the spectrum.
>
>
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.


> >>  - How do we incentivize these participants to help fill the current
> >> gaps that exist in the community?
> >
> > To me, there's a perception of gap that I'd like you to further describe.
>
> I think that the gaps in the community are centered on issues that
> primarily concern users. The two largest are user support, and open
> discussion of system architecture. I'm not suggesting that these
> discussions aren't happening, but I think that they aren't happening
> enough, and the current system for contributions doesn't seem to
> incentivize users to improve them sufficiently.
>
> I wrote a separate email about this explicitly; it is pretty lengthy,
> but I think that it covers my observations about these issues at a
> good level of detail.
>
> > For example, we have established mechanisms for doc contributions, QA,
> and
> > infrastructure contributions. Possibly you don't like those for certain
> > reasons we could address.
>
> I think that those mechanisms are fine. I think that they are aiming
> for the visible part of the user iceberg: deeply engaged users. My
> hope is that there is a large, less engaged user community that we
> could engage at a lower activity level than you are describing.
>

Thierry described the steps going towards an easy-to-use walk-up support
system in a follow up email. I'm all for that.


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

(Guh, I sound like some sort of social media consultant with those last two
words.) :)



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


> Here is a stab at a strawman mission: (using my definition of users)
> The user committee has four main goals:
>  - fostering the development of the user community (including support
> and system design best practices)
>  - facilitating communication with the openstack contributor community
> (TC/devs/etc)
>  - collection of information about the openstack deployment base, as
> well as broad user survey conducted (per release/per year/?)
>  - User advocacy (both individual and on the basis of the survey,
> community discussions)
>
>
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!
Anne


> These first two points could go a long way towards addressing some of
> the things that I've been discussing above and in the other mail. I
> also think that collecting information about where the community is
> and where it is going is a critical function.
>
> I think that this is probably enough comment for one evening, but I
> look forward to your (and others') opinions on all of this.
>  -nld
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/foundation/attachments/20130115/343735a0/attachment-0001.html>