LogoLogo
  • CHAOSS Community Handbook - Table of Contents
  • Handbook Usage
  • ABOUT
    • CHAOSS History
    • Values
    • Roadmap
    • Roles and Responsibilities
    • Community Guidelines
    • Path to Leadership
    • Terminology
      • CHAOSS Specific Terms
      • CHAOSS Committees
      • CHAOSS Community Working Group Terminology
      • CHAOSS Community Mentorship Terminology
    • Terminology Usage
    • General FAQ
  • COMMUNITY
    • Working Groups
      • WG Repository Structure
    • Metrics
      • Releases
      • Translation
      • Metrics FAQ
    • Community Report
    • CHAOSScon
    • CHAOSScast
    • CHAOSS Meetings
  • CONTRIBUTING
    • Development
      • Contributing Workflow
    • Documentation
      • Style Guide
    • Design
      • Design Workflow
      • Design Contribution
      • CHAOSS Visual Identity
    • Outreach
  • MENTORSHIPS
    • Google Summer of Code
    • Google Season of Docs
    • GSoC/GSoD Roles & Responsibilities
    • Outreachy
  • D&I BADGING
    • Overview of the D&I Badging
    • How to contribute
    • Apply for a badge
      • Apply for an In-Person Event
      • Apply for a Virtual Event
    • Reviewing for CHAOSS
      • Apply to Review
      • The Review Process
      • Conflict of Interest Policy
    • Badging Roles
      • Applicant
      • Reviewer
      • Moderator
      • Maintainer
    • The badging-bot
    • D&I Badging Code of Conduct
Powered by GitBook
On this page
  • 🤔 Contribution Approach
  • 💡 Opening an Issue
  • 💻 Contributing to Source Code
  • Forking
  • Cloning
  • Making Commits
  • Sending Pull Request

Was this helpful?

Export as PDF
  1. CONTRIBUTING
  2. Development

Contributing Workflow

General contributing Workflow

PreviousDevelopmentNextDocumentation

Last updated 3 years ago

Was this helpful?

🤔 Contribution Approach

We love pull requests from everyone! We follow the standard Git workflow of fork 👉 change 👉 pull request 👉 merge 👉 update fork 👉change ... (repeat forever). If you are new to open source, we recommend GitHub's excellent guide on "". In addition, please feel free to reach out to any of the maintainers or other community members if you are struggling; we are here to help you learn!

Before getting started, please make sure you've read the README of the respective project repository to get a primer on our project.

💡 Opening an Issue

If you're experiencing an issue with any project or have a question you'd like help answering, please feel free to open an issue in the respective repository of the project. To help us prevent duplicates, we kindly ask that you briefly search for your problem or question in our issues before opening a new one.

Please note that if you open a bug report and your issue does not follow our template, we cannot help you until you have provided us all the relevant information in that format. Respectfully, we do not have the time to try and recreate an error given with minimal or no context, so by providing this information you are helping us help you! You will see this template when you open an issue; click on "Bug Report" and it will be populated with descriptions of what to put in each section. Replace the descriptions with your comments to the best of your ability, and please include screenshots and error logs if applicable.

💻 Contributing to Source Code

Forking

You are required to fork the repository on your Github. Follow the in order to understand the steps to fork any repository

Cloning

You should clone your fork. This step is needed only once. Using as an example below;

$ git clone github.com:your-username/augur.git
$ cd augur/

Making Commits

This is the step where you make desired changes to the codebase inside the respective repository.

Sending Pull Request

At this point, you're waiting on us. We like to at least comment on pull requests within three business days (and, typically, one business day). Once one of our maintainers has had a chance to review your PR, we will either mark it as "needs review" and provide specific feedback on your changes, or we will go ahead and complete the pull request.

NOTE: Any pull requests containing commits that are not signed off will not be eligible for merge until the commits have been signed off.

Writing a well-crafted Git commit message is the best way to communicate context about a change to fellow developers. Seven rules of a great Git commit message are mentioned in .

After you have made the desired changes into your fork version of the repository, you are required to send the pull request with the description explaining your changes. ****

We require all commits to be signed off with a in accordance with the . This can be easily done by using the -s flag when using git commit. For example: git commit -s -m "Update README.md". This can be automated by using a browser plugin like .

How to Contribute to Open Source
guidelines by GitHub
augur
How to Write a Git Commit Message
Checkout Github guide to creating the Pull Request
Developer Certificate of Origin
CHAOSS charter
DCO GitHub UI