Open Stack

On Mon, 25 Feb 2019, Matt Riedemann wrote:

> On 2/25/2019 5:53 AM, Chris Dent wrote:
>> So, to take it back to Matt's question, my opinion is: Let's let
>> existing stuff run its course to the end of the cycle, decide
>> together how and when we want to implement storyboard.
>
> FWIW I agree with this. I'm fine with no separate specs repo or core team. I 
> do, however, think that having some tracking tool is important for project 
> management to get an idea of what is approved for a release and what is left 
> (and what was completed). Etherpads are not kanban boards nor are they 
> indexed by search engines so they are fine for notes and such but not great 
> for long-term documentation or tracking.

I've started the process of implementing a form of
"specs-management". There's a review [1] in progress for in-tree
specs, within the existing docs. The template file in there
describes a slightly different process from nova. Instead of
launchpad blueprints, things that might eventually need a spec
should start as a StoryBoard story. Review of that story will
determine if a spec is required, at which point one will be proposed
to docs/source/specs/<cycle>/approved.

Once it is implemented, it will get moved to
docs/source/specs/<cycle>/implemented.

There a simple automatic table of contents at
docs/source/specs/index.rst that will need to be updated for each
cycle (along with the cycle-related directories and template).

Does this seem like a workable process for people? I've deliberately
made it no big deal, easy to change, and not made any strict
assertions about what does or not need a spec or blueprint. We can
learn as we go, yeah? Talking to one another and such.

As I said in the commit on the review:

* It will sometimes be hard to figure out if a spec is a nova spec
   or a placement spec. We'll get better at that, and deal with it
   as required.

* Assuming people like this plan, specs that were solely for placement
   in stein, but didn't get completed should be resubmitted to the
   placement repo as a train spec.

One this all settles out we should update the contributing docs to
reflect the process.

Thanks.

[1] https://review.openstack.org/#/c/645195/1


-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent