This document describes the governance regime for Projects of the OpenWIS® Association. This is intended as a supplement to the Articles of Association and Internal Rules. In the event of any discrepancy between the intentions noted in this document, meaning and governance shall be sought from the Articles of Association then the Internal Rules over this document.
Initiation of new Projects
- A Member or Partner organisation may submit a proposal for a new Project; ‘Project Proposal’; for example, a study or research activity, or for the development of a new software package or as part of a contribution to an externally funded initiative.
- When the Steering Committee deem that there is sufficient interest in a Project Proposal, the Steering Committee Chair will announce the development of a new Project Charter.
- A Project Charter must define the scope, anticipated duration of Incubation Phase and other characteristics of the intended work.
- Member and Partner organisations wishing to participate should register their interest their interest in the proposed Project, indicating, without binding commitment, what level resource they may be able to contribute.
- Subject to review by the Steering Committee, the Project Charter shall be assessed for: (i) compatibility with the purpose and objective of the OpenWIS Association, (ii) sufficient commitment from Member and Partner organisations to operate a core project team, (iii) clarity of objective, (iv) timescale. (etc.)
- Based on the assessment, the Steering Committee shall vote to recommend establishment of a new Project.
- The Board must approve the Steering Committee recommendation before the Project can be established.
- Once approved, the Steering Committee shall:
- establish the Project Management Committee (PMC); the PMC shall comprise one delegate, “PMC Member”, from each participating Member or Partner organisation
- appoint the Project Leader(s) from amongst the PMC Members - this person or persons is accountable for the delivery of the Project as specified in the Charter;
- assign a mentor from the Technical Committee if a member of the Technical Committee is not already participating in the Project;
- work with the PMC to agree the open source License under which the project deliverables will be made available and develop a suitable Contributor License Agreement (CLA); and
- request the necessary environment for the project to be provisioned (“Project Provisioning”); e.g. hosting space for Project websites, wikis, mailing lists, source code repositories, etc.
- New Projects shall begin in the Incubation Phase. Classification of “incubation” is less a statement about the quality of the Project’s code; rather it is about assessing the Project team’s progress in practicing the open and public processes necessary to establish the two communities (developers and users) around the Project. When a the Project’s code and documentation is ready, and the Project team has learned to operate as an open source project, the project may opt to graduate into the Mature Phase.
The project initiation procedure is described here.
Amendments to existing Projects
- Members and Partner organisations may become additional ‘participants’ in a given Project (and thus assign a representative to the PMC) via mutual consent from the existing participating Member and Partner organisations. Participation may be subject to assessment of the level of contribution that the new organisation is willing to commit and/or previous contribution(s) from the organisation. Member or Partner organisations may escalate requests to the Steering Committee.
- A PMC may request an amendment or extension to their Charter. Amendments and extensions are subject to Board approval following recommendation from the Steering Committee.
- A PMC may, by mutual consent (two-thirds majority), choose to elect new or additional Project Leaders from amongst the members of the PMC.
- A PMC may, by mutual consent (two-thirds majority), choose to elect new or additional PMC Members from amongst the Project’s active Contributors.
Member and Partner organisation commitments
- Member and Partner organisations shall apply reasonable endeavours to meet their stated commitment to the Project.
- Anyone can Contribute to the Project delivery; subject to completion of a CLA and their good standing within the OpenWIS® community.
- A simple KANBAN approach to agile delivery is recommended; using a ‘notice board’ to manage the flow of work within each Project.
- New work packages must be approved by the PMC before they are added to the Project notice board.
- Each work package will define the features to be delivered (rather than the technical details of “how” the work package is to be implemented). It is recommended that work packages should be defined as ’Small’, ‘Medium’ or ‘Large’ for simplicity in planning.
- Delivery criteria for the work package will include elements such as test coverage and documentation.
- Contributors and Participants in the Project take work packages according to their priority.
- Progress on each work package must be visible. This will help show which features may be included in the next release.
- Regular scheduled delivery of ‘Feature Releases’ is recommended.
- Patch Releases will be made as necessary in response to urgent bug-fixes and other stimuli.
- Release numbering should use the following scheme: x.y.z
- ‘x’ = major version number,
- ‘y’ = feature release number,
- ‘z’ = patch release number.
- Even number ‘Feature Releases’ (e.g. 4.2.0) will be stable releases intended for operational deployment; odd number ‘Feature Releases’ (e.g. 4.1.7) will be developer releases. The developer release allows new and experimental features to be exposed prior to their incorporation in a stable release.
Governance for Project deliverables and releases
- With guidance from the Technical Committee, the PMC will define the release mechanism, quality criteria and schedule pertinent to the project.
- The PMC must agree the release quality criteria with the Steering Committee.
- Steering Committee will hold PMC to account with respect to the release quality criteria - either through review of each release, or by post-release audit.
The governance of project delivery and releases is described in this flowchart.