Document Project Lifecycle

As above, any document idea can be proposed to a Working Group for consensus approval. We have low barriers to entry at this stage: a proposal will be refined over the project’s lifecycle into something truly awesome and impactful.

‣

Approval criteria

‣

Approval process

2. Draft

📝

The project is in its iterative stage: it is being explored by the project team.

Features of a Draft document project

Drafts are the starting point for all future work. Therefore:

They must be publicly accessible in a designated repository
The landing page of the repo should direct users to the Dev feature branch
The repo must contain the following disclaimer at the top of the README file and all other public-facing documentation:

[!important] Draft Project: This is a draft document only and has not been approved or adopted by the Green Software Foundation. This draft may not be relied upon for any purpose other than review of the current state of development.

Benefits of a Draft document project

When a project is in Draft, it is considered an official GSF project. This means it gets the resources it requires to move through the remainder of the lifecycle, including:

Marketing support from GSF, including:

being listed on the GSF website and in our newsletter updates;
the opportunity to participate in GSF events; and
shout-outs and connections via social media.

Mentorship in areas such as, but not limited to:

project management;
governance;
legal;
tooling;
security best practices; and
documentation.

The opportunity to influence and shape a GSF project deliverables.

Moving to the next stage

✅

Approving body: Working Group

‣

Approval criteria

‣

Approval process

3. Approved

📝

The project has been approved by the Working Group as it is deemed to have met its objectives.

Features of an Approved document project

Approved projects are well on their way to publication, and are ready to be passed to the Steering Committee for ratification. There should not be any changes to the document at this stage.

Moving to the next stage

✅

Approving body: Steering Committee

Ratification is legally required as it bounds the GSF Member Organisations to the legal framework defined in the GSF Bylaws (GSF Charter)

‣

Ratification criteria

‣

Ratification process

4. Ratified

📝

Once the document has been ratified by the GSF Steering Committee, the publication process is triggered.

Features of a Ratified document project

Ratified documents are officially approved by the Steering Committee, and carry the support of the GSF. Therefore, the repo must contain the following disclaimer at the top of the README file and all other public-facing documentation:

[!important] Ratified Project This project is a Ratified Document Project, supported by the Green Software Foundation. The publicly available version documented in the README is trusted by the GSF. It may move to the Historic Stage at any moment.

Benefits of a Ratified document project

Ratified document projects:

Can be published by the GSF;
Have the backing of the GSF’s Steering Committee;
Receive a formal announcement of ratification to GSF members;
Receive marketing support to celebrate the ratification of the document;
Replace the ‘Draft’ disclaimer with one that shows it is a trusted project supported by the GSF

Moving to the next stage

There are no approval criteria for moving to publication from ratification.

The Steering Committee’s ratification of the document automatically approves publication. At any point after ratification, the document can be made publicly available.

5. Published

📝

The document is made publicly available.

Publication process

Once the project has been ratified, the Working Group merges the Dev branch into Main.
The Working Group collaborates with the GSF Communications team to publish and promote the document project.
The GSF gathers public feedback

Benefits of a Published document project

When a document is published, it has the support of the GSF Communications team. This means that it will be promoted and shared across the GSF's platforms and networks for maximum visibility and impact.

Moving to the next stage

✅

Approving bodies: Working Group and Steering Committee

Though Published is the goal stage for all document projects, sometimes they will move to a final stage: Historic. This stage is used when the document is no longer relevant (for example, because the technology it defines has become obsolete).

‣

Approval process

6. Historic

📝

The document is archived, though it remains publicly accessible.

Features of a Historic document project

If a project is in this stage, the document is deemed no longer relevant (for example, because the technology it defines has become obsolete). These projects:

Have archived their repositories. All branches except for Main have been removed.
Cannot change from the Historic stage into another.

If a member wishes to resurrect the project in some form, they must submit a new proposal and make reference to it there.

Must contain the following disclaimer at the top of the README file and all other public-facing documentation:

[!important] Historic Document Project This project is historic and is no longer being run inside the Green Software Foundation. Documents are *NOT* maintained or improved. This project cannot be reactivated.