Skip to content

Latest commit

 

History

History
61 lines (32 loc) · 3.84 KB

CONTRIBUTING.md

File metadata and controls

61 lines (32 loc) · 3.84 KB
Raw

How to contribute to Politeiagui

We are excited you want to contribute to Politeiagui. This is the best place to get you started!

If you haven't yet, please join our Matrix Channel and introduce yourself. We always like to know who is interested in the project and we can help you with any questions you may have.

Did you find a bug?

  • Ensure the bug was not already reported by searching our GitHub under issues.

  • If you're unable to find an open issue addressing the problem, open a new one. Be sure to include:

    • a title and clear description
    • as much relevant information possible

  • Evaluate if this bug wouldn't be better placed in the Politeia repository instead. Politeiagui issues are intentended to bugs which affects the UI directly. If the bug requires backend work, first create an issue on Politeia. If you are not sure where it belongs, feel free to ask us.

Do you want to add a new feature or change an existing one?

  • Before openning an issue, suggest your change in the Politeia Room and collect enough positive feedback. We expect GitHub issues to be primarly intended for bug reports and fixes.

Do you intend to work on a patch that fixes a bug?

  • Give a signal in the issue that you are going to work on it or assign the issue to yourself if you have the GitHub permission.

  • Do your best to drive the issue into completition. But if you think you won't be able to finish it, remember to comment in the issue signaling that you are no longer working on it.

  • Do not allow more than 10 days without providing a status of your work, otherwise the issue will be free for others to take.

Did you write a patch code that fixes a bug?

  • Open a new GitHub pull request with the code.

How to write the perfect pull request:

  • Ensure the PR description clearly describes the problem and solution. Include the relevant issue number if applicable.

  • Include a list with the actions relevant to your PR in the description.

  • Make sure you test your PR before opening it.

  • Make sure your code is readable and well organized.

  • Go for a declarative approach whenever you can. This guide is a good read on imperative x declarative programming.

  • Make sure you follow the React best practices, the thinking in react section of the React docs is a good read. If you are not experienced with the framework, don't worry! Show up on matrix and we will be glad to help you.

  • If your PR changes something in the UI, please add some screenshots in both light and dark modes.

  • Be explicit about what feedback you want: a quick pair of eyes on the code, discussion on the technical approach, critique on design, etc.

  • Be explicit about when you want feedback, if the Pull Request is work in progress, say so by adding the [WIP] tag or opening a Draft.

Do you intend to work on an issue but you don't know which one to pick?

  • If you are a newcomer, look for the 'good-first-issue' label in the issues list. Those are the easiest ones to be dealt with.

  • If you are already contributing, prioritize the issues by weighing the value it will deliver to the end user and how fast you can write that code. Generally speaking, the labels 'bug', 'ux', 'enhancements' are good choices. They are generally faster to be handled and they deliver a good value to the end user.

  • If you are already contributing and want to work on a more challenging issue, make sure to share your intention in the Politeia Room to check if the issue is still relevant and also gather some thoughts from other peers.