GovStack on a Shoestring

Providing essential GovStack specifications development without significant resources

The GovStack project is made up of many parts, each of which envelops at its own pace as needed. Those parts, such as the specifications, the compliance testing systems, and country engagement, go through periods of high and low intensity development.

Proposal

We have recently undergone a high intensity period of development on the specifications, to reach the release of version 1.0. Maybe now the intensity of development in the specifications can be allowed to find its natural level of intensity whilst we concentrate our development resources elsewhere? Here is a proposal for how we do this.

Separate the role of BB Lead into Triage Lead and Tech Lead

We currently employ BB leads on the basis that they are the key writer of a building block specification but, now that we have the basic block in place, do we really need to continue this model?

To better manage the contribution of those other than paid individuals, be they volunteer individuals or organisations volunteering staff, we should reorganise so that we separate the role of BB lead into two parts, that of a Triage Lead whose primary responsibility is to welcome contribution by others, organise and support their work, bring in the expert opinion of a Tech Lead, ensure that the work meets an agreed set of quality criteria and merge it into our published specification.

Tech Leads do not necessarily need to hold a 1:1 relationship with a building block. Indeed, we may work with multiple tech leads on a single BB and one Tech Lead may be consulted on changes across multiple BBs. The idea is that the Triage Lead ensures that the proposed change is documented well enough in the Jira issue that the Tech Lead has to spend very little time giving their opinion.

A Triage Lead needs the leadership qualities we discussed in Berlin in May. Some current BB Leads would likely be great Triage Leads and Tech Leads at the same time.

Pay small number of Triage Leads / Committer Lead

The key workload of maintaining the team around building blocks falls to the Triage Leads. There may be two or three of these to support all the current building blocks, the final number being determined by budget. Their work is less easy to find voluntarily.

Tech leads are easier to find voluntarily, especially if we remove the triage/management responsibility.

Maintain current building blocks

We need to be clear which building blocks are in maintenance mode and which are under active development. I would suggest that those under active development follow sprints and those that are not simply follow the “issue queue” work of the Triage Leads

Invite anyone to develop new building block specs based upon use-cases

Anyone, groups of individuals or specific organisations with interest in the area, should be encouraged to work on new building blocks from the list defined in the Exchange.

They need materials and support to understand what would be expected of their content for it to be accepted as part of a future published version. This would largely be defined as quality criteria similar to the Drupal Core Gates.

They can develop at their own pace until they have something worth publishing but, to be included in a release, they commit to a specific timetable around a release. This means it might take a year or two before they “apply for main publication inclusion” and they enter a workstream where they agree to timings of meetings, reviews, etc just for the publication.

Give due recognition for contribution in the Marketplace

We get more and more strict as to how we measure contribution and give recognition and reward. It all has to come down to Jira.

Roles

The proposal requires a number of roles to implement. In some cases, one person may be performing more than one of these roles. Ideally, though, they should avoid a situation where they are both proposing and approving the same change. An example of this would be if a person acts as a Triage Lead on an issue, they should as a different person who is a Committer Lead to actually merge the work.

Triage Lead

A Triage Lead’s purpose is to ensure that all leads and other contributors have a clear list of questions to apply their talent to. A Triage Lead:

1. Encourages those with interest in the specifications to raise their thoughts for how they can be improved as Jira issues

   1. At an initial level, this could be through the ”Give Feedback” form on the website which creates issues on their behalf

   2. A Triage Lead is responsible for monitoring people using the Give Feedback option and invite those giving regular, constructive feedback to create a Jira account, introduce them to other Contributors and Leads working in the area, and assist them with contributing more.

2. Monitors incoming issues and works with the issue creator to ensure that they are

   1. Clearly described in that they define what is proposed, why, and optionally give alternative solutions

   2. Identify Tech Expert(s) that can give their opinion on specific pieces of the issue, as needed

3. Ensure that relevant Tech Expert(s) are brought to the issue

4. Support the Tech Expert in giving their opinions and recording that in the issue

5. Support Contributors in proposing any agreed changes to the specification, as advised by the Tech Expert, as Change Requests

6. Works with a Committer Lead to approve the Change Request and commit the change

7. Handles conflict in the issue, forwarding any conflicts that cannot be resolved to the Committer Lead for final decision. (Note that behaviour management is not the same thing as conflict resolution, though they can occur concurrently – behaviour management should be handled through the Code of Conduct)

8. Closes issues when work is completed and gives thanks to all those involved.

Tech Expert

A Tech Expert provides their expertise on an ad-hoc basis wherever they are called upon to give it in the specifications. They:

1. Monitor Jira issues for those wanting a Tech Expert opinion that falls within their scope of expertise. We will use Jira tags for this, one for each type of Tech Expert needed, in the same way Drupal does for tags like Accessibility

2. Adds comments to the issue that leads other Contributors and Leads to understand how the issue should be progressed, if at all

3. Follows the directions of GovStack’s Quality Criteria Statement to know what can be included. Things like neutrality of content, following the template, language, etc should all be included in such a Quality Criteria Statement, just like Drupal does with the “Core Gates”

Committer Lead

The “final say” on whether a change is included is taken by the Committer Lead. They:

1. Monitors the list of issues for throes that are marked as ready for commit

2. Checks that the content proposed in a Change Request associated with the issue (because we always remember to add the issue number to the Change Request title) meets the Quality Criteria Statement. Sends back to the Triage Lead if not for further work

3. Merges the change

The only people able to commit to repositories in GovStack will be Committer Leads. They are ultimately responsible for the quality of content committed, as referenced by the Quality Criteria Statement, and that the associated jira issue is up to date. The Committer Lead will close the jira issue once the commit is made.

Commits can be made either in GitHub or GitBook. We will reflect permissions across each platform. A Committer Lead may have that role across one, many or all repositories.

Contributor

Everyone connected to the GovStack project is a Contributor. In the specific context of the specifications, a Contributor can either bring their own ideas, questions, or feedback to the project and this is always done through the Jira issue management system. Only by using Jira to record all of the activity, can we be sure to respond consistently and later give due recognition and reward for the contributions they make.

Whilst we might want to reach out to specific people to act as Contributors on occasion, we also allow and encourage contributions from anyone who can give us their feedback, making it easy for them to do so by initially having a “feedback form” on the specifications website that actually creates jira issues on their behalf. Should the feedback be interesting, Triage Leads reach out to the Contributor to invite them to work directly in Jira and contribute more and more.