Identifying an Area to Contribute
There are several ways to identify an area where you can contribute to Polygon:
- The easiest is just to email one of the Community Maintainers saying “I want to help!”. They’ll work with you to find an area for you to contribute
- If you have a specific contribution in mind, confirm whether the contribution is appropriate first by reaching out in Polygon Telegram group or contacting one of the Community Maintainers directly
- If you do not have a specific contribution in mind, you can also browse the issues labelled as
help wantedon the Polygon GitHub repos
- Issues that additionally have the
good first issuelabel are considered ideal for first-timers
Add to Polygon Documentation:
- If you need to add or change anything in Polygon Documentation, please raise a PR to the
masterbranch. (Kindly check the sample PR)
- Polygon team will review the PR or reach out accordingly.
- Repository: https://github.com/maticnetwork/matic-docs
- Sample PR: https://github.com/maticnetwork/matic-docs/pull/360
If you are adding a new document, it is recommended to just have a basic summary/introduction and a link to your github or documentation for more details.
We believe one of the things that makes Polygon special is its coherent design and we seek to retain this defining characteristic. From the outset we defined some guidelines to ensure new contributions only ever enhance the project:
- Quality: Code in the Polygon project should meet the style guidelines, with sufficient test-cases, descriptive commit messages, evidence that the contribution does not break any compatibility commitments or cause adverse feature interactions, and evidence of high-quality peer-review
- Size: The Polygon project’s culture is one of small pull-requests, regularly submitted. The larger a pull-request, the more likely it is that you will be asked to resubmit as a series of self-contained and individually reviewable smaller PRs
- Maintainability: If the feature will require ongoing maintenance (eg support for a particular brand of database), we may ask you to accept responsibility for maintaining this feature
gitchangelog for all of our repos for change logs. For that, we need to follow the following convention for commit message. There will be no merge if you are not following this convention.
Commit Message Convention
The following are suggestions to what might be useful to think about adding in your commit messages. You might want to separate roughly your commits into big sections:
- by intent (for example: new, fix, change ...)
- by object (for example: doc, packaging, code ...)
- by audience (for example: dev, tester, users ...)
Additionally, you could want to tag some commits:
- as “minor” commits that shouldn’t get output to your changelog (cosmetic changes, small typo in comments...)
- as “refactor” if you don’t really have any significative feature changes. Thus this should not also be part of the changelog displayed to final user for instance, but might be of some interest if you have a developer changelog.
- you could tag also with “api” to mark API changes or if it's a new API or similar
Try writing your commit message by targeting user functionality as often as you can.
This is a standard git log
--oneline to show how these information could be stored:
* 5a39f73 fix: encoding issues with non-ascii chars.
* a60d77a new: pkg: added ``.travis.yml`` for automated tests.
* 57129ba new: much greater performance on big repository by issuing only one shell command for all the commits. (fixes #7)
* 6b4b267 chg: dev: refactored out the formatting characters from GIT.
* 197b069 new: dev: reverse ``natural`` order to get reverse chronological order by default. !refactor
* 6b891bc new: add utf-8 encoding declaration !minor
For more info please refer to What Are Some Good Ways to Manage a Changelog Using Git?
For more details, see https://chris.beams.io/posts/git-commit/