Mailing List Archive

Narayan Desai wrote:
> To the first point, there is often a tone of "patches welcome" in the
> community, that is somewhat unwelcoming to users that can't or won't
> develop code. This suggests that engagement solely on the development
> terms is probably not a sustainable solution for the heterogenous
> community that is developing around openstack. I think that it is
> important to give these folks (ones that build systems, not so much
> software) a role that they can identify with as a contributor to the
> project.

One interesting point to note is that we use revision control and source
repositories for more than just "code". Documentation (RST, DocBook5)
and administration of our infrastructure systems (Puppet, *) are also
using revision-controlled repositories and do not require you to be a
Python developer to contribute.

Users are usually the best-placed to notice an error or a gap in our
docs, and (a lot of them being sysadmins by trade) they are also a
knowledgeable group to help with our server infrastructure. So "Patches
welcome" is not about saying "contribute code or you're a loser". It's
about saying "this is a project that will live or die based on
everyone's contributions" and that also applies to doc and
infrastructure contributions.

--
Thierry Carrez (ttx)
Release Manager, OpenStack

_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

Hi Narayan,

Interesting read - thank you for putting this together! and a happy new
year to all the OpenStack community - may 2013 be a healthy, happy and
successful year for everyone involved.

On 12/28/2012 06:11 PM, Narayan Desai wrote:
> I have a few comments; these aren't so much comments about the
> document that you're circulating; rather, they speak specifically to
> the mission of the user committee, which is only discussed briefly at
> the end.
>
> This mission of the user committee should (IMO) flow from a few basic questions:
> - How do users engage in the community?
> - How do we incentivize these participants to help fill the current
> gaps that exist in the community?
> - How do we best integrate the perspectives of users into the design
> process of openstack code?
> - How can the user committee facilitate a more productive engagement
> between these two parts of the openstack community?

I would add one question, to be answered before all the others - who are
OpenStack's users? What is their profile? Are we talking about
CIO/technical director of companies deploying OpenStack, DevOps/sysadmin
involved in the deployment and operation, partners packaging and
integrating OpenStack and delivering it to customers, or some other user
profile?

And in addition to your question on how users engage with the community,
how do they *want* to engage with the community? Is it more to share
knowledge with other OpenStack users, to give feedback on the
project/request feature additions, or to help out?

Cheers,
Dave.

--
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13

_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

On Fri, Dec 28, 2012 at 11:11 AM, Narayan Desai <narayan.desai@gmail.com>wrote:

> I originally sent this mail to Tim Bell, on the subject of a document
> that he (and the other members of the user committee) are preparing.
>
> Tim suggested widening the discussion to this mailing list, so I've
> forwarded the message here. I'm particularly interested in others'
> opinions about the mission of the user committee, and aspects of the
> openstack community culture that this mission reflects.
> -nld
>
> =====================
>
> Hi Tim.
>
> Thanks for the update on the user committee.
>
> When Lauren (Sell) originally mentioned the user committee to me, I
> was most excited about the addition of user advocacy into the
> openstack community. From early on in the project (at least back to
> Bexar when I started paying attention), openstack has primarily been a
> developer-focused community. While this culture has been excellent for
> encouraging contribution of code, I think that this is a tendency
> that needs to be moderated in order for openstack to grow to its full
> potential.
>
> I have a few comments; these aren't so much comments about the
> document that you're circulating; rather, they speak specifically to
> the mission of the user committee, which is only discussed briefly at
> the end.
>
>
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?


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

After the user committee gets going, there will be another engagement layer
through them I believe.


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

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.

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.



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


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

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?



> To the first point, there is often a tone of "patches welcome" in the
> community, that is somewhat unwelcoming to users that can't or won't
> develop code. This suggests that engagement solely on the development
> terms is probably not a sustainable solution for the heterogenous
> community that is developing around openstack. I think that it is
> important to give these folks (ones that build systems, not so much
> software) a role that they can identify with as a contributor to the
> project.
>
>
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! :)


> I think that there are a large range of gaps between the coding and
> deployments today. Openstack supports a wide enough range of functions
> (and IMO it is necessary, not incidental complexity) that it is
> difficult to boil down to simple configurations. I think this poses a
> serious difficulty for both documentation and testing. These issues
> have been discussed at length, but make me wonder if a different
> structure would address these gaps as well as the social split as
> well.
>
> As I've written this, I'm realizing that the one thing that doesn't
> sit well with me about the current structure you're proposing for the
> user committee seems to institutionalize the current split between
> developers and users, where I think that the committee should be
> trying to figure out ways to blur the divisions between the groups.
>
>
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'd suggest adding in an explicit mission for the group at the top of
> the document, in addition to the mandate. I think that might set the
> tone for the rest of the document in a productive way. Considering my
> lack of standing on the committee, I think that it might be
> presumptive for me to suggest its mission, but I think that the four
> questions above capture many of the things that I think are important.
>
>
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'm happy to help in any way you'd like. let me know if you'd like
> additional comments, or participation in the documents in some
> fashion.
>

I definitely think your comments on the document they've started would be
useful. Thanks for the input - really needed as we shape these working
groups.

Anne

1.
https://docs.google.com/document/d/1yD8TfqUik2dt5xo_jMVHMl7tw9oIJnEndLK8YqEToyo/edit


>
> Happy holidays.
> -nld
>
> _______________________________________________
> Foundation mailing list
> Foundation@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
>

One idea I discussed with Thierry was to kick off each "topic" within the Design Summit every day with a roundtable to share user pain points or other areas that users might see as priorities going forward.

IMHO this would be a positive step, and is something we could implement in April.



On Friday, December 28, 2012 11:11am, "Narayan Desai" <narayan.desai@gmail.com> said:

> I originally sent this mail to Tim Bell, on the subject of a document
> that he (and the other members of the user committee) are preparing.
>
> Tim suggested widening the discussion to this mailing list, so I've
> forwarded the message here. I'm particularly interested in others'
> opinions about the mission of the user committee, and aspects of the
> openstack community culture that this mission reflects.
> -nld
>
> =====================
>
> Hi Tim.
>
> Thanks for the update on the user committee.
>
> When Lauren (Sell) originally mentioned the user committee to me, I
> was most excited about the addition of user advocacy into the
> openstack community. From early on in the project (at least back to
> Bexar when I started paying attention), openstack has primarily been a
> developer-focused community. While this culture has been excellent for
> encouraging contribution of code, I think that this is a tendency
> that needs to be moderated in order for openstack to grow to its full
> potential.
>
> I have a few comments; these aren't so much comments about the
> document that you're circulating; rather, they speak specifically to
> the mission of the user committee, which is only discussed briefly at
> the end.
>
> This mission of the user committee should (IMO) flow from a few basic questions:
> - How do users engage in the community?
> - How do we incentivize these participants to help fill the current
> gaps that exist in the community?
> - How do we best integrate the perspectives of users into the design
> process of openstack code?
> - How can the user committee facilitate a more productive engagement
> between these two parts of the openstack community?
>
> To the first point, there is often a tone of "patches welcome" in the
> community, that is somewhat unwelcoming to users that can't or won't
> develop code. This suggests that engagement solely on the development
> terms is probably not a sustainable solution for the heterogenous
> community that is developing around openstack. I think that it is
> important to give these folks (ones that build systems, not so much
> software) a role that they can identify with as a contributor to the
> project.
>
> I think that there are a large range of gaps between the coding and
> deployments today. Openstack supports a wide enough range of functions
> (and IMO it is necessary, not incidental complexity) that it is
> difficult to boil down to simple configurations. I think this poses a
> serious difficulty for both documentation and testing. These issues
> have been discussed at length, but make me wonder if a different
> structure would address these gaps as well as the social split as
> well.
>
> As I've written this, I'm realizing that the one thing that doesn't
> sit well with me about the current structure you're proposing for the
> user committee seems to institutionalize the current split between
> developers and users, where I think that the committee should be
> trying to figure out ways to blur the divisions between the groups.
>
> I'd suggest adding in an explicit mission for the group at the top of
> the document, in addition to the mandate. I think that might set the
> tone for the rest of the document in a productive way. Considering my
> lack of standing on the committee, I think that it might be
> presumptive for me to suggest its mission, but I think that the four
> questions above capture many of the things that I think are important.
>
> I'm happy to help in any way you'd like. let me know if you'd like
> additional comments, or participation in the documents in some
> fashion.
>
> Happy holidays.
> -nld
>
> _______________________________________________
> Foundation mailing list
> Foundation@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
>



_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

On Thu, Jan 3, 2013 at 9:26 AM, Mark Collier <mark@openstack.org> wrote:

> One idea I discussed with Thierry was to kick off each "topic" within the
> Design Summit every day with a roundtable to share user pain points or
> other areas that users might see as priorities going forward.
>
> IMHO this would be a positive step, and is something we could implement in
> April.
>

This would be great. I remember the ops pain points session from a couple
summits back. The entire room was packed and the 30 minutes scheduled
wasn't even close to enough time. I have a feeling that this will be a
popular change.

- Ryan

On 01/03/2013 07:32 PM, Ryan Lane wrote:
> This would be great. I remember the ops pain points session from a
> couple summits back. The entire room was packed and the 30 minutes
> scheduled wasn't even close to enough time. I have a feeling that this
> will be a popular change.

I agree, this will be popular and it's a great thing to do. We will need
everybody's help to make sure that the roundtable is only *one* of the
many ways where users will be able to express their views and contribute
to a successful Design Summit. The risk I would like to mitigate is that
users will limit their participation to the roundtable and skip/avoid
joining the rest of the Design sessions.

/stef

_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

Sorry for the slow response.

And borrowing the worlds of Blaise Pascal, I apologize for the length
of this letter; I had no time to make it shorter. ;)

One of the values of being offline for a bit is to get to read larger
chunks of the conversation as opposed to incrementally as they come
in. This mail contains comments in response to statements made by
Thierry, Dave, and Anne. This has actually been good in that it has
given me time to figure out why my perception of the situation is
different from the responses from folks here, and caused me to
reconsider my opinions in some ways.

First, let me say what I mean by users. When I talk about users, I
mean people who primarily consume the software and use it. Some of
these people will contribute back, in terms of bug reports, or perhaps
even bug fixes, but their primary scope of work is deployment and
operation of openstack.

Thierry, you're absolutely right; these folks are in the right place
to be able to tell us where documentation is wrong or incomplete,
where openstack breaks in weird (or regular) configurations, etc. This
information is enormously valuable to openstack as a project. I think
that an important question here is how far into the contributors
column these folks will be able to step, in terms of time investment,
effort, etc. This is an impossible question to answer with complete
certainty, and there will be all sorts of caveats having to do with
corporate culture, and a myriad of other factors. Be that as it may,
as a community, it is a reasonable question to ask what the
cost/benefit looks like for leaving that information on the table. The
take home message here is that the incentives aren't aligned between
people who are deeply involved and people who are casually involved.
People who are casually involved have another job to do. Openstack is
a potentially prominent part of that other job, but job #1 is X (site
reliability is a good example, but there are a bunch of others as
well).

Dave, I think that my formulation of the user category is somewhat
orthogonal to the categories that you're talking about; conceptually
it is the user/dev split. Generally, at least in open source projects,
I think of devs as being the people that produce the software, etc.
While there are some people in the user category that contribute to
the project in terms of documentation, infrastructure, etc, bug
reports and help to other users are as far as most people in the user
category go.

One other critical detail; users tend to use the software that has
been released, not the software that is being developed. I think that
this is borne out by the recent spate of comments of users planning
for essex to folsom upgrades on the mailing list. All of the
contribution processes seem tied to release+1, while the focus of many
users is release at best, if not release-1, or release-X.

As a related comment, Thierry, I think that your goal of most
end-users contributing to openstack as a general matter of course is
probably unrealistic. Even with good end user engagement, I'd be
surprised of there wasn't some kind of exponential ratio trend
separating core contributors, from occasional contributors, from rare
contributors, from relatively passive (mainly consumption-oriented)
users in open source projects as a whole. I would argue that Openstack
has the best infrastructure I've seen for contributions when people
are engaged. I think that the mechanisms for interacting with users
(casually involved people in terms of development) is ad-hoc at best.

When thinking about interactions with users (under my definition),
there are a bunch that are worth considering. New users evaluate
openstack, usually though some sort of POC. Once users have decided to
deploy openstack in some form, they need to figure out how best to
deploy it for a production deployment. Once it is deployed, people run
into bugs, performance problems, and the like.

All of these interactions hinge on user support. And user support is a
tricky issue. It is time consuming and expensive, particularly when
the user base is growing so fast, and international.

I don't mean in any way to diminish the contribution or value of the
documentation. The doc has made tremendous strides over the last two
years, and Anne and the rest of the doc contributors deserve credit
for it. At the same time, it seems that there is still a lot of demand
for interactive support, either via email or IRC. I think that this is
unavoidable; because openstack operates across a series of complex
broad areas (virtualization, storage, networking, etc), documenting
openstack in a definitive, comprehensive way is more difficult than
other projects. I personally believe that the need for interactive
support is linked to this fundamental complexity in cloud system
software stacks.

IMO, the only way to address this issue in the long term is to
activate and engage the user community in order to build a relatively
self-sustaining ecosystem. So far, I feel like the openstack community
hasn't managed to catalyze this activity sufficiently. We have several
venues, each of which end up lying fallow much of the time. (I'm
thinking specifically of openstack-operators, but questions are often
left unanswered on IRC as well.)

As a related rhetorical question, I'm left with the feeling that Vish
still spends a lot of time answering user questions. When we first
deployed Bexar, there were a few tricky problems that we would not
have been able to get past without his assistance. At the same time,
as the project has grown, his time/effort has become one of the most
substantial assets we have as a project, as developer contributions
are exploding. This seems to be the case in other openstack projects
as well, where the PTLs seem to be a substantial source of user
support. I'm not suggesting that PTLs should firewall themselves off
from users with questions, but it seems like there is a gap there that
we should be thinking about filling somehow.

I'm also not meaning to suggest that there aren't users that are
stepping into the fray in terms of user support. We all know the
familiar names from the mailing list and IRC of people that step up,
but there seems to be an insufficient number of these people for the
community as it stands, nevermind the community we hope to have
tomorrow.

This leaves the question, how do we effectively build out this part of
the ecosystem? I'm not sure that I have easy answers on this, but I
think that this is the key issue that the user committee needs to
tackle.
-nld

_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

Hi Mark.

I think this would be fantastic, particularly if it was done as a
plenary-style session, where there wasn't much conflicting with it
schedule wise, at least on a project by project basis.

This might even be a good opportunity to start soliciting reference
architectures for deployments of various types. These might make for
interesting sessions and might help to incubate the community around
system design discussions.
-nld

On Thu, Jan 3, 2013 at 11:26 AM, Mark Collier <mark@openstack.org> wrote:
> One idea I discussed with Thierry was to kick off each "topic" within the Design Summit every day with a roundtable to share user pain points or other areas that users might see as priorities going forward.
>
> IMHO this would be a positive step, and is something we could implement in April.
>
>
>
> On Friday, December 28, 2012 11:11am, "Narayan Desai" <narayan.desai@gmail.com> said:
>
>> I originally sent this mail to Tim Bell, on the subject of a document
>> that he (and the other members of the user committee) are preparing.
>>
>> Tim suggested widening the discussion to this mailing list, so I've
>> forwarded the message here. I'm particularly interested in others'
>> opinions about the mission of the user committee, and aspects of the
>> openstack community culture that this mission reflects.
>> -nld
>>
>> =====================
>>
>> Hi Tim.
>>
>> Thanks for the update on the user committee.
>>
>> When Lauren (Sell) originally mentioned the user committee to me, I
>> was most excited about the addition of user advocacy into the
>> openstack community. From early on in the project (at least back to
>> Bexar when I started paying attention), openstack has primarily been a
>> developer-focused community. While this culture has been excellent for
>> encouraging contribution of code, I think that this is a tendency
>> that needs to be moderated in order for openstack to grow to its full
>> potential.
>>
>> I have a few comments; these aren't so much comments about the
>> document that you're circulating; rather, they speak specifically to
>> the mission of the user committee, which is only discussed briefly at
>> the end.
>>
>> This mission of the user committee should (IMO) flow from a few basic questions:
>> - How do users engage in the community?
>> - How do we incentivize these participants to help fill the current
>> gaps that exist in the community?
>> - How do we best integrate the perspectives of users into the design
>> process of openstack code?
>> - How can the user committee facilitate a more productive engagement
>> between these two parts of the openstack community?
>>
>> To the first point, there is often a tone of "patches welcome" in the
>> community, that is somewhat unwelcoming to users that can't or won't
>> develop code. This suggests that engagement solely on the development
>> terms is probably not a sustainable solution for the heterogenous
>> community that is developing around openstack. I think that it is
>> important to give these folks (ones that build systems, not so much
>> software) a role that they can identify with as a contributor to the
>> project.
>>
>> I think that there are a large range of gaps between the coding and
>> deployments today. Openstack supports a wide enough range of functions
>> (and IMO it is necessary, not incidental complexity) that it is
>> difficult to boil down to simple configurations. I think this poses a
>> serious difficulty for both documentation and testing. These issues
>> have been discussed at length, but make me wonder if a different
>> structure would address these gaps as well as the social split as
>> well.
>>
>> As I've written this, I'm realizing that the one thing that doesn't
>> sit well with me about the current structure you're proposing for the
>> user committee seems to institutionalize the current split between
>> developers and users, where I think that the committee should be
>> trying to figure out ways to blur the divisions between the groups.
>>
>> I'd suggest adding in an explicit mission for the group at the top of
>> the document, in addition to the mandate. I think that might set the
>> tone for the rest of the document in a productive way. Considering my
>> lack of standing on the committee, I think that it might be
>> presumptive for me to suggest its mission, but I think that the four
>> questions above capture many of the things that I think are important.
>>
>> I'm happy to help in any way you'd like. let me know if you'd like
>> additional comments, or participation in the documents in some
>> fashion.
>>
>> Happy holidays.
>> -nld
>>
>> _______________________________________________
>> Foundation mailing list
>> Foundation@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation
>>
>
>

_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

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

_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

Hi Naryan,

I've read your other posts too, thanks for your thoughtful response.

On 01/10/2013 04:31 AM, Narayan Desai wrote:
> First, let me say what I mean by users. When I talk about users, I
> mean people who primarily consume the software and use it. Some of
> these people will contribute back, in terms of bug reports, or perhaps
> even bug fixes, but their primary scope of work is deployment and
> operation of openstack.

So you're talking about the individuals deploying and operating
OpenStack in test and production environments? To summarise in few
words, sysadmins and DevOps?


> Dave, I think that my formulation of the user category is somewhat
> orthogonal to the categories that you're talking about; conceptually
> it is the user/dev split.

My main issue with the user/dev split in this context is that it does
not cover the spectrum of the OpenStack community - it does not cover
people who are not Python coders but who (for example) provide marketing
expertise, organisational support and budget, co-ordinating local
meet-ups, package OpenStack for various distributions, do some of the
glue work to make it install more easily, write documentation, work on
the website and wiki, and so on.

OpenStack users will, in general, be getting OpenStack from a third
party, be it Ubuntu, Red Hat, Fedora, Suse, whatever. Or they might make
an organisational commitment, and then the CIO would be the key decision
maker and bridge between his DevOps team and the foundation.

I think it would be useful for us to come up with a set of personas
(personae?) covering the various types of "OpenStack user" - because I
do not think that there is just one type. This would help us avoid the
trap of using broad unqualified statements ("users often...", "these
people usually...", "users tend to use...", "the focus of many users...").

> This leaves the question, how do we effectively build out this part of
> the ecosystem? I'm not sure that I have easy answers on this, but I
> think that this is the key issue that the user committee needs to
> tackle.

I think you raise good points about the user adoption cycle, and the
various support channels which might be useful. But deciding which
channels to prioritise, and where to expend energy short term, requires
us to understand what the specific needs of OpenStack users are.
Personas are a great tool for something like this.

Cheers,
Dave.

--
Dave Neary - Community Action and Impact
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13

_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

2013/1/10 Dave Neary <dneary@redhat.com>

> Hi Naryan,
>
> I've read your other posts too, thanks for your thoughtful response.
>
>
> On 01/10/2013 04:31 AM, Narayan Desai wrote:
>
>> First, let me say what I mean by users. When I talk about users, I
>> mean people who primarily consume the software and use it. Some of
>> these people will contribute back, in terms of bug reports, or perhaps
>> even bug fixes, but their primary scope of work is deployment and
>> operation of openstack.
>>
>
> So you're talking about the individuals deploying and operating OpenStack
> in test and production environments? To summarise in few words, sysadmins
> and DevOps?
>
>
>
> Dave, I think that my formulation of the user category is somewhat
>> orthogonal to the categories that you're talking about; conceptually
>> it is the user/dev split.
>>
>
> My main issue with the user/dev split in this context is that it does not
> cover the spectrum of the OpenStack community - it does not cover people
> who are not Python coders but who (for example) provide marketing
> expertise, organisational support and budget, co-ordinating local meet-ups,
> package OpenStack for various distributions, do some of the glue work to
> make it install more easily, write documentation, work on the website and
> wiki, and so on.
>
> OpenStack users will, in general, be getting OpenStack from a third party,
> be it Ubuntu, Red Hat, Fedora, Suse, whatever. Or they might make an
> organisational commitment, and then the CIO would be the key decision maker
> and bridge between his DevOps team and the foundation.
>
> I think it would be useful for us to come up with a set of personas
> (personae?) covering the various types of "OpenStack user" - because I do
> not think that there is just one type. This would help us avoid the trap of
> using broad unqualified statements ("users often...", "these people
> usually...", "users tend to use...", "the focus of many users...").
>
> Who can explain the difference between the User committee and User
Group?As we have many User group already right?


>
> This leaves the question, how do we effectively build out this part of
>> the ecosystem? I'm not sure that I have easy answers on this, but I
>> think that this is the key issue that the user committee needs to
>> tackle.
>>
>
> I think you raise good points about the user adoption cycle, and the
> various support channels which might be useful. But deciding which channels
> to prioritise, and where to expend energy short term, requires us to
> understand what the specific needs of OpenStack users are. Personas are a
> great tool for something like this.
>
>
> Cheers,
> Dave.
>
> --
> Dave Neary - Community Action and Impact
> Open Source and Standards, Red Hat - http://community.redhat.com
> Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
>
> ______________________________**_________________
> Foundation mailing list
> Foundation@lists.openstack.org
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**foundation<http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation>
>



--
--Ben

OSI Individual Member
OpenStack Foundation Board Member
Co-founder and Leader of China OpenStack User Group( COSUG )

Mobile: +86 15921531026
WEIBO: http://weibo.com/u/1716287123<http://www.weibo.com/u/1716287123?from=profile&wvr=4&loc=infweihao>
TWITTER: https://twitter.com/ben_Duyujie
LINKEDIN: cn.linkedin.com/in/duyujie

On Thu 10 Jan 2013 06:29:14 PM CET, Yujie Du wrote:
> Who can explain the difference between the User committee and User
> Group?As we have many User group already right?

The main difference is that the User Committee is an organ of the
OpenStack Foundation. Its mission is to represent the interests of
users inside the Foundation. It is a new organ that is getting formed.

The OpenStack User Groups are informal associations of people around
the world that meet to discuss about OpenStack, share knowledge and
experiences. These are important entities for the OpenStack project as
they help spreading awareness, recruit developers and users and more.
The user groups don't have a direct relation with the OpenStack
Foundation even though the members of the user groups can be members of
the Foundation and eventually be member of the User Committee.

cheers,
stef

_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

Dave, thanks for taking the time to respond. I think that it is clear
that there are a lot of opinions on this, and I think that it will
help us all to discuss them concretely.

On Thu, Jan 10, 2013 at 4:03 AM, Dave Neary <dneary@redhat.com> wrote:
>
> So you're talking about the individuals deploying and operating OpenStack in
> test and production environments? To summarise in few words, sysadmins and
> DevOps?

I really think that the important characteristic is this group's
relationship with the openstack project. These are folks that are less
involved in the project, contributing in a formal way either rarely or
not at all.

While operations types are in this category, I am thinking of it as a
more expansive category that includes people that are casually engaged
with openstack. I think this is an important distinction.

>> Dave, I think that my formulation of the user category is somewhat
>> orthogonal to the categories that you're talking about; conceptually
>> it is the user/dev split.
>
>
> My main issue with the user/dev split in this context is that it does not
> cover the spectrum of the OpenStack community - it does not cover people who
> are not Python coders but who (for example) provide marketing expertise,
> organisational support and budget, co-ordinating local meet-ups, package
> OpenStack for various distributions, do some of the glue work to make it
> install more easily, write documentation, work on the website and wiki, and
> so on.

Thinking about the engagement continuum, all of the folks that you are
describing above fall into the "more engaged" end of the spectrum,
right?

I'm not trying to suggest in any way that the user committee shouldn't
work with more engaged users as well; I currently see the gap being
largest in terms of casually engaged users.

> OpenStack users will, in general, be getting OpenStack from a third party,
> be it Ubuntu, Red Hat, Fedora, Suse, whatever. Or they might make an
> organisational commitment, and then the CIO would be the key decision maker
> and bridge between his DevOps team and the foundation.

I'm not sure that I agree with this. While many OpenStack users will
be getting packages from a third party, I think that it would be a
mistake for the project to assume that consumers will be completely
abstracted away from the upstream project here. Moreover, I think that
balkanizing what active user community we have by splitting it across
the different distribution is not the best move here.

I'm actually not so concerned about users when they get to the point
of making an organizational commitment. At that point, they will be
contributing in some fashion, they definitely have institutional buy
in, and the associated mandate to contribute to the community. I feel
like the existing processes seem to work pretty well for contributors.

> I think it would be useful for us to come up with a set of personas
> (personae?) covering the various types of "OpenStack user" - because I do
> not think that there is just one type. This would help us avoid the trap of
> using broad unqualified statements ("users often...", "these people
> usually...", "users tend to use...", "the focus of many users...").

This is a good idea, particularly in a group that is this large.

We can definitely start with:
- adopters/deployers of openstack
- institutional contributors of openstack
- user group coordinators

I'm sure I'm missing others here. I wasn't intending to be exclusive
in the particular user classification I was discussing, I just see a
lot of issues in that particular ecosystem.
-nld

_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

I've really appreciated the discussions in these areas as it has touched on
many of the areas that I struggled with as I tried to answer "who is an
openstack user" for the points for discussion document.

One of the big flexibilities of the user committee is that there are not a
large set of bylaws currently and I think we should maintain flexibility going
forward so that we can evolve the user committee.

That we are currently addressing the 'engaged user' communities with more
emphasis than the 'casually engaged' reflects the point of the cycle we are
in. There are concrete items we need to do to address the engaged user needs
so we can start here (but make sure that we do not construct a closed
definition of a user to exclude the casual ones).

Tim

> -----Original Message-----
> From: Narayan Desai [mailto:narayan.desai@gmail.com]
> Sent: 10 January 2013 22:00
> To: Dave Neary; foundation@lists.openstack.org; Tim Bell
> Subject: Re: [OpenStack Foundation] Thinking about the mission of the user
> committeee
>
> Dave, thanks for taking the time to respond. I think that it is clear that
> there are
> a lot of opinions on this, and I think that it will help us all to discuss
> them
> concretely.
>
> On Thu, Jan 10, 2013 at 4:03 AM, Dave Neary <dneary@redhat.com> wrote:
> >
> > So you're talking about the individuals deploying and operating
> > OpenStack in test and production environments? To summarise in few
> > words, sysadmins and DevOps?
>
> I really think that the important characteristic is this group's
> relationship with
> the openstack project. These are folks that are less involved in the
> project,
> contributing in a formal way either rarely or not at all.
>
> While operations types are in this category, I am thinking of it as a more
> expansive category that includes people that are casually engaged with
> openstack. I think this is an important distinction.
>
> >> Dave, I think that my formulation of the user category is somewhat
> >> orthogonal to the categories that you're talking about; conceptually
> >> it is the user/dev split.
> >
> >
> > My main issue with the user/dev split in this context is that it does
> > not cover the spectrum of the OpenStack community - it does not cover
> > people who are not Python coders but who (for example) provide
> > marketing expertise, organisational support and budget, co-ordinating
> > local meet-ups, package OpenStack for various distributions, do some
> > of the glue work to make it install more easily, write documentation,
> > work on the website and wiki, and so on.
>
> Thinking about the engagement continuum, all of the folks that you are
> describing above fall into the "more engaged" end of the spectrum, right?
>
> I'm not trying to suggest in any way that the user committee shouldn't work
> with more engaged users as well; I currently see the gap being largest in
> terms
> of casually engaged users.
>
> > OpenStack users will, in general, be getting OpenStack from a third
> > party, be it Ubuntu, Red Hat, Fedora, Suse, whatever. Or they might
> > make an organisational commitment, and then the CIO would be the key
> > decision maker and bridge between his DevOps team and the foundation.
>
> I'm not sure that I agree with this. While many OpenStack users will be
> getting
> packages from a third party, I think that it would be a mistake for the
> project to
> assume that consumers will be completely abstracted away from the upstream
> project here. Moreover, I think that balkanizing what active user community
> we
> have by splitting it across the different distribution is not the best move
> here.
>
> I'm actually not so concerned about users when they get to the point of
> making
> an organizational commitment. At that point, they will be contributing in
> some
> fashion, they definitely have institutional buy in, and the associated
> mandate to
> contribute to the community. I feel like the existing processes seem to work
> pretty well for contributors.
>
> > I think it would be useful for us to come up with a set of personas
> > (personae?) covering the various types of "OpenStack user" - because I
> > do not think that there is just one type. This would help us avoid the
> > trap of using broad unqualified statements ("users often...", "these
> > people usually...", "users tend to use...", "the focus of many users...").
>
> This is a good idea, particularly in a group that is this large.
>
> We can definitely start with:
> - adopters/deployers of openstack
> - institutional contributors of openstack
> - user group coordinators
>
> I'm sure I'm missing others here. I wasn't intending to be exclusive in the
> particular user classification I was discussing, I just see a lot of issues
> in that
> particular ecosystem.
> -nld

2013/1/11 Stefano Maffulli <stefano@openstack.org>

> On Thu 10 Jan 2013 06:29:14 PM CET, Yujie Du wrote:
>
>> Who can explain the difference between the User committee and User
>> Group?As we have many User group already right?
>>
>
> The main difference is that the User Committee is an organ of the
> OpenStack Foundation. Its mission is to represent the interests of users
> inside the Foundation. It is a new organ that is getting formed.
>
> The OpenStack User Groups are informal associations of people around the
> world that meet to discuss about OpenStack, share knowledge and
> experiences. These are important entities for the OpenStack project as they
> help spreading awareness, recruit developers and users and more. The user
> groups don't have a direct relation with the OpenStack Foundation even
> though the members of the user groups can be members of the Foundation and
> eventually be member of the User Committee.
>
> cheers,
> stef
>

Thanks!
Last year COSUG has organized many activities in China last year,1000+
participants,but we couldn't solve their appeal for the products of
OpenStack. So I think if they can get the timely corresponding from the
User Committee,it will be great!

And for the success of the foundation the Users from Asia-Pacific can not
be ignored. "OpenStack has been huge in APAC! "
https://www.networkworld.com/news/2013/011013-openstack-mirantis-265702.html?hpg1=bn


--
--Ben

OSI Individual Member
OpenStack Foundation Board Member
Co-founder and Leader of China OpenStack User Group( COSUG )

Mobile: +86 15921531026
WEIBO: http://weibo.com/u/1716287123<http://www.weibo.com/u/1716287123?from=profile&wvr=4&loc=infweihao>
TWITTER: https://twitter.com/ben_Duyujie
LINKEDIN: cn.linkedin.com/in/duyujie

Narayan Desai wrote:
> I'm also not meaning to suggest that there aren't users that are
> stepping into the fray in terms of user support. We all know the
> familiar names from the mailing list and IRC of people that step up,
> but there seems to be an insufficient number of these people for the
> community as it stands, nevermind the community we hope to have
> tomorrow.
>
> This leaves the question, how do we effectively build out this part of
> the ecosystem? I'm not sure that I have easy answers on this, but I
> think that this is the key issue that the user committee needs to
> tackle.

One way to effectively build out this part of the ecosystem is to give
it the right tools. Mailing-lists, IRC channels and forums all have
drawbacks when it comes to user support, in particular you end up
answering the same question over and over again, with no simple way of
consolidating answers, improving them, or come up with a great FAQ.

The tool of choice for that is a Q&A site (like stackexchange). This
allows casual users and experts to efficiently provide answers to the
most pressing questions, avoid repeating yourself and build a reputation
that gives you more control over the site features. I think it will go a
long way in enabling that part of the ecosystem.

Good news is that the Foundation staff is working on setting one such
site up.

Regards,

--
Thierry Carrez (ttx)
Release Manager, OpenStack

_______________________________________________
Foundation mailing list
Foundation@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

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