|
| 1 | +# Contributing Guide |
| 2 | + |
| 3 | +> This guide is a draft under construction. |
| 4 | +
|
| 5 | +## 1. Read the specification |
| 6 | + |
| 7 | +Consult the latest Editor’s Draft before proposing changes: |
| 8 | + |
| 9 | +* HTML: [https://zarr.dev/geozarr-spec/documents/standard/template/geozarr-spec.html](https://zarr.dev/geozarr-spec/documents/standard/template/geozarr-spec.html) |
| 10 | +* PDF: [https://zarr.dev/geozarr-spec/documents/standard/template/geozarr-spec.pdf](https://zarr.dev/geozarr-spec/documents/standard/template/geozarr-spec.pdf) |
| 11 | + |
| 12 | +## 2. Understand GeoZarr objectives |
| 13 | + |
| 14 | +GeoZarr does not define a new data model. It provides an encoding and mapping to Zarr aligned with CDM-friendly frameworks and formats. Background: [https://medium.com/@christophe.noel/geozarr-1-0-objectives-cf4f9a777a0d](https://medium.com/@christophe.noel/geozarr-1-0-objectives-cf4f9a777a0d) |
| 15 | + |
| 16 | +## 3. Scope and workflow for changes |
| 17 | + |
| 18 | +* Avoid modifying multiple sections at once. |
| 19 | +* Propose initial changes in a focused section. |
| 20 | +* Use GitHub issues for discussion before drafting large updates. |
| 21 | +* Create a branch in the main repository for visible collaborative work. |
| 22 | + |
| 23 | +## 4. Participation |
| 24 | + |
| 25 | +* All community members may comment on issues and pull requests. |
| 26 | +* Monthly OGC GeoZarr SWG meetings provide a forum to review open work. |
| 27 | +* Example datasets can be contributed to [https://github.com/developmentseed/geozarr-examples](https://github.com/developmentseed/geozarr-examples). |
| 28 | + |
| 29 | +## 5. Maintenance structure |
| 30 | + |
| 31 | +### Write access |
| 32 | + |
| 33 | +Granted to a defined maintenance team. This includes SWG chairs and additional contributors approved by them. |
| 34 | + |
| 35 | +### Review and approval |
| 36 | + |
| 37 | +Informal reviews may involve any participant. |
| 38 | +For contested matters, only designated OGC GeoZarr SWG voting members may cast formal votes. |
| 39 | + |
| 40 | +### Pull request process |
| 41 | + |
| 42 | +* PRs are reviewed during regular SWG meetings. |
| 43 | +* Consensus is required for merge. |
| 44 | +* If consensus cannot be reached, an OGC formal vote may be initiated by email. |
| 45 | +* PR authors should ensure that discussion items are placed on the next SWG meeting agenda. |
| 46 | + |
| 47 | +## 6. Versioning and releases |
| 48 | + |
| 49 | +The group follows semantic versioning for official releases. Minor editorial or encoding improvements may occur between major releases when consensus allows. |
| 50 | + |
| 51 | +## 7. Roadmap |
| 52 | + |
| 53 | +Work should follow the priorities defined in the roadmap: |
| 54 | +[https://github.com/zarr-developers/geozarr-spec/wiki/First-Release-RoadMap](https://github.com/zarr-developers/geozarr-spec/wiki/First-Release-RoadMap) |
0 commit comments