Open Stack

Over the last couple of years, our launchpad blueprints have grown
unruly [0] (~77 blueprints a few days ago). The majority of them were in
"New" status, unmaintained, and several years old (some dating back to
2013). Even though we've been using specifications [1] for several
years, people still get confused when they see conflicting or inaccurate
blueprints. After another person tripped over a duplicate blueprint this
week, cmurphy, vishakha, and I decided to devote some attention to it.
We tracked the work in an etherpad [2] - so we can still find links to
things.

First, if you are the owner of a blueprint that was marked as
"Obsolete", you should see a comment on the whiteboard that includes a
reason or justification. If you'd like to continue the discussion about
your feature request, please open a specification against the
openstack/keystone-specs repository instead. For historical context,
when we converted to specifications, we were only supposed to create
blueprints for tracking the work after the specification was merged.
Unfortunately, I don't think this process was ever written down, which
I'm sure attributed to blueprint bloat over the years.

Second, if you track work regularly using blueprints or plan on
delivering something for Stein, please make sure your blueprint in
Launchpad is approved and tracked to the appropriate release (this
should already be done, but feel free to double check). The team doesn't
plan on switching processes for feature tracking mid-release. Instead,
we're going to continue tracking feature work with launchpad blueprints
for the remainder of Stein. Currently, the team is leaning heavily
towards using RFE bug reports for new feature work, which we can easily
switch to in Train. The main reason for this switch is that bug comments
are immutable with better timestamps while blueprint whiteboards are
editable to anyone and not timestamped very well. We already have
tooling in place to update bug reports based on commit messages and that
will continue to work for RFE bug reports.

Third, any existing blueprints that aren't targeted for Stein but are
good ideas, should be converted to RFE bug reports. All context from the
blueprint will need to be ported to the bug report. After a sufficient
RFE bug report is opened, the blueprint should be marked as "Superseded"
or "Obsolete" *with* a link to the newly opened bug. While this is
tedious, there aren't nearly as many blueprints open now as there were a
couple of days ago. If you're interested in assisting with this effort,
let me know.

Fourth, after moving non-Stein blueprints to RFE bugs, only Stein
related blueprints should be open in launchpad. Once Stein is released,
we'll go ahead disable keystone blueprints.

Finally, we need to overhaul a portion of our contributor guide to
include information around this process. The goal should be to make that
documentation clear enough that we don't have this issue again. I plan
on getting something up for review soon, but I don't have anything
currently, so if someone is interested in taking a shot at writing this
document, please feel free to do so. Morgan has a patch up to replace
blueprint usage with RFE bugs in the specification template [3].

We can air out any comments, questions, or concerns here in the thread.

Thanks,

Lance

[0] https://blueprints.launchpad.net/keystone
[1] http://specs.openstack.org/openstack/keystone-specs/
[2] https://etherpad.openstack.org/p/keystone-blueprint-cleanup
[3] https://review.openstack.org/#/c/625282/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190213/b53bad53/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190213/b53bad53/attachment-0001.sig>