Open Stack

On 05/15/2015 07:20 AM, Boris Pavlovic wrote:
> John,
> 
> 
>     So, you can have all details in the spec, or you can have only the
>     problem statement complete. Its up to you as a submitter how much
>     detail you want to provide. I would recommend adding rough ideas into
>     the alternatives section, and leaving everything else blank except the
>     problem statement.
> 
> 
>      We are trying to use a single process for "parked" developer ideas and
>     operator ideas, so they are on an equal footing.
>     The reason its not just a "bug" or similar, is so we are able to
>     review the idea with the submitter, to ensure we have a good enough
>     problem description, so a developer can pick up and run with the idea,
>     and turn it into a more complete spec targeted at a specific release.
>     In addition, we are ensuring that the problem description is in scope.
> 
> 
> Feature requests are the same process as specs. And I fully agree 
> that bug reports are not good idea for this. 
> 
> The only difference is template. I believe you won't find end users
> that would like to spend time to read all this steps:
> http://specs.openstack.org/openstack/nova-specs/specs/kilo/template.html 
> and provide required info. 
> 
> As an end users I would like to spend maximum 5 minutes to provide info
> about:
> - use case
> - problem description 
> - possible solution [optional]
> 
> 
> What about making nova template simpler? 
> And actually doing this across all projects? 

So... "maximum 5 minutes" is where I think that idea goes horribly off
the rails. Because it actually sets up the *wrong* expectations of how
we make progress as a community, and is only going to cause anger and
frustration by all parties.

Adding most features to most projects requires a reasonable conversation
about how that impacts other parts of that project, and other projects
in OpenStack, and how it impacts existing deploys of OpenStack, and
compatibility between OpenStack implementations in the field, especially
as we try to get more serious about interoperability.

I get that everyone wants an easy button, and for magical elves to do
stuff. However I think Rally is the anomaly here, as it doesn't need to
address many of these concerns for where it lives in the tools stack.

And easy process for submit, that ends up with too little information or
engagement to be useful, is worse than none at all. Because then there
is just a black hole in the middle where everything is going to get lost.

We make progress as a community by building strong communication ties
across different points of views, reaching out across processes, and
being willing, on all parts, to invest time to move things forward
together. It's one of the reasons I think the Ops meetups have been very
successful, as they provide really great forums to do that.

We don't do it with a max 5 minute submit process.

	-Sean

-- 
Sean Dague
http://dague.net