Something to signal the level of maturity of tools is needed

sodero commented 4 years ago

Description

Something to signal the level of maturity of tools is needed. As it is now we have a mix of (more or less) abandoned repositories, experimental code and production grade code.

Motivation

Without this distinction it's more difficult than it should be for newcomers to get started. The overall impression of Eiffel suffers.

Exemplification

When deploying RemRem we ran into a number of unexpected problems. Refer to the issues filed in eiffel-remrem-generate and eiffel-remrem-publish.

Benefits

Having information about the status of projects upfront makes it easier for potential users to estimate the effort needed for deployment.

Possible Drawbacks

If we're not careful it might give the wrong impression and make users hesitant to try out, and contribute to, the development of new tools.

sodero commented 4 years ago

Perhaps some form of badge can be used, e.g https://shields.io/

k-hallen-ericsson commented 4 years ago

In the summit we also mentioned life cycle state. Can be mature and ok for production but not maintained anymore. Should we have that dimension too?

sodero commented 4 years ago

I think that dimension could do more harm than good. If people deploy something that is production ready, which is what we want of course, then the 'not maintained' label might lower the chances for contributions to that project. I'm afraid it will evoke very negative connotations.

I think we should distinguish between projects that aren't maintained, but we would like them to be, and projects that aren't maintained and we don't expect (or even want / care) them to ever be maintained again. I don't think it's a good idea with a 'not maintained' label for the first category. Instead of a label for projects in the second category, I think we should consider removing them instead.

k-hallen-ericsson commented 4 years ago

Good point. So focus should be more a scale from experiment/proof of concept to ready for large scale production. @fdegir you had some ideas on existing models that we could use?

fdegir commented 4 years ago

I'm sharing some of the examples from the foundations and communities followed by my thoughts.

Cloud Native Computing Foundation (CNCF): 3 maturity levels are used to highlight the maturity levels of the projects; Sandbox, Incubating, and Graduated. [0] Entering the foundation or moving between different levels are decided by the Technical Oversight Committee (TOC) with the input from Special Interest Groups (SIG).
Continous Delivery Foundation (CDF): Similar to CNCF, 3 levels are used but simpler than CNCF; incubation, graduated, and emeritus (archived). TOC has the responsibility to evaluate projects. [1]
OpenStack Foundation (OSF): The model followed by OSF is even simpler with 2 levels; pilot, confirmed. [2]

I think there needs to be at least 3 stages to highlight important aspects for the projects with associated badges.

sandbox: This is a good term which can be understood by anyone looking at the project and realize that the project at this level is at the very early stage of its lifecycle, perhaps some experimental work is happening. However that may not always be the case since some projects may be more mature than just being experimental perhaps due to a company open sourcing what they used internally but still they start their life in sandbox stage and then perhaps move to the next one quickly.
incubation: This stage is where the active and none-experimental projects could live their lives as they are actively developed and used or (on their way to be used) for more than just experimentation.
archived: This is also a good stage to put inactive/dormant projects in to highlight that the project at this stage perhaps has none to little activity going on.

Having another stage after incubation (such as graduated) does not seem to be necessary at this point but it can be added later on if deemed necessary.

Another point I want to highlight is about the actual process projects and the community need to follow while proposing a new project or moving across stages. For sandbox, it is simple; the bar to entry could be very low with few points such as

project description: what the project aims to achieve, who will be initial maintainers, and how many, operational requirements/needs from Eiffel community (repos, maillist, etc)
dependencies: any dependencies to existing projects.
any overlap between what is proposed and what actually exists: to ensure the individuals proposing the project looked at the existing projects and could join to the one if it is more valuable

When it comes to moving from Sandbox to Incubation. This could be simple as well but I've noticed it could become tricky as some of the requirements included by other communities could be subjective in some cases. To avoid that, there could be few metrics that could help projects to apply for incubation and get reviewed and promoted.

no of active contributors: must be > X
no of companies contributing to the project: must be > Y
number of releases: must be >Z

and so on.

The archived stage is also simple. If the project lead/maintainers think they don't have time and interest to continue with the project, they could first announce this intention on public maillist to see if anyone wants to take over and continue with the project. After certain amount of time (2 weeks eg) if noone steps up, the "committe" can move the project to archived stage.

[0] https://github.com/cncf/toc/tree/master/process#ii-stages---definitions--expectations [1] https://github.com/cdfoundation/toc/blob/master/PROJECT_LIFECYCLE.md#iii-stages---definitions--expectations [2] https://wiki.openstack.org/wiki/Governance/Foundation/OSFProjectConfirmationGuidelines

sodero commented 4 years ago

I think the suggestion of @fdegir is a good one. Don't we need graduated already though? Where would production grade projects that are actively developed end up?

k-hallen-ericsson commented 4 years ago

Let's start from Fatih's proposal. What is most important for us, is it to make the distinction between "we do not give any guarantee that this works" and "we are quite happy with this and it should work fine if you follow the documentation"? Then I think we should start with something simple and not to many stages. Could incubation be graduated instead? If we get more project and activity and we see a need for a middle step we can introduce it.

sodero commented 4 years ago

Agree, renaming incubation to graduated would make this a lot clearer to me. Otherwise I think Fatihs proposal is good.

fdegir commented 4 years ago

ok so i can start a document by copying one of the other communities document and include these three stages

sandbox
graduated
archived

there could be some additional paragraphs to list criterias for moving between different stages so people can comment on them + who does this - eiffel-community-maintainers.

fdegir commented 4 years ago

This issue is partly duplicate of this one: https://github.com/eiffel-community/community/issues/5

fdegir commented 4 years ago

As you've seen, the PR documenting project lifecycle has been merged: https://github.com/eiffel-community/community/pull/48

I generated the badges below on shields.io as a proposal.

Sandbox: https://img.shields.io/badge/Stage-Sandbox-yellow
Graduated: https://img.shields.io/badge/Stage-Graduated-green
Archived: https://img.shields.io/badge/Stage-Archived-orange

Please let me know what you think since the next thing to do is to identify list of Eiffel projects and set their stages - probably all of them will be in sandbox to start with. In addition to that, the Eiffel repository template could be updated to include Sandbox badge by default.

sodero commented 4 years ago

Looks good.

fredjn commented 4 years ago

+1

fdegir commented 3 years ago

thanks for trying this out @t-persson!

@eiffel-community/eiffel-community-maintainers please look at the proposed badges and share your +1/-1 if you haven't done it already.

Sandbox: https://img.shields.io/badge/Stage-Sandbox-yellow

Graduated: https://img.shields.io/badge/Stage-Graduated-green

Archived: https://img.shields.io/badge/Stage-Archived-orange

you can also check the updates @t-persson made to etos and other repos to see how it looks.

we will update the project lifecycle with the usage instructions, ask projects to apply badges, and modify the repository template so new repos get sandbox badge by default.