Skip to content

Latest commit

 

History

History
41 lines (23 loc) · 2.48 KB

AgreedDevelopmentProcesses.md

File metadata and controls

41 lines (23 loc) · 2.48 KB
Raw

Agreed processes for developing the EDR API Standard

Specific to the Standard Working Group:

  1. The Standard Working Group will meet weekly or fortnightly, as agreed at previous meetings, using OGC GoToMeeting telco facilities.

  2. The meetings will be notified in the OGC Portal Calendar and via the EDR-API mailing list.

  3. Minutes of the Standard WG meetings will be on the repository wiki.

  4. The Co-Chairs of the OGC EDR API SWG have admin rights on this repository.

  5. Substantive changes to the repository are introduced through Pull Requests.

  6. Each PR will be reviewed and approved by at least two people, discussed and approved in a meeting of the Standard Working Group before being merged.

  7. Only minor editorial corrections, such as spelling typos, will be done 'in place' without a PR.

  8. Issues will be raised and discussed using the GitHub Issues. They will be discussed and closure agreed in a meeting of the Standard Working Group before being closed.

  9. Some issues will be tagged as enhancements for future Milestones.

Cross-Standard Coordination

A. Issues that affect multiple draft OGC API specifications should be checked against the issues at OGC API - Common SWG to confirm whether the topic has already been registered, and then let your SWG representatives know so that the issue can be flagged for discussion by the OGC API - Common SWG. If a new isue, please tag it with Cross-SWG Discussion. Resolution of the issue will be documented in a standard template as below:

  Specification:	name of the specification under discussion

  Objective:	describe the objective of the discussions.  Can be more than one
  •	<objective 1>
  •	<objective 2>
  •	<etc.>
  Discussion:	free text description of the discussions

  Outcome:	describe the conclusions.  Make sure you have clear concurrence on any actions.

  Risks/Mitigation:	discussions may not be entirely satisfactory.  What are the open risks and issues?  What do you propose to do about them?

  Comments:	Any additional information not covered by the categories above.

B. There is an OGC-wide proposed policy on “Naming of OGC API Standards, Repositories & Specification Elements" OGC 20-059r4 that we shall try to follow.