On Sun, 24 Feb 2019, Matt Riedemann wrote:

The issue is none of the changes are being reflected back in the whiteboard for the blueprint in launchpad because the changes are made in the extracted placement repo which doesn't have a launchpad project, nor is there anything in storyboard for placement.

Yeah, there's a similar issue with os-resource-classes releases not updating launchpad bugs as released. Probably others.

Right now it's a small thing, but I'm wondering what, if any, plans are in place for tracking blueprints for the extracted placement repo. I'm assuming the answer is storyboard but maybe it hasn't been discussed much yet.

As Jay and Eric point out we've talked about what to do about specs and months ago there was some talk of "well, eventually we'll go to storyboard" but that was sort of pending governance decisions and stability. I guess we're nearly there. (more below...) On Sun, 24 Feb 2019, Jay Pipes wrote:

There was some light discussion about it on IRC a couple weeks ago. I mentioned my preference was to not have a separate specs repo nor use the Launchpad blueprints feature. I'd rather have a "ideas" folder or similar inside the placement repo itself that tracks longer-form proposals in Markdown documents.

I like no-separate-specs-repo ideas as well and got the sense that most people felt the same way. I think still having some kinds of specs for at least some changes is a good idea, as in the past it has helped us talk through an API to get it closer to right before writing it. We don't need spec-cores and I reckon the rules for what needs a spec can be loosened, depending on how people feel. (Markdown! I'd love to do markdown but using existing tooling, and including all these artifacts in the existing docs (even if they are just "ideas") seems a good thing.) On Sun, 24 Feb 2019, Eric Fried wrote:

+1 to combining specs into the code repo.

Re launchpad vs storyboard: This may be going too far, but is "neither" an option? The information in a blueprint has always seemed largely redundant to me. Approved blueprints can be review.o.o?proj=placement&status=merged&path=specs/$release/approved/*. Whiteboards can be etherpads (which is what I thought you were talking about originally, which confused me, because I marked the placement blueprints unblocked on the etherpad last week; didn't think to duplicate that to the blueprints, my bad.) Are etherpads any more... "ethereal" than lp whiteboards or storyboards? (Does anyone look at those after the blueprint is closed?)

I agree that blueprint+spec management has felt largely redundant, probably because one came later than the other. However, I'd prefer for us to kind of unify under storyboard rather than mix and match several different pieces. I think etherpads are pretty good for the note taking thing at PTGs and the like, but execrable for pretty much everything else. (What follows are just some ideas, for comment, we'll have to figure out together what will work best.) I haven't had a chance to really learn up on storyboard as much as I would like, but I think we should probably try to use it as a central tracking place. Features that warrant a spec should be a story where one of the tasks in the story is the spec itself. The rest of the tasks are the implementation. tags, boards and lists ought to allow us to create useful views. Storyboard isn't fully soup yet, but we can help push it in that direction. We should probably create ourselves there and update infra config so gerrit updates happen well. For things that are currently in progress, we should simply carry on with them as they are, and manage them manually. That means paying some close attention to the 4 extant blueprints and the various bugs. At the end of Stein we should kill or migrate what's left. 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. (I've been sort of putting these kinds of questions off until there's a new PTL.) -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

On Mon, 2019-02-25 at 09:25 -0600, 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. for what its worth i would proably jsut creat a specs folder in the placement repo and then choose to use it as much or as little as required. kolla-ansible for example has an in repo specs folder but it only uses it very sparingly so the presence of a spec folder does not mean you have to use it for every feature. they use rfe bugs/blueprint to track most features and you could make the decision on that later depening on what tool suits placment best. be that lauchpad,storyboard or just etherpad. etherpad i think make more sense for tracking review priorites rather then completion but

for what its worth os-vif does have its own launchpad add we just use RFE bugs for any non cross project features. for cross project stuff e.g. nova usecases we use a nova bug/blueprint/sepc. the donwside of this is ironic approved a spec after m2 for a feature this release that required a os-vif change and we didnt know about it so we had to review it quickly not to block them. in that case i would have prefered at least an rfe bug against os-vif to tacked the change. anyway that is just my 2 cents out of tree specs repos with a sepreate specs core team has its uses but its overkill i think in most cases espcially for small repos like placement or os-vif but haveing a placemnt spec dir might be helpful in some cases.

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

On Mon, 2019-02-25 at 11:53 +0000, Chris Dent wrote:

On Sun, 24 Feb 2019, Jay Pipes wrote:

...

There was some light discussion about it on IRC a couple weeks ago. I mentioned my preference was to not have a separate specs repo nor use the Launchpad blueprints feature. I'd rather have a "ideas" folder or similar inside the placement repo itself that tracks longer-form proposals in Markdown documents.

I like no-separate-specs-repo ideas as well and got the sense that most people felt the same way.

I think still having some kinds of specs for at least some changes is a good idea, as in the past it has helped us talk through an API to get it closer to right before writing it. We don't need spec-cores and I reckon the rules for what needs a spec can be loosened, depending on how people feel.

(Markdown! I'd love to do markdown but using existing tooling, and including all these artifacts in the existing docs (even if they are just "ideas") seems a good thing.)

This is the only bit of this I actually have a strong opinion on :) Please, please stick to rST+Sphinx. It's certainly flawed but there is value in going to any OpenStack project and knowing how the documentation will work. /me goes back to lurking. Stephen