Open Stack

On 2017-06-21 13:52:11 -0500 (-0500), Lauren Sell wrote:
[...]
> To make this actionable...Github is just a mirror of our
> repositories, but for better or worse it's the way most people in
> the world explore software. If you look at OpenStack on Github
> now, it’s impossible to tell which projects are official. Maybe we
> could help by better curating the Github projects (pinning some of
> the top projects, using the new new topics feature to put tags
> like openstack-official or openstack-unofficial, coming up with
> more standard descriptions or naming, etc.).

I hadn't noticed the pinned repositories option until you mentioned
it: appears they just extended that feature to orgs back in October
(and introduced the topics feature in January). I could see
potentially integrating pinning and topic management into the
current GH API script we run when creating new mirrors
there--assuming these are accessible via their API anyway--and yes
normalizing the descriptions to something less freeform is something
else we'd discussed to be able to drive users back to the official
locations for repositories (or perhaps to the project navigator).

I've already made recent attempts to clarify our use of GH in the
org descriptions and linked the openstack org back to the project
navigator too, since those were easy enough to do right off the bat.

> Same goes for our repos…if there’s a way we could differentiate
> between official and unofficial projects on this page it would be
> really useful: https://git.openstack.org/cgit/openstack/

I have an idea as to how to go about that by generating custom
indices rather than relying on the default one cgit provides; I'll
mull it over.

> 2) Create a simple structure within the official set of projects
> to provide focus and a place to get started. The challenge (again
> to our success, and lots of great work by the community) is that
> even the official project set is too big for most people to
> follow.

This is one of my biggest concerns as well where high-cost (in the
sense of increasingly valuable Infra team member time) solutions are
being tossed around to solve the "what's official?" dilemma, while
not taking into account that the overwhelming majority of active Git
repositories we're hosting _are_ already deliverables for official
teams. I strongly doubt that just labelling the minority as
unofficial will any any way lessen the overall confusion about the
*more than one thousand* official Git repositories we're
maintaining.

> While I fully admit it was an imperfect system, the three tier
> delineation of “integrated," “incubated" and “stackforge" was
> something folks could follow pretty easily. The tagging and
> mapping is valuable and provides additional detail, but having the
> three clear buckets is ideal.  I would like to see us adopt a
> similar system, even if the names change (i.e. core infrastructure
> services, optional services, stackforge). Happy to throw out ideas
> if there is interest.
[...]

Nearly none (almost certainly only a single-digit percentage anyway)
of the Git repositories we host are themselves source code for
persistent network services. We have lots of tools, reusable
libraries, documentation, meta-documentation, test harnesses,
configuration management frameworks, plugins... we probably need a
way to reroute audiences who are not strictly interested in browsing
source code itself so they stop looking at those Git repositories or
else confusion is imminent regardless. As a community we do nearly
_everything_ in Git, far beyond mere application and service
software.

The other logical disconnect I'm seeing is that our governance is
formed around teams, not around software. Trying to explain the
software through the lens of governance is almost certain to confuse
newcomers. Because we use one term (OpenStack!) for both the
community of contributors and the software they produce, it's going
to become very tangled in people's minds. I'm starting to strongly
wish could use entirely different names for the community and the
software, but that train has probably already sailed (and could
result in different confusion all its own too, I suppose).
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170621/cd198986/attachment.sig>