From 862642eb86a00362398514f735863890fdc25720 Mon Sep 17 00:00:00 2001 From: Mathew Biddle <8480023+MathewBiddle@users.noreply.github.com> Date: Thu, 30 Jul 2026 15:33:41 -0500 Subject: [PATCH 1/2] Update GOVERNANCE.md closes #3 #15 #16 --- GOVERNANCE.md | 154 ++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 117 insertions(+), 37 deletions(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 93dd628..53176bc 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -1,37 +1,117 @@ -# Governance -The ACDD Steering Committee formalizes changes and additions to ACDD. - -The discussion for changes to ACDD is carried out via this wiki and the [ESIP Documentation Cluster mailing list](http://lists.esipfed.org/mailman/roster/esip-documentation). -To sign up for edit privileges for this wiki you must first [register at the ESIP Commons](http://commons.esipfed.org/user/register). This registration also -grants access to other community resources supported by ESIP. Both the mailing list and this wiki are open and -anyone in the community. ACDD will evolve based on the discussions on this list and as documented on these wiki -pages. Occasionally, the discussion may need to be moderated or a decision must be made. In these cases the -steering committee will vote and adopt a solution as described below. - -## Steering Committee - -ACDD will evolve based on the direction of the steering committee, which is comprised of the following members: - -* Anna Milan (Co-chair) NGDC -* John Graybeal (Co-chair) Graybeal.SKI Consulting -* Dave Blodgett USGS -* Nan Galbraith WHOI -* Ted Habermann The HDF Group -* Steve Hankin PMEL -* Marcos Hermida Unidata -* Aleksandar Jelenak The HDF Group -* Anna Milan NGDC -* Dave Neufeld CIRES -* Rich Signell USGS -* Bob Simons NMFS -* Derrick Snowden IOOS -* Ed Armstrong JPL - -## Decision Making Process - -Vote 70% majority of voting members; members may decline to vote on some issues - -If a vote is taken or a decision is reached, that decision should be broadcast to those who could not be present. -Discussion of the decision takes place for some period of time (or till the next meeting?) If there is disagreement -or ongoing discussion, the decision is not finalized. If there is no discussion or disagreement, the topic is final -and will not be revisited later. +# Contributing to the Attribute Convention for Data Discovery (ACDD) + +Thank you for your interest in the [ACDD](https://wiki.esipfed.org/Attribute_Convention_for_Data_Discovery_1-3/). + +The following guidance for contributing and governance rules are modelled after the [CF conventions](https://github.com/cf-convention/cf-conventions/blob/main/CONTRIBUTING.md). + +As a prerequisite to getting involved, please review the community's code of [conduct](https://github.com/ESIPFed/acdd/blob/main/CODE_OF_CONDUCT.md). + +These rules are designed to make it easy to contribute to the ACDD and are tailored to GitHub, the platform where they are hosted. +They are intended to support your work and not to constrict you; if at any time you find them difficult to follow, please ask for help. + +## Contents + +* [Rules for Changes to the ACDD](#rules) + * [Versions and schedule for updating the ACDD conventions](#new_versions) + * [Rules for enhancements to the ACDD conventions](#enhancement_rules) + * [Dormant issues](#dormant_issues) +* [Technical guidelines](#technicalities) + * [Pull requests](#pull_requests) + * [Text styling](#text_styling) +* [Revision history of the rules](#history) + +## Rules for changes to the ACDD + +These rules apply to the ACDD conventions and related documentation. +They describe the practices and procedures that should be used in fixing, updating, or adding to the metadata attributes. + +All changes to the ACDD should be discussed on GitHub using a consensus model for adoption. Each change should be initiated in an [issue](https://github.com/ESIPFed/acdd/issues). If there is support, then the change should be summarized and a pull request created. See [ Rules for enhancements to the ACDD conventions] (#rules-for-enhancements-to-the-acdd-conventions) + + +All changes to the conventions documents are proposed and discussed in an [issue](https://github.com/ESIPFed/acdd/issues) and implemented in a related [pull request](https://github.com/ESIPFed/acdd/pulls) in the [ACDD conventions GitHub repository](https://github.com/ESIPFed/acdd/), which contains the source of the ACDD conventions documents. + +---- + +### How to suggest changes + +Submit requests for changes to the ACDD [github repository](https://github.com/ESIPFed/acdd). Use the template for a new issue. + +Issues are organized into the following categories: + +label | description +------|------------- +enhancement | add new capabilities or improve existing ones +defect | corrections to substantial defects +copy edit | (spelling mistakes, etc) + +In the template, please indicate which category of change you are suggesting and we will apply the appropriate label. + +Submitters of suggested changes may be added to the contributors list. + +---- + +### Versions and schedule for updating ACDD + +New versions of the conventions are published as needed, following the [semantic versioning](https://semver.org/) schema. + + +All previously published versions of the conventions will be available as releases in GitHub. + +---- + +### Rules for enhancements to the ACDD conventions + + +Identified a problem +Make an issue +Issue will be available for open discussion for any interested participants +Issues can be closed under the following conditions: +Once consensus is reached, the issue can be closed and move to summary and Pull Request +After no activity in the issue for 3 months, an automated message will prompt administrators to take some action on the issue (close, raise for more discussion, merge, leave open, etc.). After three additional months it will become a [dormant issue](link below). +After no discussion for one week the issue will be closed or implemented according to the consensus reached. +Some admin will describe the final decision and propose the changes as a Pull Request or instruct someone else to propose the changes. +Pull Request will be merged after final review period of one week. +If there are objections, a new issue can be opened. + +When closing issues administrators should provide a brief description of why the issue is being closed. + +The moderator is encouraged to organize discussion meetings if this might help resolve an issue more quickly. + +The arguments presented and any conclusions reached in such a meeting should be summarised afterwards in the GitHub issue, for the record and so that everyone can continue to be involved in further discussion. + +In case of any disagreement, the conventions committee will arbitrate. + +---- + +### Dormant issues + +If an issue falls silent for more than six months without conclusion, any member of the ACDD steering committee may post on the issue to encourage any interested person to resume it within three weeks, if they wish it to remain open. +If discussion does not resume within three weeks, the issue should be closed with the `dormant` label attached. +The issue may subsequently be reopened and the `dormant` label removed by anyone wishing the continue the discussion. + + +### Pull requests + +Pull requests should be submitted to the `main` branch of the repository. +Use of other branches is at the discretion of the repository administrators. +It is recommended that pull requests are created on a branch of a personal fork of the repository. +Comments in pull requests should be avoided, unless discussing changes to the wording of a proposal that do not impact on the agreed meaning. + +---- + +### Text styling + +The ACDD documents and website are generated from a mix of AsciiDoc and Markdown files. +The files should be formatted in line with the +[AsciiDoc Recommended Practices](https://asciidoctor.org/docs/asciidoc-recommended-practices/) +and +[Google Markdown style guide](https://google.github.io/styleguide/docguide/style.html). +Each sentence should begin on a new line. + + +---- + +## Revision history of the rules + +* This document was created (commit link) + From 45b858ee0745a8b981f07c556a1ac3b525d6f763 Mon Sep 17 00:00:00 2001 From: Mathew Biddle <8480023+MathewBiddle@users.noreply.github.com> Date: Mon, 3 Aug 2026 07:52:06 -0400 Subject: [PATCH 2/2] Update GOVERNANCE.md fixing syntax and making a space for steering committee --- GOVERNANCE.md | 59 +++++++++++++++++++++++++++++---------------------- 1 file changed, 34 insertions(+), 25 deletions(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 53176bc..e8f46bd 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -11,21 +11,29 @@ They are intended to support your work and not to constrict you; if at any time ## Contents -* [Rules for Changes to the ACDD](#rules) - * [Versions and schedule for updating the ACDD conventions](#new_versions) - * [Rules for enhancements to the ACDD conventions](#enhancement_rules) - * [Dormant issues](#dormant_issues) -* [Technical guidelines](#technicalities) - * [Pull requests](#pull_requests) - * [Text styling](#text_styling) -* [Revision history of the rules](#history) +* [ACDD Steering Committee](#acdd-steering-committee) +* [Rules for Changes to the ACDD](#rules-for-changes-to-the-acdd) + * [How to suggest changes](#how-to-suggest-changes) + * [Versions and schedule for updating ACDD](#versions-and-schedule-for-updating-ACDD) + * [Rules for enhancements to the ACDD conventions](#rules-for-enhancements-to-the-ACDD-conventions) + * [Dormant issues](#dormant-issues) +* [Technical guidelines](#technical-guidelines) + * [Pull requests](#pull-requests) + * [Text styling](#text-styling) +* [Revision history of the rules](#revision-history-of-the-rules) + +## ACDD Steering Committee + +Name | Role | Affiliation +-----|------|------------ + ## Rules for changes to the ACDD These rules apply to the ACDD conventions and related documentation. They describe the practices and procedures that should be used in fixing, updating, or adding to the metadata attributes. -All changes to the ACDD should be discussed on GitHub using a consensus model for adoption. Each change should be initiated in an [issue](https://github.com/ESIPFed/acdd/issues). If there is support, then the change should be summarized and a pull request created. See [ Rules for enhancements to the ACDD conventions] (#rules-for-enhancements-to-the-acdd-conventions) +All changes to the ACDD should be discussed on GitHub using a consensus model for adoption. Each change should be initiated in an [issue](https://github.com/ESIPFed/acdd/issues). If there is support, then the change should be summarized and a pull request created. See [ Rules for enhancements to the ACDD conventions] (#rules-for-changes-to-the-acdd) All changes to the conventions documents are proposed and discussed in an [issue](https://github.com/ESIPFed/acdd/issues) and implemented in a related [pull request](https://github.com/ESIPFed/acdd/pulls) in the [ACDD conventions GitHub repository](https://github.com/ESIPFed/acdd/), which contains the source of the ACDD conventions documents. @@ -62,16 +70,16 @@ All previously published versions of the conventions will be available as releas ### Rules for enhancements to the ACDD conventions -Identified a problem -Make an issue -Issue will be available for open discussion for any interested participants -Issues can be closed under the following conditions: -Once consensus is reached, the issue can be closed and move to summary and Pull Request -After no activity in the issue for 3 months, an automated message will prompt administrators to take some action on the issue (close, raise for more discussion, merge, leave open, etc.). After three additional months it will become a [dormant issue](link below). -After no discussion for one week the issue will be closed or implemented according to the consensus reached. -Some admin will describe the final decision and propose the changes as a Pull Request or instruct someone else to propose the changes. -Pull Request will be merged after final review period of one week. -If there are objections, a new issue can be opened. +1. Identified a problem +1. Make an issue +1. Issue will be available for open discussion for any interested participants +1. Issues can be closed under the following conditions: + 1. Once consensus is reached, the issue can be closed and move to summary and Pull Request + 1. After no activity in the issue for 3 months, an automated message will prompt administrators to take some action on the issue (close, raise for more discussion, merge, leave open, etc.). After three additional months it will become a [dormant issue](#dormant-issues). +1. After no discussion for one week the issue will be closed or implemented according to the consensus reached. +1. Some admin (TBD) will describe the final decision and propose the changes as a Pull Request or instruct someone else to propose the changes. +1. Pull Request will be merged after final review period of one week. +1. If there are objections, a new issue can be opened. When closing issues administrators should provide a brief description of why the issue is being closed. @@ -85,10 +93,13 @@ In case of any disagreement, the conventions committee will arbitrate. ### Dormant issues -If an issue falls silent for more than six months without conclusion, any member of the ACDD steering committee may post on the issue to encourage any interested person to resume it within three weeks, if they wish it to remain open. +If an issue falls silent for more than six months without conclusion, any member of the [ACDD steering committee](#acdd-steering-committee) may post on the issue to encourage any interested person to resume it within three weeks, if they wish it to remain open. If discussion does not resume within three weeks, the issue should be closed with the `dormant` label attached. The issue may subsequently be reopened and the `dormant` label removed by anyone wishing the continue the discussion. +--- + +## Technical guidelines ### Pull requests @@ -101,11 +112,9 @@ Comments in pull requests should be avoided, unless discussing changes to the wo ### Text styling -The ACDD documents and website are generated from a mix of AsciiDoc and Markdown files. +The ACDD documents and website are generated from Markdown files. The files should be formatted in line with the -[AsciiDoc Recommended Practices](https://asciidoctor.org/docs/asciidoc-recommended-practices/) -and -[Google Markdown style guide](https://google.github.io/styleguide/docguide/style.html). +[GitHub Markdown style guide](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax). Each sentence should begin on a new line. @@ -113,5 +122,5 @@ Each sentence should begin on a new line. ## Revision history of the rules -* This document was created (commit link) +* History of this document can be found in the [GitHub history](https://github.com/ESIPFed/acdd/commits/main/GOVERNANCE.md).