[CMS-411] Project support levels

[greg-1-anderson]

Do not commit - example project support levels with badges

[CdrMarks]

I've added add a Support Level column to the public repository spreadsheet. It should be a good way to see how Greg's suggested levels will apply to our repos.

[jazzsequence]

The white-on-yellow would be an accessibility issue for too low of a contrast ratio (https://webaim.org/resources/contrastchecker/?fcolor=FFFFFF&bcolor=D6AE22). There are additional styles/parameters that we can pass to shields.io to tweak that, I propose:

Suggested change

	| Badge | Description
	| ----- | -----------
	|  | Actively maintained
	|  | Minimal support, e.g. examples
	|  | Unsupported, e.g. end-of-life / no longer relevant
	|  | Unofficial, e.g. public repo made by employee (hackweek project et. al.)

I'm not 100% sold on only one color for the badge colors, but the for-the-badge style makes the text much more readable, so it's easier to see/understand at a glance, as does the black text on the pantheon yellow background (which passes a11y contrast review).

[CdrMarks]

@greg-1-anderson Where do you think repositories where the README states it's experimental should be categorized? https://github.com/pantheon-systems/site-audit-tool is one I found. I'd like to see experimental added to one of the support level descriptions.

[stevector]

@greg-1-anderson do you have a spreadsheet (or something) that has an initial categorization of repos and statuses? Part of why I ask is because I'm concerned that 8 statuses might be too many and some of these might be duplicative, contradictory, or confusing.

For instance something under "community support" could also be "minimally maintained" or "actively maintained." Similarly repositories in some kind of early access or limited availability I suspect might have the more engagement from the engineering team than niche repos that are important but have not had significant development in years.

If we are going to use "early access" and "limited availability" as repo labels then I think should also include "general availability" because those three terms have been in wide use to describe product/feature maturity. We also presently have active work to tighten up those definitions (and add Proof-of-Concept and Pilot).

"Unofficial" is a status I would prefer not exist. I know that we have repos that match the description of "public repo made by employee (hackweek project et. al.)" but I would prefer that we eliminate this category by making these repos private, archiving them, or moving them to personal accounts.

"Deprecated" seems to duplicate the "archive" feature now native to GitHub. Do we need it?

[greg-1-anderson]

do you have a spreadsheet (or something) that has an initial categorization of repos and statuses?

See the link on the first comment, above.

For instance something under "community support" could also [have varying levels of support]

True. Some feedback I received previously is that we shouldn't label something actively maintained unless it is maintained by Pantheon (or more to the point, there should be a way to determine that a project is supported by Pantheon), but it might discourage community involvement if we labeled them some flavor of "unsupported". Maybe we should put these repos in a different org? (See my comment on unofficial repos below.)

repositories in some kind of early access or limited availability I suspect might have the more engagement from the engineering team than niche repos

Yes, I agree that from a customer perspective, EA and LA projects are equivalent to (or better than) "actively maintained" repositories. However, if a project is EA or LA, you might not have the right to receive support, and requests may be closed or ignored as a result.

If we are going to use "early access" and "limited availability" as repo labels then I think should also include "general availability"

While I like the symmetry, "General Availability" doesn't read the same as "Actively Maintained" IMO.

"Unofficial" is a status I would prefer not exist.

I see where you are coming from, but I am -1 on the idea of preventing employees from creating public repositories. Maybe moving them all to a separate org would be okay (and preferable to forcing them to a personal account)? The downside of separate orgs (e.g. pantheon-upstreams) is that pantheon-systems teams do not carry over.

"Deprecated" seems to duplicate the "archive" feature now native to GitHub.

Possibly. To me, it seems less invasive to open a PR labeling a project "deprecated" than just archiving it. Maybe we could label a project deprecated as a preamble to archiving it? Then archived projects should by convention have a deprecated badge. Of course, there's nothing stoping someone from archiving a project without updating the badge. That would look strange, but I suspect folks would figure it out, perhaps after a bit of head scratching.

I don't feel that I am the final arbitrator on these decisions; however, neither do we have an established formal process. Fortunately, we have decided not to create any pull requests until Q1, so we have more time to discuss and decide how to decide.

[stevector]

See the link on the first comment, above.

🤦 Thanks!

On "Community Support," there's only one repo in the list in that label and it looks like Pantheors are involved in that repo making commits in the last month. I'm not sure what "Community support" is meant to convey here other than what you mentioned ("it might discourage community involvement if we labeled them some flavor of 'unsupported'"). But that risk seems moot for now when the one repo in the label presently has Pantheor-involvement.

[greg-1-anderson]

During the meeting where "community support" was discussed, some folks (sorry, not remembering who) seemed to think that there were a plurality of such repos in pantheon-systems. I can't think of (and didn't seem to find) any examples of that, though, beyond our upstreams. So perhaps this is one label we can do without.

[stevector]

Sorry, I hit "comment" before fully responding above. Here's more:

However, if a project is EA or LA, you might not have the right to receive support, and requests may be closed or ignored as a result.

While I like the symmetry, "General Availability" doesn't read the same as "Actively Maintained" IMO.

I think I'd feel better about this labels if we had an accompanying flow chart. I think in part the intention here is to label different stages in a lifecycle. Or maybe not a cycle just a journey from "this is new" to "this is an actively maintained product" to "this has reached some kind of EOL"

I see where you are coming from, but I am -1 on the idea of preventing employees from creating public repositories.

I also don't want to put up too much red tape but the "unsupported" label might be more appropriate. I just don't want us tricking ourselves into thinking we can have it both ways of a repo being literally under our organization but applying a label that potentially-confusingly disclaims responsibility for the fact that it's a repo in our org.

Maybe we could label a project deprecated as a preamble to archiving it?

👍

So perhaps this is one label we can do without.

➕

[greg-1-anderson]

OK, so maybe we move the current "Unsupported" and "Unofficial" repositories to "Minimal Support", so everything that is above a certain bar of acknowledgement is claimed to have greater-than-epsilon support (without defining how small or large "Minimal" is), and then pick one of "Unsupported" or "Deprecated" to indicate a repo that has clearly "aged out" and is not recommended for use (pre-archived). A possible permutation, anyway.

EDIT Or maybe "Unoficial" => "Unsupported"

[greg-1-anderson]

I think I'd feel better about this labels if we had an accompanying flow chart

Oh, yes, I forgot to mention that it is the vision that these badges would link to a docs page that explained them. That page could have whatever sort of relationship diagram was desired on it.

[greg-1-anderson]

Where do you think repositories where the README states it's experimental should be categorized?

Experimental implies EA or LA. However, in the case of the site audit tool, that's actually actively maintained / in production. However, how "active" the active maintenance is is rather questionable, since the README is out of date, and there's an important views-ui bugfix PR that's been waiting a year or so to be deployed. We'll label projects with their aspirational rather than actual support levels, though.

[stevector]

Experimental implies EA or LA.

That's a good example of why I think it's risky to re-use the terms EA and LA if we're not very intentional about aligning them to the meaning of product release phases. In the definitions formalizing now, a product in "LA" or "EA" would no longer be experimental. There may be given elements of the product that are subject to change but the whole idea of the project/product/repo should have been proven out in an earlier stage (PoC and/or Pilot)

[jazzsequence]

We can (and probably should) add alt text to all of these with the longer explanations/definitions. This would be great for a11y but also to add the contextual details that would be lost by the badge alone.

e.g.

[![Early Access](https://img.shields.io/badge/pantheon-EARLY_ACCESS-yellow?logo=pantheon&color=FFDC28&style=for-the-badge)](https://github.com/topics/early-access?q=org%3Apantheon-systems "Early access, no support save from the Engineering team")

[kporras07]

@greg-1-anderson should this be closed now?