contributing documents

[TangoYankee]

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.
  • Datetime: 1300, March 10
• Address comments on code and resolve requested changes
• Merge own code

Description

Issue: #42

• Added labels checklist, affected components, and technical resources to issues
• Added OpenOakland Code of Conduct
• Added Contributing document
• Removed redundant parts from contributing section of readme

[theecrit]

Some notes on the Contributing doc:

1. Under "Commuication," OO's Slack can be accessed by completing this form: https://docs.google.com/forms/d/e/1FAIpQLSee_qdE0qCmhufJC94MmSRVDLPAhhFJO4QMzuC31Kh0lxI_Mg/viewform (people aren't required to attend Hack Night for access).

2. Under "Documentation," I'm concerned that linking to a specific Slack file is going to require too much overhead to keep that link updated. Wireframes are likely to go through multiple iterations, so we'll need to minimize versioning issues. Ultimately, any front-end issues should require wireframes to be attached as an acceptance criteria, which will ensure only the appropriate version is referenced by whoever tackles said issue. Which leads me to...

3. I'd like us to add a section for "Acceptance Criteria" to Issue templates. This should cover how we determine whether something is ready to push (e.g. how we define "ready" for things like design/UX/copy).

4. Under "Workflow" #1: what is the "Project Outline"? I've not heard of that doc. Perhaps meant to be "Project Overview"? Would be good to make that an active link, too.

I think that covers all my feedback. Thanks for pulling this together.

[theecrit]

Ah, looks like you addressed #4 while I was typing.

[TangoYankee]

1. I'll add that option
2. I share the concern about linking to a fixed wireframe. Would it be possible to have a solution similar to a google document, where people can make comments and request changes on a centralized wireframe?
3. I don't understand how "Acceptance Criteria" are different from a "Solution Description". From my understanding, once a design fulfills a solution and there is a consensus on moving forward, it's "accepted"

[r-b-g-b]

Great additions! I'll make an issue about going into more detail about installation, getting going with code contributions.