Governance guidelines

A change proposal can be defined at a conceptual level in an issue before being defined at a logical level (i.e. in code). In each case, the proposal must be developed in line with the DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. development design principles.

Once approved on the Working Group, the proposal will be scheduled to be merged with the DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data.'s main code branch by a reviewer.

This document providesIDE Integrated Development Environment. A software application that brings together all the essential tools a developer needs to write, test and debug code in one unified workspace. the governance policy for specifications and other documents developed using the Community Specification process in a repository (each a “Working Group”). Each Working Group must adhere to the requirements.

1. Roles

Each Working Group may include the following roles. Additional roles may be adopted and documented by the Working Group.

• 1.1. Participants. “Participants” are those that have made Contributions to the Working Group subject to the Community Specification License. Participants are automatically abiding by the IP policy of the standard by just participating in a meeting or by actively "enrolling" in the standard.

• 1.2. Discussion Groups. The Working Group may form one or more "Discussion Groups" to organize collaboration around a particular aspect of a specification. Discussion Groups are for discussion only - approval of all portions of a specification is subject to the consensus-based decision-making process.

• 1.3. Working Group Host. The Working Group will have a host that will run the call. They should follow the Working Group guidelines laid out below

2. Working Group meeting flow

The host of the DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. Working Group calls should follow the below process when going through the Kanban project board to allow efficient use of time:

1. Run through Agenda items which will be found on this week's discussion call (Host's role to set up this Discussions page)
2. Approved column:
   1. Ask the group if anyone has any blockers on their items and who needs to action to unblock
   2. Check if a reviewer has been assigned & who is the reviewer
      1. Release Management Team to facilitate assignment of a reviewer
3. Follow-up column:
   1. Ask the group if anyone has any updates on their item
   2. It will be the task of the issue owner to chase whoever wants to follow up. Provided another contributor/reviewer has given an input it should not be blocked
   3. When an issue is approved, request on the call one of the reviewer does the review.
4. Current column:
   1. Go through each item, and move issues to either of the following:
      1. Approved - Request on the call one of the reviewer does the review, and leave a comment and assign an approver
      2. Follow-Up - Leave a comment with the action whoever wants to leave it in Follow-up.

3. Decision making

• 3.1. Consensus-based decision making. Working Groups make decisions through a consensus process (“Approval” or “Approved”). While the agreement of all Participants is preferred, it is not required for consensus. An individual's role will determine the extent of their decision making abilities. For example, the reviewer will determine consensus based on their good faith consideration of a number of factors, including the dominant view of the Working Group Participants and nature of support and objections. The reviewer will document evidence of consensus in accordance with these requirements.

• 3.2. Appeal process. Decisions may be appealed via an issue, and that appeal will be considered by the reviewer in good faith, who will respond in writing within a reasonable time.

4. Major release scheduling guidelines

The Steering Working Group has the role of defining major releases of DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. and shaping their content. The major release scheduling guidelines page discusses the objectives for defining major releases and guidelines that the Steering Working Group (SWG) must follow in scheduling major releases.

5. Change control guidelines

The change control guidelines discusses how changes to DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. are controlled within and between releases, in particular:

• Principles
  • What we are trying to achieve with the change control guidelines;
  • What constraints/objectives we have for putting these guidelines in place
• Rules
  • The specific rules we want to define and enforce to meet the principles
• Evaluation methods
  • How we want to ensure that the rules are evaluated and enforced during development
  • This includes development processes (e.g. review and approval) as well as automated tooling (e.g. regression test cases)

6. Release build approval guidelines

For scheduling of minor, development, patch releases and approvals for all builds and releases, see Maintenance and release.