Scope and Overall Principles

Owned by Rachel Lawson (Unlicensed)
Last updated: Oct 16, 2023
4 min read

The governance, roles and processes we apply to various parts of the project need to be appropriate for each part of the project and reflect the type of work taking place.

Scope

The processes and roles described here apply to all changes made to the Specifications document, normally published at https://govstack.gitbook.io. This includes development of new content, changes to existing content, and removal of content no longer required.

All work on the Use-Cases is NOT in scope, as they implement their own processes and roles as most appropriate for gathering use-case information in countries partners are working in,

Overall Principles

To ensure that the GovStack project is able to ensure the quality of the materials published in the specifications, understand the history of how decisions were made regarding the content, manage differences of opinion, ensure that each section of the specification is consistent with the overall direction, and give due recognition for contributions made, the following overall principles apply:

All are welcome

We welcome all to collaborate on the GovStack specifications. Knowledge of how we may improve the specifications, not just from a technical perspective but also one of readability and ease of understanding, exists in people from a wide variety of backgrounds. We must engage with them all to create the best specifications.

Work always begins with a Jira issue

To ensure that we are ultimately able to:

  1. Give due recognition to those who contribute to the specification

  2. Ensure high quality of the specification by making the decision process visible and accessible

  3. Enable calculation of “prolific Contributors” (both individual and organisation) and reward their contribution with priority access to contracted opportunities

  4. Properly support the initial contributions of new contributors

we always start work with a Jira issue in a building block project. That issue must describe a proposal for a change and give a small justification for it to be made. A change could be something as simple as a grammar improvement or something as complex as a new section in a specification. The starting point is the same — make the issue.

Work is always collaborative

Whilst it may sometimes seem faster to “work alone”, the best work, that of the highest quality, is always made when people collaborate together. Indeed, when we consider the need to all move towards a cohesive result, working together is often more efficient.

No changes should be made to the specifications by a single person. There should always be one person proposing a change and a different person approving that change. We reduce errors this way, whilst also spreading understanding as we each have to justify our thoughts to each other.

We primarily judge the contribution, not the Contributor

In a volunteer contributor community, it is important to remember that anyone can have a great idea. When a Contributor proposes a change, via a Jira issue, those processing the issue (such as the Triage Lead and the the Technical Expert) should judge the proposed change based primarily upon the proposal rather than simply on the reputation of the Contributor.

This principle must be balanced by the fact that we value the expertise of our domain experts and we should always value their opinion, mostly by engaging with them as Technical Experts, but w e should also be sure to “check the working” of all Contributors against our Quality Criteria and other experts in the field.

Every contribution has value, even if not accepted

Always work on the principle that, even if the proposed change is inappropriate at this time, the feedback we give, via comments on the Jira issue, can help spread that mutual understanding of GovStack and help the Contributor to adjust their proposal and/or make great contributions in future. Good feedback to Contributors can be one of our most effective marketing tools.

We work to a mutually agreed quality standard

We want a Contributor community to propose changes to the specification that are appropriate and meet our quality standards so we must publish them here in this process and then use them to feedback to contributors via the Triage Lead and Technical Experts. When giving feedback, people should refer to the quality standards so they can see how they can improve the proposal.

Keep our issue management system as simple as possible

Under our old working group working practices, we have a relatively complex workflow for issues and this is large barrier to entry for new Contributors. As the new model is event driven rather than time driven, we can remove the sprints etc and issues have a simple workflow of Open (the default status of a new issue), For Review (somebody needs to review it - probably a Tech Expert or a Commit Lead), Needs Work (because a reviewer has left comments), and Closed.

The old working group model transforms into this model

Working Groups, meeting weekly to work on specific building blocks, will still use this new model but the Technical Committee will appoint a Technical Expert and the Product Owner will appoint a Commit Lead that work on those building blocks. The Product Owner holds Commit Leads responsible for changes meeting the Quality Criteria.

The working group may continue to meet on a regular basis. Indeed, they are encouraged to do so, but they still follow the model outlined here with regard to documenting everything in issues and always ensuring that every change has at least two people working on it - and documenting they have done so in the issue.

This is essential so that we can monitor the progress that the working groups are making.