Skip to content

Latest commit

 

History

History
171 lines (120 loc) · 7.97 KB

CONTRIBUTING.md

File metadata and controls

171 lines (120 loc) · 7.97 KB
Raw

Contributing To JobSeeker

👍🎉 First off, thanks for taking the time to contribute! 🎉👍

The following is a set of guidelines for contributing to JobSeeker and its packages, which are hosted in the RedHat-Beyond Organization on GitHub. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.

Contact

You are welcome to contact us through slack, with link #os-07-group4 on beyond slack.

Our Team

Core Reviewers

Table Of Contents

Getting Started

  • To get an overview of the project, read the README.
  • Make sure you have all the prerequisites so you can contribute to this project.

New Contributor Guide

Here are some resources to help you get started with open source contributions:

Conventions

Consider Starting The Issue / Commit / PR Title With An Applicable Emoji

These are the conventional emojis for our project:

Name Emoji Text Of Emoji To Provide When To Use
FEATURE 🚀 :rocket: When working on a new feature.
DOC 📝 :memo: When writing docs.
BUG 🐛 :bug: When fixing a bug.
STRUCT 📁 :file_folder: When rearranging files for better structure or orientation.
IMPROVE 🏇 :horse_racing: When improving performance of an existing feature.

The "Text Of Emoji To Provide" should be the first word in the title.

Examples

  • The PR title of:

    :memo: Updating `README.md`'s Description

    Will look like this:

  • The commit title of:

    :memo: Adding A `CONTRIBUTING.md` File

    Will look like this:

Issues & PRs

When contributing to this repository, please first discuss the change you wish to make via an issue.

Issues

Create A New Issue

If you spot a problem with the docs, search if an issue already exists. If a related issue doesn't exist, you can open a new issue.

  • Creating A New Issue That Contains Many Tasks Required To Be Done

    If that is the case, then consider making a separate "checkbox" for each task.

    Example

    The issue content of:

    We need to complete the following tasks to be able to make coffee:
  - [X] Buy coffee.
  - [ ] Buy milk.
  - [ ] Boil water.

    Will look like this:

Solve An Issue

Scan through our existing issues to find one that interests you. You can narrow down the search using labels as filters, or a specific word in the issue title. If you find an issue to work on, you are welcome to open a PR with a fix.

Commit Your Update

Use Flake8 along your code before commiting, and verify it passes all assertions.

Commit the changes once you are happy with them.

Once your changes are ready, don't forget to self-review to speed up the review process ⚡.

Then, you may upload your changes by creating a pull request, also known as a PR.

Pull Requests (PRs)

Before creating a new PR, please verify it is ready for a Core Review. To do so, keep in mind:

  • A PR should only handle a specific feature, bug fix, docs or re-arranging directories and files.
    • New features / fixes must include tests.
  • A PR should be as small as possible. In general, with less than 400 lines of code changes.
  • A PR must be well explained. See our guidlines about writing a good PR description.
  • A PR must be bounded with an Issue. See our guidlines about issues and how to link a PR to an issue.
  • All Github-Actions must pass successfully.

Notes when creating a new PR:

  • Enable the checkbox to allow maintainer edits so the branch can be updated for a merge.
  • Every PR requires at least 2 approvals from our reviewers. You are welcome to assign all of our team to review your PR. After the review, our core reviewers will be able to merge the PR.

Write a good PR description:

Please note in the PR's description:

  • What changes did you make.

    Especially in case of:

    • Renaming or removing files / folders / methods / constants.

  • In case of a big change:

    • A simple and short guide of how to navigate / use your new feature. Try to keep it concise and "to the point" as much as possible. If possible, we prefer you to add a separate markdown file in the docs folder. You can also use embedded mermaid in that markdown, or link to a mermaid.live diagram you have made - either on the PR's description or on a markdown.

  • In case of a frontend change:

    • Add some screenshots of what you have updated.

  • At the bottom of the description:

    • Don't forget to link the PR to an issue if you are solving one.

      For example, in case your PR closes the #2 issue, you should add the following line to your PR's description:

      Close #2
    • In case your PR depends on a PR that wasn't merged yet, you should note that in your PR's description, by linking to the PR it depends on. Our convention here is to mention the keyword of DEPENDS ON for that matter.

      For example, in case your PR depends on the #1 PR, you should add the following line to your PR's description:

      DEPENDS ON #1

  • (Optional):

    • Hyper-link additional information to assist the reviewers.

Once you submit the PR:

  • Our team will review your proposal. We may ask questions or request for additional information. We may ask for changes to be made before a PR can be merged, either using suggested changes or pull request comments. You can apply suggested changes directly through the UI. You can make any other changes in your fork, then commit them to your branch.
  • As you update your PR and apply changes, mark each conversation as resolved.
  • If you run into any merge issues, checkout this git tutorial to help you resolve merge conflicts and other issues.
  • For a PR to be merged, it must be approved by at least 2 team members.