Skip to content

Latest commit

 

History

History
102 lines (69 loc) · 6.16 KB

CONTRIBUTING.md

File metadata and controls

102 lines (69 loc) · 6.16 KB

Contributing

Kubetweet lives through contributions from the community. When contributing to this repository, please first discuss the change you wish to make via an issue, discord, or any other method with the maintainers of this repository before making a change.

Table of Contents

Where to Get Help

The community is present on various platforms on the internet, where we actively help each other out – not only with using the application. GitHub is the most tech-focused part of the community, albeit discussing here is the way to go for more theoretical discussions. Furthermore, we have a Discord-server where we discuss building the app and help each other out.

All Communication Channels

How to Help

If you have some experience with developing, we would gladly welcome your help in fixing issues and adding features.You can improve your skills and help the project. Even if it's a minor fix, it is still a fix!

First, feel free to search for good first issues to tackle: check here

Even if you're an advanced coder, feel free to take one of them :)

Second, please look through the other issues and discussions to get a better idea of our vision and get inspired. If you have any idea about something you want to contribute, feel free to start an issue or discussion around that.

Our Stack

Contributor Guidelines

If you want to help, make sure to communicate your intent, that is:

  1. If you want to start working on an issue, comment and say that you want to develop a PR. In the PR, please link the issue.
  2. If you want to tackle an issue but, along the way, realize that you ran out of time and can't finish it: communicate it! This is an Open Source project, and retracting is no shame, but not expressing that you cannot finish something will hinder all other people involved.
  3. If you have a PR and are unsure whether it's right, open the PR and outline your questions there. It is much easier to work with something we can see and improve the PR than if you ask without something concrete.

In any case, remember to open PRs and dive in.

Semantic Commits

Please use Semantic Commits while you commit your code changes. It helps reviewers to review the code and makes you a better programmer.

feat: (adding new feature)
fix: (bug fix for the user, not a fix to a build script)
docs: (changes to the documentation)
style: (formatting, missing semi colons, etc; no production code change)
refactor: (refactoring production code, eg. renaming a variable)
test: (adding missing tests, refactoring tests; no production code change)
dx: (dev experience; anything that helps to improve developers' experience)
chore: (updating grunt tasks etc; no production code change)

Commit Example

feat: added authentication using supabase auth

Learn more about semantic commits

Making Changes

To contribute, you will need to make a feature branch. This simplifies adding your code to the official repository and ensures the main branch is always working. As a heads up, it's best to let us know what you're working on by commenting on or creating an issue. This way, we all save time by working on different things. Follow the steps below to make changes:

  1. In terminal, cd into kubetweet.
  2. Run git checkout main. Always ensure you are on main before creating a feature branch.
  3. Run git checkout -b name-of-your-feature. This will create a feature branch and switch to it. Use a self-descriptive name for your feature branch (e.g feature-featureName, bugFix-bugName, patch-patchName). This helps us track it down in the future if we need to.
  4. Make a meaningful change. You don't want to implement the whole feature in one shot. Try to break your task into meaningful (and revertible) chunks, though sometimes one chunk is all it takes, like minor bug fixes.
  5. To create a commit, run git status to verify that only the files you want to change are affected. If there are unexpected changes, please resolve them before proceeding.
  6. Stage all of your changes with git add .
  7. Create your commit with git commit -m "Type a precise description of only the changes made with this commit." Use the format described in the Semantic Commits section above.

Pushing Changes

You are ready for your contribution to be reviewed and merged. There are a few things you can do to make this easier for maintainers to review your code, so please follow all steps.

  1. Follow the instructions for Updating Your Repository.
  2. Switch back to your feature branch with git checkout name-of-your-feature.
  3. Rebase your branch with git rebase main. This will make sure there are no conflicts with other people's contributions.
  4. Rebuild your project to make sure everything still works. If things are broken, resolve them, making commits along the way. Once resolved, return to step 1 as resolving conflict could have made more changes in the meantime.
  5. Push your branch to your online fork with git push origin name-of-your-feature.
  6. On GitHub, create a pull request for your feature branch.

Remarks

If something is missing here, or you feel something is not well described, either directly open a PR or ask in one of the community places.