The light platform consists dozens of open-source projects and lives by the work of its contributors. There are plenty of open issues and request for comments, and we need your help to make Light even brighter. You do not need to be a Java guru to contribute to the projects.
For issues or defects, please follow the issues-defects process to create GitHub issues
For new features, please follow the new-features process to create GitHub issues
For every change, we need to ensure that the corresponding document is updated in the light-doc repository to reflect the change. The reviewers will enforce this rule during the review.
Any functional change needs one or more test cases to ensure the quality of the code and help the reviewer to understand how the feature works. The reviewers will enforce this rule during the review.
As version 1.5.x is used on production, all changes need to be backward compatible. The reviewers need to enforce this rule. For broken changes, please merge to JDK 11 branch which is the base for the 2.0.x release.
For all the repositories that are used on productions or used by a lot of projects, the master and develop branches are locked down. Only the organization admin and repository owner can merge the PR to the develop branch. The light-bot release pipeline will merge to the master branch during the release.
For any substantial change, it needs to be reviewed by at least two reviewers. For low-risk changes, show stoppers and urgent defect fixes, the organization admin or repository owner can overwrite the rule to review and merge directly. In most of the cases, the person who opens the issue will be added to the reviewer list to ensure that the requirement is met.
For corporate contributions, one or two team leads must review and approve a PR before the PR can be reviewed and approved by the community member.
Every team is encouraged to submit integration test cases to light-bot build-test-all to cover their application to ensure new changes won’t break their applications.
To avoid duplicate work, each developer should self-signed up to three issues to him/her to indicate that the issues are in progress. People shouldn’t work on issues already signed to other people; however, you can politely ask the assignee to reassign an issue to you if you see there is no activity for the issue over a period of time.
The process is quite restricted, and it might hinder productivity. The organization admin and repository owner have the ultimate right to overwrite the rules and speed up the process. In the future, we are going to assign one or two owners per repository.
If you have a question about the contribution process, please visit develop guide or ask in the gitter room.