Standards Maintenance

Introduction

Standards maintenance is managed through the GitHub repository https://github.com/ConsumerDataStandardsAustralia/standards-maintenance. This repository is used for discussions and contributions from the community of participants and other interested parties in the Australian Consumer Data Right regime. Refer to the Main Standards Repository for a broad overview of Consumer Data Standards managed by the Data Standards Body.

For specific details of the next Maintenance Iteration, refer to the Standards Maintenance repository README file.

Contributing Change Requests and queries

To contribute a Change Request or a query regarding the Consumer Data Standards, raise an issue on the Standards Maintenance repository.  For details of this process, see Creating a Change Request.

How to Join

To participate in the Standards Maintenance fortnightly meetings and contribute to the discussion, sign up with the DSB Calendar, or send a request via email to [e-mail].

Maintenance Cycle

Each maintenance iteration covers a period of eight weeks, and consists of the following phases:

Backlog Grooming - 2 weeks During this phase participants comment on issues that have been raised and the DSB assesses the relevant complexity and importance of the issues identified by the community. The phase culminates in the selection of items for the iteration backlog by the DSB according to perceived priority and team capacity. This phase has two rituals:

• Retrospective, kickoff and discuss backlog: Includes a retrospective of the previous iteration as well as kicking off the next iteration with a backlog grooming of all outstanding change requests. It is an opportunity to actively discuss the priority of the change requests, concerns and considerations as well as the focus of the iteration.
• Finalise backlog: The end of the backlog grooming results in agreement on the prioritised list of change requests.

Consultation - 4 weeks During this phase the DSB, and the community, review the prioritised backlog of change requests and provide proposed changes to the standards and provide feedback on their relative merits. At the end of this phase a specific proposal is formulated for submission to the Data Standards Chair for approval. If a single acceptable proposal cannot be identified then the issue may be carried over to a subsequent iteration. This phase has two rituals:

• Progress checkpoint: During this meeting the DSB, and community, reviews the current progress made on the proposed changes. The review includes the proposal and discussion on potential obligation dates for the proposed changes and impacts.
• Review and summary of proposals: Review and discussion of remaining change requests and a summary of the positions agreed between the DSB and the community for each proposed change. The review include a discussion on potential obligation dates for the proposed changes and impacts.

Formal Approval & Update - 2 weeks During this phase the recommended proposals are provided to the Data Standards Advisory Committee for final review and then submitted to the Data Standards Chair for approval. The approved proposals are then be incorporated into the formal standards documentation.

Rituals

Due to the national scope of the CDR regime the bulk of consultation and collaboration is expected to be conducted online using the issue tracker on Standards Maintenance repository and the associated project boards.

In addition to this consultation a teleconference to discuss the phase is conducted every 2 weeks.

Meeting Information and Guidelines

Maintenance Information workgroup meetings are recorded. By attending the meeting you are agreeing to the guidelines described in Consultation meeting information and community guidelines.

Visual Project Boards

A project board for each sector is maintained in this repository. These project boards are used to track progress on each of the prioritised issues.

Currently only a single project board exists: the Data Standards Maintenance Board.

Key Processes

Raising Issues

Any interested contributor is encouraged to raise new issues for queries or requests for change on the issue tracker. Issue templates have been created for change requests and for questions. It is requested that these templates be used when raising issues.

A series of labels have also been created so that issues can be categorised when they are raised. It is requested that these labels are applied, as appropriate, when the issue is raised. Of special note is the 'Urgent' label that is used to identify changes that need to be dealt with outside of the normal cadence. Please use this label judiciously.

Issue Categorisation

It is expected that issue categorisation is done by the individual raising the issue through the application of labels. Once raised the DSB may re-apply labels if the issue is identified as being miscategorised. This may occur in response to feedback and comments identifying a different root cause for the change than originally expected.

If an issue is identified as being too complex or impactful to the standards to be managed via the maintenance process the DSB may elect to recategorise the issue as a fully fledged decision proposal. If this occurs then the issue will be closed in the maintenance repository and a new issue will be raised in the main standards repository.

Issue Prioritisation

The DSB will prioritise the open issues taking participant feedback into account. This priortisation will be managed via the order of the issues in the 'Full Backlog' column of the relevant project board.

Closing Issues

Issues may be closed by the original poster if they have received an answer that resolves their query. Alternatively, the DSB may close issues after seven (7) days where an answer has been supplied with an "answer provided" label and there has been not further comments or discussion on the issue. From time to time, the DSB may also close issues that are considered stale because there has been no feedback for an extended period of time.

Backlog Selection

At the end of the grooming phase the DSB will select a set of issues to be considered for the iteration. Issues will be selected according to priority but selection will also take into account the relative complexity of the issues and the capacity of the DSB team available for the iteration. Final decision of backlog items rests with the API Standards and InfoSec Lead under the supervision of the Data Standards Chair.

Decision Making

All decision making authority rests with the Data Standards Chair. Neither DSB members or community contributors have formal decision rights for the CDR regime. As a consequence all proposals are considered recommendations until the Data Standards Chair has formally approved them. Once approval is obtained this will be documented in the main standards repository.

Urgent Change

In the event of an issue being advised as being urgent (perhaps to support a critical implementation issue, defect or security flaw) the issue will be dealt with as a priority and, once a recommendation is identified, will be immediately submitted to the Data Standards Chair for approval. It is hoped that urgent changes can be minimised and, to help ensure this, the DSB reserves the right to verify whether an issue is considered urgent or not.