Open Stack

This a "part 2" or "other half" of evaluating OpenStack projects in
relation to the technical vision. See the other threads [1][2] for
more information.

In the conversations that led up to the creation of the vision
document [3] one of the things we hoped was that the process could
help identify ways in which existing projects could evolve to be
better at what they do. This was couched in two ideas:

* Helping to make sure that OpenStack continuously improves, in the
   right direction.
* Helping to make sure that developers were working on projects that
   leaned more towards interesting and educational than frustrating
   and embarrassing, where choices about what to do and how to do it
   were straightforward, easy to share with others, so
   well-founded in agreed good practice that argument would be rare,
   and so few that it was easy to decide.

Of course, to have a "right direction" you first have to have a
direction, and thus the vision document and the idea of evaluating
how aligned a project is with that.

The other half, then, is looking at the projects from a development
standpoint and thinking about what aspects of the project are:

* Things (techniques, tools) the project contributors would encourage
   others to try. Stuff that has worked out well.

* Things—given a clean slate, unlimited time and resources, the
   benefit of hindsight and without the weight of legacy—the project
   contributors would encourage others to not repeat.

And documenting those things so they can be carried forward in time
some place other than people's heads, and new projects or
refactorings of existing projects can start on a good foot.

A couple of examples:

* Whatever we might say about the implementation (in itself and how
   it is used), the concept of a unified configuration file format,
   via oslo_config, is probably considered a good choice, and we
   should keep on doing that.

* On the other hand, given hindsight and improvements in commonly
   available tools, using a homegrown WSGI (non-)framework (unless
   you are Swift) plus eventlet may not have been the way to go, yet
   because it is what's still there in nova, it often gets copied.

It's not clear at this point whether these sorts of things should be
documented in projects, or somewhere more central. So perhaps we can
just talk about it here in email and figure something out. I'll
followup with some I have for placement, since that's the project
I've given the most attention.

[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001417.html
[2] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002524.html
[3] https://governance.openstack.org/tc/reference/technical-vision.html

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