Skip to content

Latest commit

 

History

History
85 lines (53 loc) · 5.93 KB

contributing.md

File metadata and controls

85 lines (53 loc) · 5.93 KB
Raw

Contributing to Pyrsia

We like to pronounce it /pərsēə/ or [ pir-see-ah ]. 😉 Listen here.

The following summarizes the process for contributing to the Pyrsia project.

Code of Conduct

We follow the OpenSSF's 🛡️ (Open Source Security Foundation) code of conduct.

Dev-flow

Pyrsia follows the "Forking Workflow". You can see GitHub's About collaborative development models for more details.

To contribute follow the next steps:

  1. Comment in the corresponding issue that you want to contribute. If there is no open issue, we strongly suggest opening one to gather feedback from the team.
  2. Fork the Pyrsia repository and create a branch from the main branch and develop your fix and/or feature as discussed in previous step. See About forks for help.
  3. Try to keep your branch updated with the main branch to avoid conflicts. See Syncing a fork.
  4. Please make sure to link any related issue to the PR, referring to the issue of step 1.

When opening your PR, CODEOWNERS should fire and assign your request to one or more pyrsia organization teams. They will then review and help with merging accepted changes.

Pull Requests

PRs are a great way to share what you are working on and get early feedback. Make sure to open as a draft so other know the state. Before opening a pull request it's recommended to "clean your commit history", this makes it easier to review by breaking down the work and removing some of the clutter and noise of regular development. Check out this article and this guide to learn more.

When PRs are "read for review", there's a few house keeping 🧹 items to keep in mind:

  • Make sure to give your PRs a great title. These will be the commit messages and should be treated as such.
  • Do not worry about squashing, that is done automatically by GitHub.
    • It's ideal to clean up any commit messages before confirming the merge to reduce the noise.
  • Try to avoid force pushing your branch. GitHub forces reviewers to restart since it loses their progress.
  • When synchronizing your branch, prefer using merge. Check out Syncing a fork for more details and guidance.

Approval Processes

Request reviews from the @pyrsia/collaborators team to assign team members for the PR. They are responsible for making sure the PR is reviewed in a timely manner; they are expected to make time. Approvals are not limited to the assigned reviewers, anyone on the team can and should review each PR.

Specific individuals or "topic teams" may also be assigned (only after collaborators has been assigned so the GitHub automation can work properly). Approvals from "topic teams" are highly sought after but pull requests are strongly encouraged to include reviews from the team at large.

All pull requests require:

  • 2 approvals (from any team member)
  • All required checks passing

If there are optional checks that fail, it's best to ask the reviewers and bring up the failure at the next team meeting.

Merging Suggestions

  • Cleanup the commit message and description, remove lines like "wip" or "fix typo" so the reader has less clutter to sort through

Project Board

Learn more

All open tickets related to ongoing work are tracked in a GitHub project board. Up coming, future and completed work here.

Labels

Learn how

Labels are used to sort and describe issues and pull requests. Some labels are usually reserved for one or the other, though most labels may be applied to both.

They may be used to:

  • highlight the state of completion, such as "Triage" or "Blocked"
  • organizing according to the source code relevant to issues or the source code changed by pull requests, such as "Blockchain", "Discovery", or "Network"

Legal

You will need to complete a Contributor License Agreement (CLA) before your pull request can be accepted. This agreement testifies that you are granting us permission to use the source code you are submitting, and that this work is being submitted under appropriate license that we can use it.

For each pull request, all commit authors are required to sign the Contributing License Agreement. We are using CLA Assistant which requires commit email to match your GitHub account. You can view signed CLAs through their site.