tiers to classify projects

[UlisesGascon]

As discusses in our last meeting https://github.com/onebeyond/maintainers/issues/69, it will nice to define some tiers to classify our projects easier.

Tiers

Tier 0: Incubate

The idea is to group here all the new projects, some criteria to that apply to this projects:

• The project was created in the last 12 months
• The project did't released v1.0.0 yet
• The project is not yet following all the guidelines from the org (code, automations, metafiles...)

Some examples: onebeyond/onebeyond-studio-email-providers, onebeyond/onebeyond-studio-file-storage, onebeyond/onebeyond-studio-obelisk, onebeyond/cuckoojs, onebeyond/shieldjs

Tier 1: Active

The idea is to group here all projects that are growing, some criteria to that apply to this projects:

• The project is under active development including business logic evolution (at least one release in the last year).
• The project has a roadmap

Some examples: onebeyond/maintainers, onebeyond/systemic-azure-bus, onebeyond/swagger-endpoint-validator, onebeyond/license-checker

Tier 2: Maintenance

The idea is to group here all the consolidated projects that our community relays on but does not require any active development in terms of business logic, some criteria to that apply to this projects:

• The project is done in terms of business logic but is actively used by the community, so the project is mostly updating dependencies and fixing minor bugs.
• The project has completed the roadmap

Some examples: onebeyond/error-handler-module, onebeyond/make-manifest, onebeyond/systemic, onebeyond/prepper, onebeyond/handy-postgres, onebeyond/systemic-redis, onebeyond/systemic-express

Tier 3: End Of Life

• The project is considered completed and is not actively used by the community.
• The project has not done any release in the last 3 years.

Some examples: onebeyond/systemic-github-api, onebeyond/systemic-mssql, onebeyond/systemic-domain-runner, onebeyond/systemic-mysql

How this classification will affect us?

First of all, the criteria used per tier are not strict, the final decision is made by us as a group and not only by technical criterias. As well some projects are hard to classify like awesome-*

• Tier 0 will require a lot of support from the @onebeyond/maintainers team in order to consolidate the project in our Open Source culture, IT resources, guidance...
• Tier 1 will require active monitoring from the @onebeyond/maintainers and the code owners for security patching, code review priority...
• Tier 2 will require some work from the code owners peer year to keep up with the dependencies, etc...
• Tier 3 will require some work from the @onebeyond/maintainers to deprecate the libraries, remove IT resources and archive the projects.

When and who decided the project tier?

The initial step will be to create a PR with the first draft proposal for all the projects that we maintain, in that list all the projects are going to be classified by tier and then we can discuss (@onebeyond/maintainers and Codeowners) case by case.

Once the list is available, any code owner or @onebeyond/maintainers can create a PR to change any project tier at any time, that will be discussed in the the PR or in the maintainers meeting if needed.

Next steps

If we have a basic agreement on this tiers/requirements, I will create a PR to this repo with a draft classification so we can have a discussion on individual cases.

[inigomarquinez]

@UlisesGascon , I really like the classification you propose and for me it makes totally sense this group of tiers.

[carpasse]

👍 I also think they make totally sense.