Skip to content

ML-STAC Development & Release Process 🌟

Development Process 💻

The Machine Learning SpatioTemporal Asset Catalog specification is under active development. The goal is to get to a small, flexible stable release that can be extended in a variety of ways. The core development team aims to release early and often, which generally means a new release between six months after the previous one.

The main branch aims to always be stable, meaning that all the pieces of the specification are consistent and well explained, and all the examples are consistent with the specification. The dev branch is a place of active development, where a new change in one part of the spec might not yet be fully updated everywhere else. The team uses the ml-stac issue tracker to identify and track all that will be done for a release. Once all the major issues are resolved the core team makes sure everything is consistent across the spec and examples.

Any changes to the spec must be made as pull requests to the dev branch. Anyone is welcome and encouraged to bring ideas and improvements, to the issue tracker or (ideally) as pull requests. To merge a new pull request the work must be reviewed by at least two members of the STAC spec 'core team' (who have write access to the main repository). It also must pass the Continuous Integration (CI) testing, which checks all Python and example files for proper formatting, and also validates all examples against JSON schema. For more information about making pull requests see CONTRIBUTING.md.

Core ML-STAC Team 🌐

The current list of people who are part of the 'core ML-STAC team', and can approve pull requests.

Anyone can be nominated to the core ML-STAC team, and that generally happens after contributing a few pull requests and/or helping review other PR's. Nominations are reviewed by the PSC and must receive 3 positive votes and no negatives.

Release Process 🚢

To release a new version of the STAC spec the following list of tasks must be done.

  • Update Issue Tracker: Each release has a milestone in the GitHub issue tracker, and before a release is done all open issues that are filed against it should be reviewed. All issues do not need to be completed, but the core release team should review the issues to make sure that the critical ones for the release have been addressed. Issues that aren't seen as essential should be moved to future releases so that there are no open issues against the milestone.
  • Agreement from the Project Steering Committee: The PSC should meet (on the phone or on Google Meet) and decide that the release is ready. This should include a review of the issues, as well as looking at the spec holistically, to make sure the new changes keep with a coherent whole.
  • Final Spec Read Through: There should be a final read-through of the core specification to make sure it makes sense and there are no typos, errors, etc.
  • Update the Changelog: The changelog should be reviewed to make sure it includes all major improvements in the release. And anything in the 'unreleased' section should move to the version of the spec to be released.
  • Merge dev to master: As there is no 'build' process since the specification is the markdown files in the GitHub repository, the key step in a release is to merge the dev branch into master, as master is the current stable state of the spec.
  • Release on GitHub: The final step to create the release is to add a new 'release' on https://github.com/radiantearth/stac-spec/releases. This should use a tag like the others, with a 'v' prefix and then the release number, like v0.5.2. The changelog should be copied over to be the release notes, and then also include a link to the full milestone of everything closed in the issue tracker.

Governance 🏛️

The vast majority of decisions on ML-STAC are made by the Core ML-STAC Team reaching consensus in discussions in pull requests and issues. Any change to the specification must have two positive reviews and no negative reviews.

Project Steering Committee 🗳️

In the rare case where a decision cannot be reached by consensus, there is a Project Steering Committee that has ultimate decision-making authority. This consists of individuals who are intended to represent the various communities which have a stake in the specification and surrounding ecosystem. An odd number is chosen to facilitate the voting process and help prevent ties. This committee also handles the allocation of any funds that are raised for the project. Turnover is allowed and expected to accommodate people only able to become active on the project in intervals. A PSC member may step down at any time.

Current Project Steering Committee 📜

PSC Membership 💼

A new PSC member can be nominated at any time. Voting for a new PSC is done by current active PSC members. PSC nominations are generally given in recognition of very significant contributions to the specification or the broader ecosystem. PSC members are not expected to be technical, and we hope to recognise contributions in documentation, outreach and evangelism. Nominated PSC members must receive a majority of +1 votes from the PSC, and no -1’s. The initial PSC was selected by Cesar Aybar, who was deemed the 'Benevolent Dictator for Life' for the bootstrapping phase.

Back to top