lifecycle.md

Extension Life cycle

This document describes the process of publishing extensions within the CiviCRM ecosystem.

Background

The CiviCRM ecosystem is built on the belief that non-profit organizations can serve themselves best by collaborating in development of their data-management applications. As staff, volunteers, and consultants for non-profit organizations, we can share our new enhancements and extensions — and build a richer whole for the entire ecosystem.

Of course, this collaboration means that we're all engaged in some give-and-take. We alternate between two roles:

• Consumers: Sometimes we're the receivers. We want to quickly browse the available extensions, pick the ones which look best, and install them. We expect the extensions to work — both now and going forward (with future upgrades).
• Developers: Sometimes we're the providers. We enjoy building great functionality, and want to invite people to use our products, but need to juggle the publishing tasks (like testing and maintenance releases) with the goals and resources provided by our bosses and clients.

With the extension life-cycle described here, we seek to build an ecosystem that balances the needs of both consumers and developers.

Definitions

Project Maturity

Should we expect this to work for most users? Should we expect it to work in 6 months?

Experimental

An experimental project offers zero support, stability, or maintenance. It may be useful for discussion, finding collaborators, or proving a concept.

Incubation

An incubation project offers some degree of support, stability, or maintenance. It's probably in use at multiple organizations. However, the levels are not guaranteed; some gaps and road bumps should be expected. A project may be "Incubation" for days or months or years.

Stable

A stable project has undertaken significant efforts to ensure that it works and continues working in the future. It has a strong quality-signal.

Deprecated

The project is no longer being maintained. It may work today; but it's liable to break tomorrow (unless someone steps up to manage it).

Stewardship

Who manages a project? Who decides whether the project is experimental? Or maintained? Or unmaintained?

Contributed

This project is managed by an individual or company in the ecosystem. All design, support, and maintenance are at discretion of the original author.

Official

The project is monitored as a community resource. Generally, the original author retains editorial control, but the project receives more strenuous reviews and follows stricter standards with feedback from others in the community.

Seeking Maintainer

This project does not have a person or organization responsible for it. If you think the project is useful, feel free to take responsibility for it.

Support Model

How do you submit questions and requests about issues?

Free

Submit questions and requests to an open bug-tracker.

Negotiated

Issues may be reported to open bug-tracker. If the author agrees it is critical or data-loss, they may address it. Otherwise, you need to negotiate a contract.

Pre-Paid

The author will not engage in any support discussions unless you have pre-paid for support.

Quality Signals

How do we know if an extension is any good?

Self-Assessment

An author makes a claim about the stability of their work. (This is a low-tech, low-touch process.)

Informal Discussion

One or more experts give gut reactions. (This is a low-tech, high-touch process.)

Formal Review

One or more experts assesses the quality, maintainability, best-practices, etc. using formal criteria. (This is a low-tech, high-touch process.)

Social Metrics

Data-points (such as #installations or average 5-star rating) is collected from many people. (This is a high-tech, low-touch process.)

Technical Metrics

Technical details (such as test-coverage, test-results, style-checks, or cyclomatic complexity) are checked by a bot. (This is a high-tech, low-touch process.)

Workflow

The database on civicrm.org publishes information about available extensions, including maturity and stewardship. This is significant because it affects authors (who publish the extension) and users (who download the extension) and determines access to communal resources on civicrm.org. The particulars are determined the maturity and stewardship of the project -- with a few basic rules of thumb:

• The author always registers their extension on civicrm.org by creating an extension node.
• Official extensions are subject to more scrutiny than Contributed extensions.
• Experimental, Incubation, and Deprecated extensions have simple, open processes -- such as Self-Assessment or Informal Discussion.
• Stable extensions require some kind of Formal Review.

Based on these rules, we can fill out a full table of the workflow:

Maturity	Stewardship	Primary Quality Signal	How does an author get their extension designated as X?	How does a user download an extension with X designation?
Experimental	Contributed	Self-Assessment	In civicrm.org, the author creates an "extension" node and flags it as "Experimental".	Locate the extension on the website. View a block which says, "Install Instructions", which includes drush/wp-cli commands.
Experimental	Official	Informal Discussion	As above. Additionally The author announces to a high-visibility medium (such as blog or mailing-list). If discussion is persuasive, a senior member of core team flags the project as official.	Locate the extension on the website. View a block which says, "Install Instructions", which includes drush/wp-cli commands.
Incubation	Contributed	Self-Assessment	In civicrm.org, the author creates an "extension" node and flags it as "Incubation".	Locate the extension on the website. View a block which says, "Install Instructions", which includes drush/wp-cli commands.
Incubation	Official	Informal Discussion	As above. Additionally The author announces to a high-visibility medium (such as blog or mailing-list). If discussion is persuasive, a senior member of core team flags the project as official.	Locate the extension on the website. View a block which says, "Install Instructions", which includes drush/wp-cli commands.
Stable	Contributed	Formal Review (light)	In JIRA, the author requests a formal peer review. Once the reviewer is satisfied, they mark the node in civicrm.org as Stable.	In app, go to "Add New" and choose the extension.
Stable	Official	Formal Review (heavy)	As above. Additionally FormalReview criteria are more detailed. Announce to a high-visibility medium. At least one reviewer must be a senior member of the core team.	In app, go to "Add New" and choose the extension.
Deprecated	Contributed	Self-Assessment	In civicrm.org, the author marks the "extension" node as deprecated and announce to a high-visibility medium.	Locate the extension on the website. View a block which says, "Install Instructions", which includes drush/wp-cli commands.
Deprecated	Official	Informal Discussion	The author announces intent to deprecate in a high-visibility medium. If discussion is persuasive and no alternative maintainer comes forward, a senior member of core team flags the project as official.	Locate the extension on the website. View a block which says, "Install Instructions", which includes drush/wp-cli commands.

Formal Review Process {:#formal-review}

Extensions must pass a Formal Review to become designated as Stable and made available for automated distribution through CiviCRM's in-app Extension management screen.

The review process assess several criteria, and as a rule of thumb, Contributed extensions are subject to a gentler review (fewer criteria), and Official extensions are subject to more stringent review (more criteria).

Who can review?

• Contributed extensions must be reviewed by at least one peer/contributor.
• Official extensions must be reviewed by at least one senior member of core team.