Skip to content
This repository has been archived by the owner on Oct 2, 2024. It is now read-only.

Latest commit

 

History

History
129 lines (86 loc) · 7.84 KB

CONTRIBUTING.md

File metadata and controls

129 lines (86 loc) · 7.84 KB

Contributing Guide

Contributing Guide

🎥 You can watch the video that Eddie created as a contributing guide. Click on the image to watch the video.

Issues & Pull Requests

Creating an Issue

Before creating an Issue for features/bugs/improvements please follow these steps:

  1. search existing Issues before creating a new issue (has someone raised this already)
  2. if it doesn't exist create a new issue giving as much context as possible (please select the correct Issue type, for example bug or feature)
  3. all Issues are automatically given the label status: waiting for triage and are automatically locked so no comments can be made
  4. if you wish to work on the Issue once it has been triaged and label changed to status: ready for dev, please include this in your Issue description

Working on an Issue (get it assigned to you)

Before working on an existing Issue please follow these steps:

  1. only ask to be assigned 1 open issue at a time
  2. look out for the Issue label status: ready for dev (if it does not have this label, your work might not be accepted)
  3. comment asking for the issue to be assigned to you (do not tag maintainers on GitHub or Discord as all maintainers receive your comment notifications)
  4. after the Issue is assigned to you, you can start working on it
  5. only start working on this Issue (and open a Pull Request) when it has been assigned to you - this will prevent confusion, multiple people working on the same issue and work not being used
  6. do not enable GitHub Actions on your fork
  7. reference the Issue in your Pull Request (for example closes #123)
  8. please do not force push to your PR branch, this makes it very difficult to re-review - commits will be squashed when merged

Notes:

  • it is not sustainable for maintainers to review historical comments asking for assignments before the Issue label status: ready for dev was added; only requests for assignment of an Issue after this label has been added will be considered
  • check the Assignees box at the top of the page to see if the issue has been assigned to someone else before requesting this be assigned to you
  • if an Issue is unclear, ask questions to get more clarity before asking to have the Issue assigned to you
  • only request to be assigned an Issue if you know how to work on it
  • an Issue can be assigned to multiple people, if you all agree to collaborate on the issue (the Pull Request can contain commits from different collaborators)
  • any Issues that have no activity after 2 weeks will be unassigned and re-assigned to someone else

Reviewing Pull Requests

We welcome everyone to review Pull Requests, it is a great way to learn, network and support each other.

DOs

  • be kind and respectful, we use inclusive, gender neutral language (for example they/them instead of guy/man)
  • use inline comments to explain your suggestions
  • use inline suggestions to propose changes

DON'Ts

  • do not be rude, disrespectful or aggressive
  • do not repeat feedback, this creates more noise than value (check the existing conversation), use GitHub reactions if you agree/disagree with a comment
  • do not blindly approve pull requests to improve your GitHub contributors graph

Note: Persistent non-compliance with this Contributing Guide can lead to a warning and/or ban under the Code of Conduct

Maintainers

Criteria for becoming a Maintainer

  1. You are a member of the EddieHub Community

  2. You are active on the EddieHub Discord in helping other members of the community, particularly in the #contributor-support channel

  3. You have a consistent track record of: i. reviewing Pull Requests to the Project. This includes:

    • adding value in your comments
    • helping authors with any difficulties they have
    • referencing the official documentation when appropriate
    • your tone and language is in line with that used in EddieHub ii. creating Issues which have been approved as adding value to the project iii. successfully have Pull Requests merged in relation to an Issue created either by you or another contributor

You will be contacted via DM on Discord to invite you to become a maintainer on the project.

We will ask you to confirm that you are happy to be given this role and have the capacity to become a maintainer. If you confirm you are happy to proceed then we will start the Onboarding process.

Role

  1. Pull Requests: comment, review and merge
  2. Issues
  • Assigning: once the label is status: ready for dev please assign to a contributor in accordance with the Contributing Guide.
  • Bugs: if you agree that the bug is valid then please change the label from status: awaiting triage to status: ready for dev.
  1. Documentation: whilst this always need improving we want to avoid contributions which are aimed only at chasing green squares (for example: making changes that add no value), and we want to ensure that the Documentation remains in the same style and standard. Example: fixing typos adds value, but changing a word from British English (the style used) to American English does not.

  2. Features: so that the project remains manageable, we have a steady roll out of Features and Pull Requests are not left open for too long - please do not remove the status: awaiting triage label and assign.

  3. Keeping the conversation going

A big part of being a Maintainer on this project is reviewing and merging PRs and we also want you to contribute with new ideas through Issues, and putting them into place. However as a Maintainer we are looking for you to help us with keeping the project moving and making sure that we do not have a backlog of Pull Requests and Issues.

This includes:

  • identifying and closing any duplicate Pull Requests and Issues
  • reminding contributors of our Contributing Guide

Note: Keep an eye on the ⁠#repository-maintainers channel on Discord where we make maintainer decisions.

Review

We will consistently review how you are doing as a Maintainer and here are things we will consider:

  • are you consistent (this does not mean you need to be involved every day)
  • are you welcoming and supportive to new contributors
  • are your comments clear to the author of the PR/Issue
  • do your comments make it easier for the author to make the necessary changes and for another maintainer to accept/merge the PR (e.g. inline comments with code change suggestions)
  • are you able to firmly and professionally enforce our Contributing Guide and Code of Conduct

Recognition

At this time we are unable to provide financial compensation to our Maintainers, but we are keen to be able to reward our Maintainers where we can.

By becoming a Maintainer you will have access to:

  • Invitation to Discord Maintainers channel
  • Invitation to participate in Maintainers calls
  • Unofficial mentorship from other Maintainers
  • LinkedIn recommendation from Eddie (and potentially other maintainers)
  • Eddie's paid resources for free, for example digital courses

Renew

A project's maintainers are integral to keep it going and progressing. We do realise that this is a voluntary position and whilst Maintainers may have the time availability now, this may not be the case in the future.

At the time, we have chosen not to have a specific duration for the role, however:

  • if there is no consistent activity by the Maintainer for an extended period of time, they will be removed from the role and and notified (this does not preclude them from becoming a Maintainer on the project again in the future).
  • if at any time a Maintainer wishes to no longer have this role, then they can DM eddiejaoude to be removed