contributing documents

.github/ISSUE_TEMPLATE/bug_report.md

@@ -36,3 +36,18 @@ If applicable, add screenshots to help explain your problem.
 
 **Additional context**
 Add any other context about the problem here.
+
+**Labels**
+- [ ] Add a status label
+  - `backlog`
+  - `discussing`
+  - `ready`
+  - `implementing`
+- [ ] Add a `bug` label
+- [ ] Add additional labels as needed
+
+**Affected Components (For Developers)**
+List what pages or backend files will need to be added, removed, or changed
+
+**Technical Resources (For Developers)**
+Add links to appropriate documentation. Describe possible code implementations. 

.github/ISSUE_TEMPLATE/feature_request.md

@@ -18,3 +18,17 @@ A clear and concise description of any alternative solutions or features you've
 
 **Additional context**
 Add any other context or screenshots about the feature request here.
+
+**Labels**
+- [ ] Add a status label
+  - `backlog`
+  - `discussing`
+  - `ready`
+  - `implementing`
+- [ ] Add additional labels as needed
+
+**Affected Components (For Developers)**
+List what pages or backend files will need to be added, removed, or changed
+
+**Technical Resources (For Developers)**
+Add links to appropriate documentation. Describe possible code implementations. 

.github/code_of_conduct.md

@@ -0,0 +1,77 @@
+# Code of Conduct
+
+This document is adapted from Code for America’s [Code of Conduct](https://github.com/codeforamerica/codeofconduct/blob/master/README.md) and Anti-Harassment Policy.
+
+## [OpenOakland’s Code of Conduct](http://openoakland.org/code-of-conduct/)
+
+Our Code of Conduct aims to produce an environment that is inclusive and collaborative by guarding each person’s dignity and sense of security.
+
+The OpenOakland community expects that  OpenOakland activities, events, and digital forums:
+
+1. OpenOakland is a professional environment. Behaviors that are inappropriate around your boss are inappropriate here.
+2. Respect personal space. As a policy, we discourage hugs and other physical contact.
+3. Err on the side of political correctness. Don’t say or write anything that can be misunderstood as insensitive.
+
+OpenOakland reserves the right to ask anyone in violation of these policies not to participate in OpenOakland network activities, events, and digital forums.
+
+We have put together a toolbox for achieving the environment set out above.
+
+For interpersonal interactions:
+
+1. Presume the value of others. Differing ideas, skills and contributions all play a crucial role in the operation of each project.
+2. Endeavor to include technical and non-technical skill sets in your project.
+3. Encourage members and participants to listen as much as they speak.
+
+When considering a new project or working on a current one:
+
+1. Strive to build tools that are open and free technology for public use.
+2. Consider access for and input from those who are traditionally excluded from the civic process.
+3. Encourage participation from all community members in the planning, design, and implementation of civic tech.
+4.  Create and maintain positive relationships with community partners, community members and local government staff and actively involve them in the decision making process. 
+
+## OpenOakland’s Anti-Harassment Policy
+
+This anti-harassment policy is based on the [example policy](http://geekfeminism.wikia.com/wiki/Conference_anti-harassment/Policy) from the Geek Feminism wiki, created by the Ada Initiative and other volunteers.
+
+This policy is based on several other policies, including the Ohio LinuxFest anti-harassment policy, written by Esther Filderman and Beth Lynn Eicher, and the Con Anti-Harassment Project. Mary Gardiner, Valerie Aurora, Sarah Smith, and Donna Benjamin generalized the policies and added supporting material. Many members of LinuxChix, Geek Feminism and other groups contributed to this work.
+
+<hr>
+All OpenOakland network activities, events, and digital forums and their staff, presenters, and participants are held to an anti-harassment policy, included below.
+
+OpenOakland is dedicated to providing a harassment-free experience for everyone regardless of gender, gender identity and expression, sexual orientation, disability, physical appearance, body size, race, age, or religion. We do not tolerate harassment of staff, presenters, and participants in any form. Sexual language and imagery is not appropriate for any OpenOakland event or network activity, including talks. Anyone in violation of these policies may expelled from OpenOakland network activities, events, and digital forums, at the discretion of the event organizer or forum administrator.
+
+Harassment includes but is not limited to: offensive verbal or written comments related to gender, gender identity and expression, sexual orientation, disability, physical appearance, body size, race, religion; sexual images in public spaces; deliberate intimidation; stalking; following; harassing photography or recording; sustained disruption of talks or other events; inappropriate physical contact; unwelcome sexual attention; unwarranted exclusion; and patronizing language or action.
+
+If a participant engages in harassing behavior, the organizers may take any action they deem appropriate, including warning the offender or expulsion from OpenOakland network activities, events, and digital forums.
+
+If you are being harassed, notice that someone else is being harassed, or have any other concerns, please contact a member of the event staff or forum administrator immediately. You can contact them at [EVENT ORGANIZER/FORUM ADMINISTRATOR EMAIL AND PHONE NUMBER]. Event staff or forum administrators will be happy to help participants contact hotel/venue security or local law enforcement, provide escorts, or otherwise assist those experiencing harassment to feel safe for the duration of the event.
+
+If you cannot reach an event organizer or forum administrator and/or it is an emergency, please call 911 and/or remove yourself from the situation.
+
+You can also contact OpenOakland about harassment at safespace@openoakland.org and feel free to use the email template below.  The OpenOakland Core Team acknowledge that we are not always in a position to evaluate a given situation due to the number of events and the fact that our team is not always present. However, we are hopeful that by providing these guidelines we are establishing a community that jointly adheres to these values and can provide an environment that is welcoming to all.
+
+We value your attendance and hope that by communicating these expectations widely we can all enjoy a harassment-free environment.
+Email Template for Anti-Harassment Reporting
+
+SUBJECT: Safe Space alert at [EVENT NAME]
+
+I am writing because of harassment at an OpenOakland event, (NAME, PLACE, DATE OF EVENT).
+
+You can reach me at (CONTACT INFO). Thank you.
+
+Code of Conduct Complaints will be reviewed by the Ombudspersons. The full process is stated in the [Review of Code of Conduct Violations documentation](https://docs.google.com/document/d/166AtSw9ygV4NW0_P9XrYDgx_pt7gtjkePXAoUQ0_KrA/edit#heading=h.y9wfwqjg139g).
+
+
+## Image and Video Policy
+
+OpenOakland respects members’ and event attendees’ privacy—online and offline. Creating a safe and comfortable space for all people to participate and contribute fully is our first priority in OpenOakland spaces. When capturing video, photographic, or audio images in all OpenOakland spaces, consent by subjects is paramount.
+
+To this end, OpenOakland’s official photo and video policy is an opt-in model, meaning it is the photographer’s onus to gain consent from all individuals being photographed/filmed. Images and videos captured officially to be used on OpenOakland promotional materials are captured and used at the discretion of the Communications Leads.
+
+Any OpenOakland member capturing images on behalf (meaning they are capturing images, video, or audio that will be posted or used on official OpenOakland channels, websites, or social media accounts) of OpenOakland must follow the opt-in policy. If a photo shoot (meaning a pre-arranged event specifically for capturing images, video, or audio for the purpose of being used for promotion of OpenOakland events or projects) is being arranged, consent should be provided in writing by each “model” signing a waiver that stipulates that the images taken are only for OpenOakland promotions. At events, name badges that clearly state opt-in or out should be worn by all attendees. When events are held in public spaces where photograph or videotape anyone is legal, the rules stipulated above still apply. Our goal is not to simply meet legal requirements, but to foster a space that is comfortable for everyone.
+
+In the event that name tags are not available, anyone capturing images, video, or audio must acquire verbal consent of all those persons whose image is being captured ideally before any image, video, or audio is captured, and definitely prior to making any collected content public e.g., before tweeting, or distributing through other social media platforms. Any complaints could result in a take down of images on media channels. If repeated complaints are filed, OpenOakland steering committee members may take disciplinary action.
+
+Related reading:
+
+https://geekfeminism.org/2009/10/11/conference-recordings-and-harassment/

.github/contributing.md

@@ -0,0 +1,74 @@
+# Contributing
+Welcome to the WOAQ Contributing document!
+
+## Code of Conduct
+Please review the Open Oakland [Code of Conduct](https://github.com/openoakland/woeip/tree/master/.github/code_of_conduct.md)
+
+## Communication
+WOAQ communinicates primarily through the [OpenOakland Slack Workspace](https://openoakland.slack.com), in the #woaq channel. Access to the Slack Workspace is granted by attending an [OpenOakland Hacknight](http://openoakland.org/) and onboarding with the community organizers. Once a member of the Slack Workspace, you may navigate to the #woaq channel.
+
+## Documentation
+Please reach out in the #woaq Slack Channel or at an OpenOakland Hacknight to request access to any private documents
+- [Project Outline](https://bit.ly/WOAQoverview) for long term strategy
+- [Wireframes](https://slack-files.com/T02FEGG84-FGQFB5NA2-72b7ae10b5) for website design
+- [Trello Board](https://trello.com/b/EBnxZHmx/west-oakland-air-quality) for project management
+- [GitHub Issues](https://github.com/openoakland/woeip/issues) for code management
+- [Google Drive](https://drive.google.com/drive/folders/1XQ9ckXD4z3G6NWXcd2PO8GtK7zcucBfx) to preserve historical documents
+
+## Workflow
+These are general guidelines on the flow from design to implementation
+1. Product needs are identified by consulting with WOEIP and its citizen scientists.
+   - Notes are generally kept in the Google Drive. More refined thoughts are moved into the Project Outline
+2. Product needs are translated into project requirements and documented in the Trello Board.
+   - Guidance on contributing to the Trello Board are available on the [Instructions Card](https://trello.com/c/msbASe3F)
+3. The project requirements are translated into wireframe designs
+4. GitHub issues are used to translate project requirements and wireframes into actionable code
+5. Github pull requests implement the code agreed upon in the GitHub issues
+
+## Code Development
+
+### Forks and Branches
+Developers generally work on the original OpenOakland WOEIP repository, rather than creating personal forks. <br>
+Some developers identify their branches with a personal code, followed by a slash, and then the branch name. This practice is encouraged but not enforced.
+- ie) [initials of developer]/[branch name] 
+- ex) ty/add-index
+
+### Repository Permissions
+Write permissions can be requested by contacting the development team at an OpenOakland hack night. Contributors without a code review, discussion in an issue, or commit in past 60 days will have their write permissions rescinded.
+
+
+### Issues
+Issues are the primary means of coordinating code implementation.<br>
+Issues will have one of four status labels:
+1. `backlog`: The feature is not currently needed or its application is not fully defined
+2. `discussing`: The feature is fully defined and its code design is being outlined
+3. `ready`: The code design is outlined. It needs to be assigned a developer
+4. `implementing`: The code is actively being written
+
+Status labels can be combined with feature labels:
+1. `bug`
+2. `testing`
+3. etc
+
+Status and bug labels are mandatory. Other labels are optional.<br>
+Developers looking to make code contributions should assign `ready` issues to themselves and change the label to `implementing`.
+
+
+### Pull Requests
+A pull request should simply implement a solution that was already established in an issue, rather than include discussions on how to implement the project design. To the maximum extent possible, it should address only one bug or feature. Limiting the scope of pull requests simplifies the review process and accelerates development.
+
+Pull requests must pass the Travis checks before merging into the `master` branch. These checks are a linting check and code tests. They can be accomplished locally by entering the project shell (`make local.shell`) and running them separately (`make quality` and `make test`) or together (`make validate`). Please pass these checks locally, before making a pull request. Other contributors will gladly help with any tests you are struggling to pass.
+
+Only one approving review is required to merge into the `master` branch. However, please leave the pull request open for at least **36 hrs**. As a volunteer project, contributors may not be able to immediately make comments. Adding a slight delay allows for multiple reviewers to provide input. However, this is a soft rule. It is not meant to be applied so rigidly that it creates unnecessary delays and inefficient code development.
+
+Once the Travis checks are passing, any requested code changes are resolved, and **36 hours** have passed, the developer who opened the pull request should merge their own code.
+
+### Style Guidelines
+Please follow these guidelines during development:
+- [PEP 8](https://www.python.org/dev/peps/pep-0008/) enforced by [pylint]
+- Docstrings in [Numpy Stlye](https://sphinxcontrib-napoleon.readthedocs.io/en/latest/example_numpy.html#example-numpy)
+- [Django Templating](https://oncampus.oberlin.edu/webteam/2012/09/architecture-django-templates)
+
+### Reporting Bugs and Security Concerns
+Please open an issue to report any bugs.<br>
+To report or discuss a security concern, email Tim Miller at miller.tim108@gmail.com or reach out to the #woaq Slack channel.

.github/pull_request_template.md

@@ -0,0 +1,25 @@
+---
+name: Pull Request
+about: Request merging changes into the code base
+title: ''
+labels: ''
+reviewers: ''
+
+---
+
+## Checklist
+- [ ] Add description
+- [ ] Reference open issue pull request addresses
+- [ ] Pass linting check
+  - complete on the local machine with `make local.shell` `make quality`
+- [ ] Pass functional tests
+  - complete on the local machine with `make local.shell` `make test`
+- [ ] Request code review
+  - Please allow **36 hours** from opening a pull request before merging a pull request- even if it has already recieved an approving review.
+- [ ] Address comments on code and resolve requested changes
+- [ ] Merge own code
+
+## Description
+Issue: #
+
+*Brief description of solution*

README.rst

@@ -20,9 +20,7 @@ WOEIP has collected Air Quality (AQ) data over several years. The current AQ dat
 
 How To Contribute
 -----------------
-There are several ways to contribute to WOAQ, including product design, community engagement, project management, and engineering. A general project overview is available in the `WOAQ Google Document <https://docs.google.com/document/d/1nMpRN8zOn-Sq9ocrVcOY0HZI2JnL5R7wEKje_YgVwRk/edit>`_. Current project issues and goals are organized on the `WOAQ Trello board <https://trello.com/invite/b/EBnxZHmx/6e43b909891f622463a67da64dbb8101/west-oakland-air-quality>`_. Please review the `Instructions Card <https://trello.com/c/msbASe3F>`_ before editing the Trello Board. 
-
-**TODO:** create a full contributing document
+There are several ways to contribute to WOAQ, including product design, community engagement, project management, and engineering. Visit `Contributing.md <https://github.com/openoakland/woeip/tree/master/.github/contributing.md>`_ for more information.
 
 Reporting Security Issues
 -------------------------
@@ -160,3 +158,4 @@ Note that this process will take at least 10 minutes for the initial database se
 may also take up to 20 minutes.
 
 The resulting state information will be saved to S3.
+