...
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?
...
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 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:
Encourages those with interest in the specifications to raise their thoughts for how they can be improved as Jira issues
At an initial level, this could be through the ”Give Feedback” form on the website which creates issues on their behalf
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.
Monitors incoming issues and works with the issue creator to ensure that they are
Clearly described in that they define what is proposed, why, and optionally give alternative solutions
Identify Tech Expert(s) that can give their opinion on specific pieces of the issue, as needed
Ensure that relevant Tech Expert(s) are brought to the issue
Support the Tech Expert in giving their opinions and recording that in the issue
Support Contributors in proposing any agreed changes to the specification, as advised by the Tech Expert, as Change Requests
Works with a Committer Lead to approve the Change Request and commit the change
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)
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:
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
Adds comments to the issue that leads other Contributors and Leads to understand how the issue should be progressed, if at all
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:
...
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.
...