Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

initial draft of 'how changes are made' doc #84

Merged
merged 1 commit into from
Jul 31, 2020
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 24 additions & 0 deletions how_changes_are_made.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
# How Changes are Made to the Code4Lib Code of Conduct

The purpose of this document is to clearly outline a transparent means of modifying the Code4Lib community's Code of Conduct and related community standards.

1) One should submit changes to the Code of Conduct and its related documents as a Pull Request (PR) on [the Code of Conduct repository](https://github.com/code4lib/code-of-conduct). If you are uncomfortable with GitHub and PRs, you can contact the people listed in [css_volunteers.md](https://github.com/code4lib/code-of-conduct/blob/master/css_volunteers.md) and they will help compose one on your behalf. No one has to log into Github if they do not want to.

It is preferable for changes to be logically segmented as opposed to sets of unrelated edits to different files. For instance, adding a name to SUPPORTERS.txt, fixing a typo in code_of_conduct.md, and adding a list item to norms.md are better as three separate requests than a single monolithic one.

2) Pull Requests generate their own discussion threads where questions can be asked and changes may be proposed or incorporated. Changes to the PR must be made or approved by its original author(s); if they do not agree with the changes, then the changes are better suited to becoming a separate PR. As with creating PRs, if you are not comfortable commenting on a PR for any reason, you may reach out to the CSS who will do so on your behalf. Once discussion has ended on a PR, indicated by two weeks without a comment or change submitted, the PR is ready to be reviewed.

3) The Community Support Squad (CSS) reviews the changes suggested by the Pull Request and either approves them, rejects them, or re-opens discussion on the PR with further comments, questions, or suggested changes. In order to be approved, a majority of CSS members must vote in favor of the PR. For instance, if three of seven CSS members vote in favor of a PR, while only one votes against it and three abstain, then the PR would be rejected.

The Community Support Squad may decide that a set of proposed changes are so wide-reaching, or subject to so much disagreement or controversy, that a community-wide vote must be called.

Examples of changes that call for a community vote are: this document itself, which introduces a new procedure related to the Code of Conduct and changes the nature of the CSS's responsibilities within the Code4Lib community; an addition of an entire section to the Code, such as a new method or philosophy of enforcement; and any change that generates substantial debate within the community or the CSS itself, for instance one with several comments on its PR that represent divergent points of view.

In those instances, the CSS conducts a community vote with an accessible, web-based form with the following elements:

- respondent email address, used only to deduplicate responses and not visible outside the CSS
- the proposed changes
- the discussion on GitHub and any additional, relevant resources
- an option to approve or reject the changes

Community votes will be held open for one month, with a reminder 2 weeks before they close, and changes approved if greater than half of respondents agree with them.