Commit Lead

The Commit Leads are responsible for the quality one relevance of the content added to the GovStack specifications.

A Commit Lead does not necessarily need domain expertise to perform the role as that is given by the Technical Expert. Their expertise in necessary in looking at the overall picture of the content and how it is being changed. Does it meet our agreed Quality Criteria? Is the change helping us meet the overall goals of the project?

It is possible for a Commit Lead to also be a Technical Expert BUT Commit Leads should avoid committing work they have personally approved as a Technical Expert - every change should always have been reviewed by at least two people.

All Commit Leads are, of course Contributors and they CAN commit changes they have authored themselves IF a different person acts as a Technical Expert and gives approval. Again, all changes need at least two people to review.

Commit Leads are the only role that have commit access to the GitHub repositories that contain the specifications, and are able to merge Change Requests in GitBook.

Responsibilities

  • To always follow the GovStack Code of Conduct

  • To ensure the quality and relevance of all content contained in the GovStack specifications

  • To review and assess Tech-Expert-approved issues against the project’s Quality Criteria and, when meeting all the requirements, to commit that change to the Development spaces

  • To provide actionable feedback on issues that are not committed

  • To Collaborate with other Commit Leads and the Product Owner to make regular official releases of the specifications

Actions

The Commit Lead primary acts reactively to events in the Jira issue queues:

An issue has been positively assessed by a Technical Expert

The Commit Lead monitors the list of issues which have been targeted as positively reviewed by Technical Leads

For each issue:

  1. Review if the content of the change described in the issue meets the project’s Quality Criteria

  2. Consider if the change is a good fit with the overall intended direction of the project. This consideration might mean consulting with other Commit Leads and the Product Owner, possibly at the Product Committee meeting

  3. When satisfied, merge the associated Change Request or Pull Request

  4. Give thanks to those involved in the issue and close it.

Where the Commit Lead does not think that an issue contained all of the information necessary, or that the change it proposes does not meet the Quality Criteria and overall direction of the project, the Commit Lead needs to feedback to the other participants in the issue, via an issue comment, what might be necessary to make is acceptable. They also need to be ready to say “no” to some issues, but always with constructive criticism so that the Contributors involved are able to learn from the exercise and bring further acceptable issues.

Governance

Commit Leads are appointed by the Product Owner.

It is possible for the Product Owner to appoint a Commit Lead across all of the building blocks or to specific building blocks. It might be that a new building block has one or two Technical Experts and one or two Commit Leads so that they can work largely autonomously during early development of the building block’s specifications and then become more and more integrated into the wider team as the building block begins to be included in the release publication processes.

Why be a Commit Lead?

The Commit Leads are the “owners” of the specification, on behalf of the Product Owner. They are, therefore, absolutely central to the success of the project and are recognised as such.