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.
Proposal-writing tips and tricks:
A proposal must:
- Have a clear description
- Have a well-defined scope
- Identify committed resources
- Identify initial maintainers
- Be vendor-neutral
- Have identified any risks
- Describe what success looks like
- Know its audience/community
A proposal must not:
- Overlap with any existing standards or specifications.
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.
Approval criteria
To move to the next stage, the proposed project must:
- Have an assigned GSF PM
- Have at least three representatives from different member organizations of the GSF.
- As the project moves through its lifecycle, these representatives will attend the Working Group and champion the project, volunteer to lead it, and provide updates.
- We require at least three representatives to help ensure that the project runs smoothly and progresses towards its goals.
The project’s name must:
- Have the approval of the GSF Marketing team
- Not be trademarked
Approval process
- Proposal template is submitted by GSF member to the Working Group.
- Working Group gives consensus approval.
- Assigned GSF PM submits an issue to the Working Group Chairs repo for awareness. The Working Group Chairs have 2 weeks to comment / object.
- If a proposal is deemed by the Working Group or Working Group Chairs to be high risk (e.g. there is reputational, financial, legal, or greenwashing risk), it must also be reviewed by the Steering Committee and the Executive Director.
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
Approval criteria
In addition to the criteria it met to move into this Draft stage, the project must have:
- Met its scope
- An active set of contributing members from at least three member organizations
- A public GitHub repo with clear project documentation that sets out:
- the project overview (README)
- how to contribute (contributing.md)
- end-user guide (enablement.md)
- GSF processes, including:
- a project team mailing list
- the provision of regular updates to the Working Group
- defined OKRs agreed by the assigned GSF PM
Approval process
The project runs through a consistency review in order to transition from Draft to Approved. This is a final chance for the entire Working Group to review the deliverable.
- Review period opens: Members of the Working Group have 14 days to review and comment on the project.
- Review period closes: Since the Working Group operates by consensus, if there are no comments the submission will be approved automatically. However, if any comments were made, the project team addresses them at this point. The Working Group must then agree that the comments have been addressed.
- Approval: Once consensus is reached, the document is approved. If there are sustained objections, the chairs may carry on trying to reach a consensus or a vote can be held to move the project forward.
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)
Ratification criteria
The project has:
- An existing, versioned deliverable.
- Passed the Working Group’s consistency review and approval.
- Clear reference to the licence under which the document is being made available (see the GSF Charter for more information).
- If this project necessitates changes to the Charter, there will be a Review and Approval period where all Org leads will be invited to submit comments.
Ratification process
- The project leads present the document to the Steering Committee for ratification
- The Steering Committee passes the ratification motion
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
- 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
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
- Project team notifies GSF PM that they wish to moe the document to Historic status
- The Project Lead or Project Manager requests approval from the Working Group and Steering Committee to move to Historic status.
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.