Open Stack

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.

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

> 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 ;)

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

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)

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