Firstly, a heartfelt thank you for making time to contribute to this project! <br />

As a distributed team, <br /> we need a contributing guide with simple steps people can easily follow <br /> so that we avoid confusion and keep our communication consistently crystal clear! <br />

Our contribution steps in a nutshell:

<!-- The text under the magnifying glass says: "validate the need exists" "or undesired behavior" "from the user's perspective" I believe this should be something like "validate the need or" "undesired behavior exists" "from the user's perspective" but the image is not in the repo so I can't modify it myself. -->

Please inform us if anything is unclear or if you have a suggestion for how to simplify/streamline it!

Contents Guide

• Part 1: Describe your Question, the Idea or User Story in an Issue
  • Step 1 Check if the issue already exists
  • Step 2: Create a new user story or report an issue
  • Step 3: Submit the new issue and wait for validation
• What do I do next?
• Part 2: Validate the Need (User Story) or Issue Exists
  • Step 1: Confirm the need
  • Step 2: Assign a priority to the issue
• Part 3: Do the Work!
  • Step 1: Estimate the time required
  • Step 2: Assign yourself the issue
  • Step 3: Open the Pull Request (PR) and assign it for review
  • Step 4: Reviewers review and merge PR
• Example User-focused "Story" Descriptions
  • Example User-focused "Story" Descriptions
  • Writing Good Issues
• Practical Note on Time Estimation for a Story/Task
  • Revising a Time Estimate
  • Estimating for open source projects without sprints
• Notes on Creating Good Pull Requests
  • 1. Keep it Small and Simple
  • 2. Descriptive Pull Request Title and Description
  • 3. PR Etiquette
• Creating a New Repository
  • Use Cases for Creating a New Repo
  • How?
  • Minimum Requirements for a New Repository
• Forking Repositories
• General Notes <br/>

Part 1: Describe your Question, the Idea or User Story in an Issue

Why Use GitHub Issues...?

Everything starts with a thought. We collect all our thoughts in GitHub "issues". <br /> The issue can then be discussed, validated and worked on as a team while keeping everyone informed. <br /> We use issues to log our user stories, sub/technical tasks and any progress towards solving the issue, <br /> this ensures we have a single source of truth that everyone can easily see!

Step 1: Check if the Question/Idea/Story/Issue Already Exists Using GitHub Search

1. Please take a moment to read through the existing stories/issues for the project <br /> to familiarize yourself with the current "backlog". (There is a chance what you are thinking has already been described by someone else...)

2. Try searching through the existing issues for keywords associated with the story/issue you want to create. <br /> For example, you could use https://github.com/dwyl/time/issues?utf8=%E2%9C%93&q=is%3Aissue%20app+icon if "app" and "icon" were the keywords for what you have in mind and you were searching in the "Time" project. <br />

3. If you find an existing issue that matches what you were looking for, please click on the title of the issue, read the description to confirm that it's what you are looking for, then comment on it so we know more than one person has the need/issue. <br />

Note: If there is already an issue for what you were thinking, you can skip steps 2 & 3. as there's no need to create a duplicate new issue.

1. Otherwise, once you are reasonably sure there is no existing question/issue/story covering what you have in mind, please create a new issue (see next step!)

Step 2: Create a New User Story or Report an Issue

1. Using the New Issue button, create an issue for the user story (feature request, expected or unexpected behaviour, or question) you have in mind.

Note: If you are new to writing "User Stories", please checkout out our Example User-focused Story Descriptions section in the "Notes" section below!

Step 3: Submit the New Issue!

1. Submit the new issue!

2. Once you submit a new issue for a User Story or Question/Issue/Bug, a member of the team (typically the Product Owner) will review the issue.

3. That's it from the side of the issue creator! (Thank you!)

What do I do Next...?

Once a new issue has been created, it must be "validated" by a different member of the team/organisation. (see: "Part 2" below...)

:star: Star the Project! :star: (share the love!)

<!-- _After_ you have ***contributed*** to the project, _e.g: by commenting on or creating an issue_, <br /> -->

If you've found the project interesting, helpful or useful in any way, please star the repository on GitHub! <br /> Stars show other members in the developer community that it's a worthwhile project or learning resource and one that can offer value to other developers like you! 🌟

<br />

Questions?

<!-- should the questions be at the END of this doc or will people not scroll that far? see: https://github.com/dwyl/contributing/pull/63#pullrequestreview-18508277 My idea was to structure the content in in the order a Complete Beginner (or at least a Person who is new to our Contributing Guide) will *think* of it... So I've submitted my issue/question/bug-report i.e: now what...? So having these questions and corresponding answers here seemed logical... but I'm equally happy for someone to re-org them into a FAQ section with other contributing/process-related questions. please make suggestions in issues! thanks!! -->

Why Does the Issue Need to be Validated? >> One Word: Communication

This may initially feel a bit "bureaucratic" but we urge you not to think of it as <br /> "jumping through hoops". We think of issue validation as something that:

• ensures that everyone on the project is aware of the issue/idea/story.

• saves you time by avoiding duplicating effort!

The Product Owner (PO) or Project Lead (PL) has detailed knowledge of the current issue backlog and all previous ("closed") issues. <br /> They know how features/functionality should work and can validate things from the user's perspective. <br /> Most importantly the PO/PL knows if someone else is already working on the issue... <br /> And, sometimes the exact same issue has been "***solved befor