First, thank you for considering contributions to Zadig!
We welcome all sorts of contributions: from fixing a typo, updating a documentation, raising a bug, proposing a feature request, to proposing a design and driving all the implementations in end-to-end manner.
For every commit, be sure to sign off on the DCO.
Zadig's success heavily relies on a healthy community, and it's up to every one of us to maintain it. This is a reminder that all contributions are expected to adhere to our Code of Conduct.
You should first fork the specific repository you want to contribute to. Please follow the instructions here to set Zadig up for running.
Before submitting any new issues or proposing any new changes, please check the open issues to make sure the efforts aren't duplicated. There are a few labels that could help you navigate through the issues:
If you are looking for some startup issues to get your hands on, you could follow the #good-first-issue issues.
If you are looking for some more serious challenges, you could check out our #help-wanted issues.
Or some random bugfix, check out #bugs.
For security related issues, please drop an email to firstname.lastname@example.org instead. For non-security related issues, please read on.
There are 5 types of labels for issues that you need to think of:
If you understand which services are involved with the new issue, please also attach the relevant label(s) to it. You
could search for
service/ prefix to find the correct label.
If you aren't sure about this, feel free to leave it open, our maintainers will get to it.
If you have checked that no duplicated issues existed and decided to create a new issue, choose the label accordingly and follow the issue template. Please be as specific as possible assuming low or no context from whoever reading the issue.
All issues created will be triaged by our maintainers:
For trivial doc changes, such as fixing a typo, updating a link, go ahead and create a pull request. One of our maintainers will get to it. Please follow our PR and commit guidelines below.
If you are looking for a more serious documentation changes, such as refactoring a full page, please follow the instructions of non-trivial code changes below. You'll need an issue to track this and a design outlining your proposal and have the design approved first.
For any code changes, you need to have an associated issue: either an existing one or create a new one.
to prevent duplication, please claim an issue by commenting on it that you are working on the issue.
aslanmicroservice, you need to update our API doc accordingly.
yyyy-MM-dd-my-design-name.md. Please send a separate PR for this. One of our maintainers will get to it.
If you only modified APIs from services other than
aslan, you could ignore this since we don't have API docs for them
aslan service, we use Swag to automatically generate API docs hosted by
Swagger based on the swag declarative API comments.
So if you have added or modified any API on
aslan service, please:
Document your API Handler following swag declarative API comments.
Update the swagger API doc with the following command:
cd [your root path of Zadig-X] swag init -d ./lib/microservice/aslan/ -g server/rest/router.go -o ./lib/microservice/aslan/server/rest/doc
Check out Swag CLI for more details.
Note: If your generated doc/docs.go contains "github.com/alecthomas/template" (used by early swag versions), please change it to "text/template".
We have established a well-lit path for contributor's progression. Please check out GOVERNANCE for more information.
：Code submit frequency
：React/respond to issue & PR etc.
：Well-balanced team members and collaboration
：Recent popularity of project
：Star counts, download counts etc.