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