Add Responsible End Of Life & Archiving Policies

[bensternthal]

This PR:

1. Refactors Emeritus stage into End Of Life & Archived
2. Details Annual Review Process

Much thanks to @rginn @PaulaPaul @UlisesGascon and others that contributed to this work.

Fixes #1185

[mcollina]

lgtm

[ovflowd]

LGTM! Left a few comments

[tobie]

Thanks for getting this started! This is a great step forward. I think we should take the opportunity to clean-up the language and be careful not to introduce new notions. For example, there's now onboarding, incubation, and graduation that kind of describe overlapping phases.

I'm going to reiterate my request to include a state diagram in this doc so that the whole process and lifecycle is easier to follow for everyone involved, e.g.:

stateDiagram-v2
    direction LR
    [*] --> Application
    Application --> Incubating
    Application --> [*]
    Incubating --> [*]
    Incubating --> Active
    state Active {
        AL : At Large
        Impact --> AL
        AL --> Impact
    }
    Active --> EoL
    EoL --> Active
    EoL --> Archive

Loading

It would also be good if the different states where presented in order, and active was defined (as either At Large or Impact), as its used in the bylaws.

Finally, I think I agree with @ovflowd suggestion to split the checklists out. Should we merge back the project-status repo into this one while we're at it or do we want to continue keeping it as a separate repo?

[bensternthal]

@tobie Hmm we did not introduce new notions (at least I do not think so): onboarding, incubation, and graduation exist in the current doc and we did not adjust those as part of this work. Maybe I am not understanding.

If we do want to change those stages, I'd suggest doing that in a different PR, I'd like to keep this one atomic to updating Emeritus.

+1 to a wireframe, I do love a good wireframe

+1 to moving the checklists out, I'd prefer to have those in this repo but can defer to the community.

[tobie]

@tobie Hmm we did not introduce new notions (at least I do not think so): onboarding, incubation, and graduation exist in the current doc and we did not adjust those as part of this work. Maybe I am not understanding.
If we do want to change those stages, I'd suggest doing that in a different PR, I'd like to keep this one atomic to updating Emeritus.

Oof. My bad. The way the PR is formatted made it look this way. You're right. Entirely fine to move this to a separate PR.

Can we add a diagram to this one and make sure we agree on fundamentals of these new stages? I share @eemeli's confusion about the shapes of the different stages (as I had already mentioned in the original Google doc), and remain unsure whether they refer to periods or discrete events (milestones).

[tobie]

+1 to moving the checklists out, I'd prefer to have those in this repo but can defer to the community.

If you're suggesting we merge back project-status into this repo, I'm all for it. We should absolutely do that imho.

[tobie]

I remain confused with the different stages.

I think there are two problems:

1. "End of Life" is usually understood as a milestone (see for example how Node talks about it: https://github.com/nodejs/release#release-schedule), but it's being used as a period of time here. I think this is confusing. We should adopt the term "maintenance" instead.
2. There's confusion as to what exactly the EoL (or maintenance) period entails as it says both that the software receives and doesn't receive patches during that time. Here's how I think this would make sense:

Stage	Feature development	Security patching
Active (At Large/Impact)	✅	✅
Maintenance (currently called EoL)	❌	✅
Archived	❌	❌

[ljharb]

in that case, i'd call "Archived" "EOL" instead, since "archived" is just a repo status, but EOL is the project status.

[bensternthal]

Added the wireframe and made some tweaks based on suggestions. Regarding the names for phases, I suggest we keep End Of Life and Archived (see updates) for the following reasons:

1. Maintenance does not imply or communicate a date when maintenance would end, if projects are receiving ongoing security updates and there is no plan to cease updates, then I would say this project is Active.
2. End Of Life projects are expected to have a date when updates would cease. I think it's important to have a stage that clearly communicates, "we are making updates now but we wont after x date."
3. Archived I think is very clear in communicating, you can see the code but no one is working on it. EOL to me still implies folks are working on it and that at some point in the future, they won't be.

[eemeli]

Added the wireframe and made some tweaks based on suggestions. Regarding the names for phases, I suggest we keep End Of Life and Archived (see updates) for the following reasons:

1. Maintenance does not imply or communicate a date when maintenance would end, if projects are receiving ongoing security updates and there is no plan to cease updates, then I would say this project is Active.

I do not think this matches the practical reality of jQuery UI and Sizzle, two of our five emeritus projects. They are quite explicitly in "maintenance only" mode, and have not announced any set end date for that. I do not think calling these projects "active" is useful, and splitting up our current project categorization in such a way that none is appropriate for them is not a good change.

As I'm not a contributor myself to these, input from @mgol, @timmywil and/or @Krinkle would be useful here.

2. End Of Life projects are expected to have a date when updates would cease. I think it's important to have a stage that clearly communicates, "we are making updates now but we wont after x date."

Why? What is the benefit of communicating such a decision through foundation staging? And why must an end date be included in a decision for a project to go "maintenance only"?

[timmywil]

Indeed, UI does not fit either description, and we do not plan on setting an end date. That depends on usage, which we can't really know right now. I consider "maintenance only" to mean that they do receive some important fixes (although worth noting not all of them are security related), but I'd say the projects are also far from "Active" and not really EOL either.

Edit: actually, we do plan to archive Sizzle soon. I don't have an exact date, but the plan is to archive Sizzle when we release jQuery 4.0 final. But we have 4.0 beta.2 and rc before we get that far.

[bensternthal]

Interesting! looping in @PaulaPaul and @UlisesGascon for their thoughts (we worked together on the initial revision).

[mgol]

Adding to what Timmy wrote: allowing only security fixes is a pretty limiting factor. In the jQuery UI case, even if we limited current changes as much as possible, we'd still want to maintain support for new jQuery releases which is a jQuery UI dependency and that goes beyond security fixes.

But I would definitely not call jQuery UI support "active". Most feature requests are declined, bugs that existed before the 1.12.x version (the current one is 1.13.2) are generally left for the community to figure out and mostly not acted upon, etc.

[tobie]

Agree with the points mentioned above. We absolutely need a stage that says: “This project is complete. If there’s a security issue or a really bad bug, it’ll be fixed, but we won’t be adding any new features.”

I don’t think we need to police exactly what goes into maintenance mode and what doesn’t. The idea is for a project to be able to clearly express a shift in priorities and focus.

I also don’t think that we need a different stage name once EoL had been announced and until EoL is reached. It’s still maintenance during that time.

[eemeli]

Agreed with @tobie. Also, "Complete" would be a really good stage name.

[tobie]

I like “complete” (or even “feature complete”) as a stage name. It changes the framing quite a bit.

[UlisesGascon]

I agree with the latest comments; it seems like we need to include the option for solving bugs and not just security-related ones.

Also, I guess that maybe not all projects will continue bug fixing in the complete state, and this will depend on the maintainers' decision. It's also possible to allow bug fixing for minor issues, not necessarily critical ones.

I believe the big difference from active to complete is that there is no plan to add more features or at least significant features in the near future.

So I guess the table will look like this:

Stage	Feature Development	Bug Fixing	Security Patching
Active (At Large/Impact)	✅	✅	✅
Complete (currently called EoL)	❌	✅/❌	✅
Archived	❌	❌	❌

Note: feel free to suggest a single emoji replacement for ✅/❌

On the other hand, when checking the current Project Lifecycle, I assume that the complete status is not reversible, so I guess that this can be quite limiting to the projects. As one of the reasons to end up in this state can be maintainer exhaustion, that situation can change if new team/members want to take leadership of the project again.

Saying that, I have another question regarding governance:

In cases where the project maintainers aren't responding after having been repeatedly contacted through appropriate channels about the CPC's intent to move the project to the End of Life stage, the CPC may proceed with the stage change to either End of Life or Archived without approval from the maintainers.

So, here it is very clear that the decision to change the state can be made by the CPC in a very specific case, but I will remark that the CPC should put the mechanism in place to ensure that at least security patching is done. So if the project has a critical security vulnerability, we are capable of patching it even if the project maintainers aren't addressing them. That way, we can provide a certain amount of time (6-12 months?) for users to migrate to a different solution that is more maintained before the projects end up as Archived. Not sure if I am going off-topic with this last question.

[tobie]

"Complete/Feature-complete" stage is explicitly reversible.

We can simplify your table like so:

Stage	New feature development	Vulnerability & bug fixes
Active (At Large/Impact)	✅	✅
"Complete/Feature-complete" (currently called EoL)	❌	✅
"Archived/EoL"	❌	❌

BTW, once we land on something we're happy with this table, I think adding it to the doc itself would be really useful. It's a great tool to understand what the different stages are about and help maintainers make decisions about where their project belongs.

Also, we might want to give the option for new projects to join the foundation as "complete." In practice, this happens already. It would allow us to not be trying to guess whether that's the case or not. It could also be combined with a request for resource commitment from the organization bringing such projects in until EoL.

[bensternthal]

Folks, I did my best to integrate everyone's suggestions and feedback. I think if @tobie and @eemeli approve, we can merge.

[Krinkle]

I believe these two suggestions were neither applied nor explicitly dismissed:

1. Allow new projects to apply to join in the Complete state.

Perhaps this would fit under the Incubating section where we currently say "Projects in this phase may be looking to join the foundation as At-Large or Impact Stage." which could instead read "Projects in this phase may be looking to join the foundation as At-Large, Impact, or Complete Stage."

2. Allow projects to go from Complete back to Active.

I would propose for the text to describe the same criteria in both directions, e.g. maintainer and CPC approval. With the chart also showing an arrow in both directions.

Both of these seem valuable to have in my opinion, but I'm open to understanding why we might prefer not to apply these.

[bensternthal]

@Krinkle I think I have addressed your concerns/comments.

I think this is an outdated change request, if not we can do a PR to fix anything I missed.