search

dwyl / contributing

:clipboard: Guidelines & Workflow for people contributing to our project(s) on GitHub. Please :star: to confirm you've read & understood! :white_check_mark:
88 stars 9 forks source link

Guidelines #7

Closed jackcarlisle closed 8 years ago

jackcarlisle commented 8 years ago

ready for review

Expands on the guidelines for contributing to a dwyl project

nelsonic commented 8 years ago

@jackcarlisle this looks really good! 👍 We can (should) add a section on "Before You Start" to ensure people don't dive into solving perceived issues or adding features that are not validated/discussed.

nelsonic commented 8 years ago

Issues > Before you Start

  1. First read through the existing stories/issues for the project to familiarise yourself with the current "backlog".
  2. Think of the keywords associated with the story/issue you want to create.
  3. Perform a quick search through the existing issues for the project with the keywords you identified e.g: https://github.com/dwyl/time/issues?utf8=%E2%9C%93&q=is%3Aissue%20email if email was your keyword.
  4. Once you are (quite) sure there is no existing issue/story covering what you want to solve/create move on to creating ... (see: steps below)
jackcarlisle commented 8 years ago

@nelsonic let me know if there are any other sections you want me to add!

nelsonic commented 8 years ago

Issues > Validation

After creating an issue/story (before you estimate the time required or start working on it) get people's input/feedback to confirm that the description of the story is clear, has enough detail and addresses a real need/issue.

This may feel a bit "bureaucratic" but (we find that on balance) it makes for better remote working because less discussion is "lost" and means everyone can follow along regardless of their location.

There must be a comment from at least one other person on the issue acknowledging it and/or confirming the requirement/bug before work can start. This is necessary to avoid doing unnecessary work or incorrect implementation (e.g. someone may have already solved that problem or implemented a similar feature on a different project and can point you in the direction of sample code) or the PO/Client may deem the issue/story to be lower priority than something else on the list.

@iteles thoughts?

nelsonic commented 8 years ago

@iteles please let us know your thoughts... 👍

iteles commented 8 years ago

👀

iteles commented 8 years ago

Looks great! Left a few comments 👍

iteles commented 8 years ago

:tada: Amazing. Thanks!