Permalink
Browse files

Update contributing.md

  • Loading branch information...
Jeff Boykin GitHub
Jeff Boykin authored and GitHub committed Jul 20, 2016
1 parent e69183c commit 3ba9b58e0800c11d32382bee75f086be46da141e
Showing with 8 additions and 61 deletions.
  1. +8 −61 contributing.md
@@ -4,85 +4,42 @@ Our instructor community has grown tremendously, and local markets do so much to

Included in this file is information about:

- [__________ GitHub Community](#the-community)
- [Contributing Guidelines for Issues or Pull Requests](#contributing-guidelines-issues-and-pull-requests)
- [Using Labels Appropriately](#labels)
- [Contributor Expectations](#contributors-expectations)

_Note: A lot of the language in this Readme has been taken and adapted from GitHub's guidelines about contributing to open-source projects_.


## The Community

We've broken down the community as follows:

- **Maintainers** (write access to the repository): Instructional Designers & Product Managers

- **Contributors** (everyone who can open and have a pull request merged into a project): Instructors, Subject Matter Experts

- **Community Members** (users who often use and care deeply about the project and are active in discussions for future updates): GA Producers & Regional Directors'

## Contributing Guidelines: Issues and Pull Requests

Contributing back should take the form of issues or pull requests depending on the nature of the contribution. Contributions via GitHub pull requests and issues should *only* be created for curriculum or WDI fundamentals. Production-related feedback or questions should be submitted via [GA's helpdesk](ga.co/helpdesk).
Contributing back should take the form of issues or pull requests depending on the nature of the contribution. Contributions via GitHub pull requests and issues should *only* be created for curriculum. Operations-related feedback or questions should be submitted to your GA point of contact via email.

#### Create an Issue

If you find a bug in a lesson, lab, or Readme file (and you don’t know how to fix it) if have higher-level questions about the scope or sequence of a unit or lesson, or have a general question about the curriculum, create an issue!

Here are a few tips when creating an issue:

- Check existing issues for your issue. Duplicating an issue is slower for both parties so search through open and closed issues to see if what you’re running into has been addressed already.

- Be clear about your feedback or question by using a label and thorough details in your issue description: what lesson were you using? what should have happened that didn't happen? how would you change a week? etc.

- Include error messages, logs, or screenshots

- Paste error output or logs in your issue or in a Gist. If pasting them in the issue, wrap it in three backticks so that it renders nicely.

#### Create a Pull Request

If you’re able to patch the bug, create a new lesson/lab, or correct some syntax/spelling yourself – fantastic! Make a pull request with your changes! Be sure you’ve read our [styleguide](templates/styleguide.md) and follow accordingly as it will speed up the merging process. Once you’ve submitted a pull request, the owners and maintainers will carefully review your code/suggestions to determine whether or not more action is needed or the request should be merged or closed.
If you’re able to patch the bug or correct some syntax/spelling yourself – fantastic! Make a pull request with your changes! Once you’ve submitted a pull request, the owners and maintainers will carefully review your code/suggestions to determine whether or not more action is needed or the request should be merged or closed.

Here are a few tips when creating a pull request:

- All pull requests should be submitted from a feature branch on your local fork, straight to *generalassembly-studio/adi-course-materials/master*.

- Before submitting a pull request, please make sure your local feature branch is up to date with generalassembly-studio/adi-course-materials/master:
- All pull requests should be submitted from a feature branch on your local fork, straight to *generalassembly-studio/android-programming-101-cwe-materials/master*.
- Before submitting a pull request, please make sure your local feature branch is up to date with generalassembly-studio/android-programming-101-cwe-materials/master:

```bash
$ git remote add upstream git@github.com:generalassembly-studio/adi-course-materials
$ git remote add upstream git@github.com:generalassembly-studio/android-programming-101-cwe-materials
$ git fetch --all
$ git checkout -b my-feature-branch upstream/master
```

- Contribute in the style of this repository to the best of your abilities. This may mean using indents, semi colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future. Again, look at our [styleguide](resources/guidelines/styleguide.md) for more information.

- If you're submitting a new _lesson_, _lab_, or _homework_ resource, **create a feature branch** for each individual resource. Lesson branch naming should follow the same naming style and convention we use for folders. For example:

```bash
$ git checkout master
On branch master
nothing to commit, working directory clean
$ git checkout -b intro-to-relational-data-modeling
Switched to a new branch intro-to-relational-data-modeling
```

- If a lesson/lab/homework both have the exact same name, just denote which with `-lesson` or `-lab`.

```bash
$ git checkout -b layouts-partials-and-views-lesson
```

... or ...

```bash
$ git checkout -b layouts-partials-and-views-lab
```

- Again, if submitting a new lesson or lab resource, please make sure the resources are in the standard [lesson](templates/lessons) and [lab](templates/labs) templates.

- Contribute in the style of this repository to the best of your abilities. This may mean using indents, semi colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.

##### Open Pull Requests

@@ -99,30 +56,20 @@ As discussed, please use labels to make it easier for owners and maintainers to
</p>

- **Bug Fix**: Used by contributors for either pull requests that contain solutions or issues reporting a bug

- **Discussion/Question**: Used by maintainers, owners, or contributors on issues for higher-level discussions or questions about the curriculum

- **Duplicate**: Used by maintainers or owners to classify duplicate issues or pull requests

- **Enhancement/Suggestion**: Used by contributors to suggest changes in an issue or enhance a lesson/lab for various reasons

- **Help Wanted**: Used by maintainers, owners, or contributors to invite others to collaborate; this will be used in conjunction with assignment

- **Needs Review**: Used by maintainers or owners to call for technical support or a second set of eyes

- **Needs Revision**: Used by maintainers or owners to notify contributors that more work is needed before a merge

- **New Resource**: Used by contributors to submit a new lesson, lab, or homework


## Contributors Expectations
## Contributor Expectations

Given the bandwidth of the owners and maintainers, issues and pull requests will be addressed about once a week, by a group of owners and maintainers, going forward. The outcome of the issue or pull request is likely to fall into one of three buckets:

1. **Merged / Addressed** - The feedback, solution, new resource, or bug fix is merged in or addressed immediately. Bug fixes will take priority and, as long as merge conflicts are not an issue, will be merged, immediately.

2. **Prioritized for Product Sprint** - If the feedback or pull request cannot be addressed in the time dedicated each week, but the owners and maintainers acknowledge the immediate impact, the pull request or issue will be brought to the next sprint planning meeting (these occur every two weeks) and appropriate time will be budgeted to address and work through the issue or pull request.

3. **Logged into the feedback log** - If the feedback or pull request cannot be addressed in the time dedicated each week, and the owners and maintainers do not see the immediate value in prioritizing this feedback, it will be closed and logged into the product feedback log to be used for future iterations and releases of the curriculum.
3. **Logged into the feedback log** - If the feedback or pull request cannot be addressed in the time dedicated each week, and the owners and maintainers do not see the immediate value in prioritizing this feedback, it will be closed and logged into the product feedback log to be used for future iterations and releases of the curriculum.

Expect all your issues or pull requests to be commented on by an owner or maintainer. If after a week, a dialogue does not ensue and further detail or action is needed, the issue or pull request may be closed.

0 comments on commit 3ba9b58

Please sign in to comment.