From 6ae042d6fe228da1043198fca248c7bc114e57e9 Mon Sep 17 00:00:00 2001 From: olaph wagner Date: Thu, 7 Dec 2017 16:07:13 -0600 Subject: [PATCH] Add markdown files This commit adds a few files to bring this repo in line with the current publishing guidelines --- CONTRIBUTING.md | 15 +++++++++ LICENSE.txt => LICENSE | 2 +- MAINTAINERS.md | 70 ++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 86 insertions(+), 1 deletion(-) create mode 100644 CONTRIBUTING.md rename LICENSE.txt => LICENSE (99%) create mode 100644 MAINTAINERS.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..9e101da --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,15 @@ +# Contributing + +This is an open source project, and we appreciate your help! + +We use the GitHub issue tracker to discuss new features and non-trivial bugs. + +In addition to the issue tracker, [#journeys on +Slack](https://dwopen.slack.com) is the best way to get into contact with the +project's maintainers. + +To contribute code, documentation, or tests, please submit a pull request to +the GitHub repository. Generally, we expect two maintainers to review your pull +request before it is approved for merging. For more details, see the +[MAINTAINERS](MAINTAINERS.md) page. + diff --git a/LICENSE.txt b/LICENSE similarity index 99% rename from LICENSE.txt rename to LICENSE index e4a0210..d645695 100644 --- a/LICENSE.txt +++ b/LICENSE @@ -187,7 +187,7 @@ same "printed page" as the copyright notice for easier identification within third-party archives. - Copyright 2015-2017 IBM Corporation + Copyright [yyyy] [name of copyright owner] Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. diff --git a/MAINTAINERS.md b/MAINTAINERS.md new file mode 100644 index 0000000..24a07a1 --- /dev/null +++ b/MAINTAINERS.md @@ -0,0 +1,70 @@ +# Maintainers Guide + +This guide is intended for maintainers - anybody with commit access to one or +more Code Pattern repositories. + +## Methodology + +This repository does not have a traditional release management cycle, but +should instead be maintained as as a useful, working, and polished reference at +all times. While all work can therefore be focused on the master branch, the +quality of this branch should never be compromised. + +The remainder of this document details how to merge pull requests to the +repositories. + +## Merge approval + +The project maintainers use LGTM (Looks Good To Me) in comments on the pull +request to indicate acceptance prior to merging. A change requires LGTMs from +two project maintainers. If the code is written by a maintainer, the change +only requires one additional LGTM. + +## Reviewing Pull Requests + +We recommend reviewing pull requests directly within GitHub. This allows a +public commentary on changes, providing transparency for all users. When +providing feedback be civil, courteous, and kind. Disagreement is fine, so long +as the discourse is carried out politely. If we see a record of uncivil or +abusive comments, we will revoke your commit privileges and invite you to leave +the project. + +During your review, consider the following points: + +### Does the change have positive impact? + +Some proposed changes may not represent a positive impact to the project. Ask +whether or not the change will make understanding the code easier, or if it +could simply be a personal preference on the part of the author (see +[bikeshedding](https://en.wiktionary.org/wiki/bikeshedding)). + +Pull requests that do not have a clear positive impact should be closed without +merging. + +### Do the changes make sense? + +If you do not understand what the changes are or what they accomplish, ask the +author for clarification. Ask the author to add comments and/or clarify test +case names to make the intentions clear. + +At times, such clarification will reveal that the author may not be using the +code correctly, or is unaware of features that accommodate their needs. If you +feel this is the case, work up a code sample that would address the pull +request for them, and feel free to close the pull request once they confirm. + +### Does the change introduce a new feature? + +For any given pull request, ask yourself "is this a new feature?" If so, does +the pull request (or associated issue) contain narrative indicating the need +for the feature? If not, ask them to provide that information. + +Are new unit tests in place that test all new behaviors introduced? If not, do +not merge the feature until they are! Is documentation in place for the new +feature? (See the documentation guidelines). If not do not merge the feature +until it is! Is the feature necessary for general use cases? Try and keep the +scope of any given component narrow. If a proposed feature does not fit that +scope, recommend to the user that they maintain the feature on their own, and +close the request. You may also recommend that they see if the feature gains +traction among other users, and suggest they re-submit when they can show such +support. +