Open Stack

Hi all,

As per Anne's recent email, I strongly oppose splitting out a new guide
for upgrades.

Essentially, I don't believe there is a maintenance, discoverability or
contribution problem for the upgrades section of the ops guide - we've
done well at all of these for the past few releases. Similarly, there is
no problem with having different architectures with the install guide -
both guides have very different aims, objectives and audiences.

However, what I want to talk with you about is slightly different to
those concerns.

Normally, I wouldn't intervene in something like this, but we have a
massive problem in documentation that no-one seems to be talking about.
And, instead of fixing it, we're performing busywork like this guide
split :) It may create a feeling of making great progress since we're
doing massive wide-ranging, high-line-count changes, but we're actually
falling further and further behind.

Of course, what I'm referring to is our massive bug backlog. We have
more than seven hundred bugs, and according to the stats from Bitergia
the worst performance rate at closing them than any OpenStack project by
a long way.

I've watched our bug backlog from about the time it was in the dozens -
at that time, I could actually remember every single bug and its status
:) Since then, our project has grown - and our team has grown to match.
However, our ability to tackle the bug backlog did not improve - it got
worse. This problem is not just in the raw number of contributors.

So, with such a situation as this, it causes pause to ask: why were only
around half of our commits in Juno related to bringing a bug to closure?
What were the other half doing?

Each bug represents a problem with our documentation. Something that is
incorrect, or a feature that essentially will not exist for a user until
it is written down.

For example, this release, we did not even manage to write up headline
features, such as cinder's volume replication, swift's global clusters
or storage policies. These features came about from strong demand from
our users and at the moment we're failing them badly.

Is there anyone out there who also cares about this? Who is monitoring
this? Who wants to do something about this?

Or, perhaps you'd prefer to copy and paste some more files around
different repositories...


... but it's not nice to leave an email on such a note. This problem is
solvable, and conveniently we have an in-person meeting coming ~today.
Perhaps we can re-focus our efforts and priorities there, and
ensure they're really about delivering the most benefit for our audience.



Regards,


Tom