Skip to content

Latest commit

 

History

History
45 lines (32 loc) · 2.56 KB

CONTRIBUTING.md

File metadata and controls

45 lines (32 loc) · 2.56 KB

Contribution Guide

Before you join the development, make sure to set up the project on your local machine. Use the installation guide to get you started. Once you have everything set up, feel free to explore and get familiar with the application. Who knows, you might come up with some new feature ideas along the way! :)

Team Norms

Values

Be respectful to other teammates. If there are interpersonal conflicts, we should resolve it in a civil + peaceful way.

If you are blocked on a task, feel free to ask for help in our team-oita slack channel. Go ahead and @channel us if need be!

If we ever are in disagreement, we will vote to reach a consensus on direction.

We should always try to timebox our tasks. However, if we ever fall behind on our work obligations, we can ask team members for help and contribute more during the next sprint.

We want to be communicative as possible. So, we will check slack at least twice a day to check for messages.

Sprint Cadence

Sprints will be 2 weeks long.

Standups

Standups will be ~ 15-20 minutes long and will be a mix of synchronous and asynchronous meetings.

Synchronous standups will be held:

  • Mondays 8PM
  • Wednesdays 10PM

Asynchronous standups will be held on saturdays. One team member will start an Async standup {date} ⬇️ thread, where everyone else's updates will be posted within the thread. Individual posts should detail the following: What was worked on, What is next, Any blockers.

Best Practices

  • Use CamelCase variable names. If it is a constant, capitalize it.
  • Name your branch after the feature or issue you will work on. Keep it concise.
  • Write clear and meaningful commit messages.
  • Using VSCode? Try not to include the .vscode folder in your commit.
  • If working on a UI-related issue, it would be great to include a screenshot(s) of what is going to be rendered.

Pull Request Process

  • Ensure that your code passes our eslint build and that there are no merge conflicts.
  • Provide a clear subject title that is related to the issue (e.g. [Issue #5] Update the Readme).
  • Provide a list of changes the PR addresses.
  • Link the PR to the related issue. This way, the issue is closed upon merge.
  • PRs must be approved by 2-3 people. If asked, please address any requested changes.
  • Once approval is granted, merge the PR and delete the branch that was worked on (unless others are using it).

Feature Requests

If there is a feature you would like to suggest, feel free to file a new issue so that we can take a look.