Open Stack

I'm not keen on a 2nd database but I am keen on, as you say, "well described
specific issues". There may be additional process steps required.

Our user community should not be obliged to understand the internals of
OpenStack. Many high level pain points can have multiple project hits (e.g.
horizon/keystone/nova) and allowing a user to enter their pain point into a
wiki without needing to formulate the detail is required to ensure maximum
opportunities for participation and input. A developer can always choose
that a problem is sufficiently important that they do the patches, many of
the users we want to reach do not have this skill set but contribute in
other ways to the OpenStack community.

Bugs are somewhat easier than requests... if something does not work as it
is documented, this can be made concrete. Requests are more problematic and
need prioritisation. The user committee can help in highlighting those
requests for enhancement which are a concern to a substantial share of the
production deployments.

Tim

> -----Original Message-----
> From: Lloyd Dewolf [mailto:lloydostack at gmail.com]
> Sent: 08 November 2012 20:04
> To: Tim Bell; Michael Still; James R Penick; openstack-
> operators at lists.openstack.org
> Subject: Re: [Openstack-operators] Operations use cases/pain points
> 
> 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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5201 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20121108/9b2ec721/attachment.bin>