Introduction

Document projects have a linear lifecycle. In other words, they move through each of the lifecycle stages in sequential order.

These stages are:

When a document project begins its goal will be to move to the Published stage.

• Introduction
• 1. Pre-Draft
• How to submit a proposal:
• Proposal-writing tips and tricks:
• Moving to the next stage
• Approval criteria
• Approval process
• 2. Draft
• Features of a Draft document project
• Benefits of a Draft document project
• Moving to the next stage
• Approval criteria
• Approval process
• 3. Approved
• Features of an Approved document project
• Moving to the next stage
• Ratification criteria
• Ratification process
• 4. Ratified
• Features of a Ratified document project
• Benefits of a Ratified document project
• Moving to the next stage
• 5. Published
• Publication process
• Benefits of a Published document project
• Moving to the next stage
• Approval process
• 6. Historic
• Features of a Historic document project

1. Pre-Draft

How to submit a proposal:

Any GSF member can submit a proposal.

It should be submitted to a Working Group using the New Project Proposal issue template.

Moving to the next stage

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.

2. Draft

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

3. Approved

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

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

4. Ratified

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

Publication process

1. Once the project has been ratified, the Working Group merges the Dev branch into Main.
2. The Working Group collaborates with the GSF Communications team to publish and promote the document project.
3. 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

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).

6. Historic

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.