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.

[dmikusa]

Suggested change

	- What about the buildpacks that are not maintained anymore? Should we archive them or move them to the paketo-community organization?
	- What about the buildpacks that are not maintained anymore? Should we archive them or move them to the paketo-community organization?
	- What about paketo-community? Do we really need that if we have this tier system?

[dmikusa]

I'd be more in favor of getting rid of paketo-community and just moving any useful/maintained buildpacks into the corresponding tier in paketo-buildpacks. There's a bunch of overhead with paketo-community in terms of managing it, keeping GH teams in sync, keep secrets in sync, etc... and I don't feel like it has really achieved it's purpose, which is to attract folks to contribute community managed buildpacks.

[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