Open Stack

Based on my experience with two of the largest open source projects
Firefox and WordPress, I'd not recommend worrying about swamping and
discourage having a separate knowledge base of problems/requests. Any
well described specific issue should be added to the single (feature
request & bug) tracker, where they can be searched for, commented on
and advocated for by the whole community. Complexity and additional
processes are an enemy, and should only be experimented with to
address experienced issues.

I see the User Committee's greatest opportunity to champion the
systematic issues and support users in navigating and utilizing
OpenStack's channels and processes.

Thank you,
Lloyd

On Thu, Nov 8, 2012 at 10:35 AM, Tim Bell <Tim.Bell at cern.ch> wrote:
>
> The prioritisation/formulation is really important to avoid that we swamp
> the development teams with complex/critical problems which may be vital to
> one user but are less important to the rest of the user community.
>
> There is also a need to aggregate items, where different users state the
> same problem in different ways.
>
> With the good start James has made, let's inventory the pain points as the
> 1st step...  before raising blueprints, we need to reflect, aggregate and
> formulate our needs as a user community.
>
> Tim
>
>> -----Original Message-----
>> From: Michael Still [mailto:michael.still at canonical.com]
>> Sent: 08 November 2012 19:23
>> To: James R Penick
>> Cc: Tim Bell; openstack-operators at lists.openstack.org
>> Subject: Re: [Openstack-operators] Operations use cases/pain points
>>
>> On 11/09/2012 03:44 AM, James R Penick wrote:
>> > Excellent idea! I'll add severity to the wiki.
>>
>> I think this list is really good, but ultimately its going to need to turn
> into a
>> series of bugs (or blueprints for things which are more systemic). I'm not
>> saying that operators need to fix those bugs, but its the best way to
>> communicate with the developers.
>>
>> So, perhaps the wiki page is where things are incubated for a bit before
> being
>> turned into bugs / blueprints?
>>
>> Mikal


--
@lloyddewolf
http://www.pistoncloud.com/