Propose to manage project status

[loewenstein-sap]

Preview

[dmikusa]

I'd rather see the levels as some opaque term, so people don't read into the title and assume things. For example, Level 1, Level 2, Level 3 or Gold, Silver, Bronze. I know it's a little less friendly, cause you might need to look up what the levels mean but I think that will actually prevent people from making possibly incorrect assumptions about them.

I'd also prefer to have four levels, where 1-3 are similar to what you outlined and 4 is when a project has gone dormant. That way we can differentiate between a project that's been archived cause maybe it's no longer useful or relevant as opposed to projects that have gone dormant and could be useful but just don't have anyone to maintain them.

My thoughts on the individual levels:

Top tier - a.) two or more maintainers (possibly with a grace period to allow for transitions), b.) maintainers actively participating in RFC process c.) maintainers actively participating in cross-project work d.) maintainers are actively engaged with the community (slack, discussions) e.) there is an established release schedule and it's being followed

Second tier - a.) one or more maintainers, b.) maintainers are less involved (not meeting one of b.), c.) or d.) from top-level, c.) there's no established release schedule or release schedule is not being followed (i.e sporadic releases)

Third tier - a.) zero or one maintainer, b.) maintainer may be unresponsive or new and not yet involved (not meeting multiple of b.), c.) or d.) from top-level, c.) project is a new project and being bootstrapped, no 1.0 release yet. d.) no defined release schedule / no consistent releases

Fourth tier - a.) zero maintainers, b.) cannot guarantee state of the buildpack in terms of compatibility or security, c.) project does not recommend this buildpack be used in its present state.

IMO, first and second tiers are normal. The main difference is just the involvement of the maintainers.

The third tier is a transition tier, a buildpack may go there if it's been abandoned, like if the maintainers have left and we're hoping to get new maintainership. New buildpacks also start here and it's a place to grow. So it's kind of an incubator. Users can use these but it's a use at your own risk kind of situation.

I think there should be time limits for buildpacks that are in the third tier. There are maybe 12 months to find someone to become the maintainer or get a new buildpack going and get things up to tier 2 quality or the buildpack gets moved to tier four. No one is going to want to have a buildpack go to tier 4 status, but I think we need something objective as a trigger and time would be one way to accomplish that.

The fourth tier is just a placeholder for what happens when we can no longer maintain a buildpack. It goes here until there is sufficient interest and involvement to resurrect it. This is different from buildpacks that we've deprecated and removed, which means those are not coming back.

[loewenstein-sap]

I am fine with simple opaque terms like "Tier N" or "Nth Tier", but I'd avoid any mapping to derive quality - even Gold, Silver, Bronze (which is probably pretty universal) - for reasons like "green" traffic lights being blue in Japan and other potential for misunderstandings.

When it comes to describing the qualities of the different tiers, I would like to point out that there are two different perspectives on this.

1. What can users expect
2. What can Paketo maintainers expect

I don't think that we can afford the second tier from a maintainer perspective, unless we also define that only Tier 1 buildpacks can participate in the projects commons. I.e. only Tier 1 buildpacks get packaged into the maintained builders, only Tier 1 buildpacks "are allowed" to use libpak or packit, etc. Otherwise, the buildpacks not participating in RFCs and cross project work would block the cross project work.

[dmikusa]

I think we have to be careful with terms like maintenance and support, as to some readers that will (incorrectly) imply a contract. That the project has actual guarantees on things, when in fact everything we do is "best effort". This is part of what I'd mentioned above about readers assuming things, and I think using an opaque term for the different levels will help prevent any miscommunication here.

[mhdawson]

Maybe using the term "activity level" which reflects what's in the wording interms of how actively the buildpacks may be updated but does not imply any promised maintenance so maybe something like:

• Active
• Security updates only
• incubating, bootstrapping
• Inactive

[dmikusa]

I feel like this creates a marketing/branding problem for buildpacks that are generally stable and not getting feature work. By saying they're "security updates only", that comes off (to me) like they're about to go EOL. This is coming from a typical software lifecycle like for a language runtime or Linux distribution where "security updates only" is typically the last thing that happens before that version goes EOL. That's not an impression we want to give off.

I also think there are at least three different things that we're trying to describe/convey to users with this description and it is hard to do, which is why I like the idea of an opaque description. The three things that come to my mind, things I'd want to know as a user, are 1.) the release reliability, are we releasing this often? is it likely to get a release when I need it to? 2.) Is it getting security updates in a timely manner? Is someone watching & merging these? If something breaks with the automated process, is someone going to fix it? 3.) Are there active maintainers? Is someone looking at issues, engaging with the community, doing development, etc...

[mhdawson]

Thinking about it a bit more Tiers are used in the Node.js project as outlined in https://github.com/nodejs/node/blob/main/BUILDING.md#strategy. That is an example of where the use of Tiers has been successful used.

[loewenstein-sap]

So, let's go for Tier N then?