openstack/governance
Code Issues Proposed changes
ae6d0272b7
governance/reference/dropping-projects.rst
Ghanshyam Mann 517390c66b Add more clarification on project retirement process 
As discussed in Victoria PTG, adding more clarification
on project retirement process on 1. Force merge the work
required for completing the retirement. 2. how to continue
development as non official project.

-https://etherpad.opendev.org/p/tc-victoria-ptg

Change-Id: Ia88f916ccc559636744959a373596eb8f29f0c86
2020-06-10 16:12:26 +00:00

4.6 KiB
Raw Blame History

Guidelines for dropping project teams from OpenStack governance

Dropping project teams is hard. There is no reason to remove low-activity but functional teams. And there are teams that cannot be dropped, even if dysfunctional. Here is a set of guidelines to help with that process.

Triggers

Triggers are events which may trigger an inquiry on the opportunity of dropping a specific project team. They are generally a sign that the team is struggling to continue to be part of the OpenStack release cycle requirements.

  • No PTL candidate during a PTL renewal

    This is generally a signal that there aren't enough people maintaining the project, or at least nobody willing to engage to be the default contact point and ambassador for a project. Alternatively, it may signal that the team is out of touch with the mailing-list and the release cycle and misses the window for self-nomination.

  • Missing RC1 signoff or triggering forced releases

    The release management team expects some confirmation from the PTL or their release liaison at critical points in the release cycle. In case such signoffs are not provided, the release management team forces releases, at the risk of producing non-functional deliverables. This is obviously not sustainable and a good sign of a dysfunctional project team.

  • Failure to communicate with community goal champions

    We set common goals at each cycle that bring more value if all project teams and OpenStack deliverables complete them. In some corner cases, teams are unable to complete the goal, and should communicate why to the goal champion(s). It is also expected that changes pushed by the goal champion(s) in support of the goal get reviewed in a reasonable timeframe. Failure to communicate at all with the goal champion(s) signals a dysfunctional team.

Criteria

Triggers alone are not a reason for removal. They just trigger an inquiry, which may result in proposing their removal, or actively looking for new volunteers to take over the project and/or adding the team to the upstream-investment-opportunities/index.

The criteria to evaluate how "critical" a project is is based on:

  • Usage

    If the user survey shows that the project is used in more than 5% of the deployments, it is necessary to continue the project to support those existing users that have invested in that technology, or at least provide a clear migration path to some alternative solution.

  • Dependency

    If the project is a dependency of other projects, it should also be continued in order to support that other project team. For example, we could not ever consider dropping Glance, as Nova depends on it. Dependencies are documented in the OpenStack Map (osf/openstack-map repository).

Process

Whenever a project generates one of the triggers, TC members may raise an inquiry. If the project is deemed critical, the TC should raise a public call for help and report to the Board to encourage more engagement in this area. However if the project is not deemed critical, calling for help can be counter-productive: it is very likely that a volunteer will step up to "save" the project, when that volunteer's energy could be better spent on more critical things. Therefore the TC should just start a thread about removing that project team from governance and future releases of OpenStack.

If project's existing or new team shows interest to continue the development under:

  • OpenStack governance then they need to update the TC on ML thread or IRC channel before retirement is approved.
  • OpenDev, please refer to the Continue Development section.

Once retirement is approved, the Technical Committee's decision overrides any objections of the project's contributors, so may involve deleting blocking votes on retirement changes. Any interested team members may continue the development as non-official OpenStack project.

Continue Development

With the OpenDev model, it is possible for the project to continue the development under different namespace than openstack/. Refer to the resolution ../resolutions/20190322-namespace-unofficial-projects. for OpenStack namespace criteria.

Refer to this document for the complete process to create the project under OpenDev.

Re-becoming Official OpenStack Project

Becoming an official OpenStack project again requires following the same criteria as new-projects-requirements.