English | 简体中文
We sincerely invite you to click on the ⭐ star in the upper right corner of this page to follow this project, which will allow you to get the latest information and better participate in the co-build. Thank you for your support!
If you have any comment or advice, please report your issue, or make any change as you wish and submit an PR.
Whether you are a designer, a product manager or a regular user, you can contribute to the Chart Knowledge Base. We value your participation and look forward to working with you to build it together.
If you don't already have a GitHub account, we recommend that you get yourself a GitHub Account first. This step is well worth it.
After that, you can help us by creating an issue or a pull request.
GitHub Discussions is like a message board where you can share ideas, ask questions, answer queries, exchange experiences, and more. Here are the basic steps for submitting discussions:
New discussion: Switch to the Discussions tab and click the New discussion button on the right to create a new discussion.
Submit discussion: Select an appropriate Discussion category and click Get Start to go to the discussion fill page. The description here should include the topic you want to discuss, your question or idea. Once completed, click Start discussion to submit your discussion.
If you have the ability to write code, or don't feel resistant to learning some code, and want to put your suggestions into clear code form (or if you want to help us save time), that's great! Please try submitting a pull request, it will help us to process your suggestions faster and implement them into the project quickly.
If you don't know what a pull request is, please refer to: Learn more about pull request.
We give priority to English to serve a wider range of developers, to deepen international cooperation and co-construction, and to avoid duplicate submissions between different languages.
AntV group members will confirm the purpose of the issue, replace more accurate tags for it, identify related milestone, and assign developers working on it.
If you are developer of AntV repo and you are willing to contribute, feel free to create a new branch, finish your modification and submit a PR. AntV group will review your work and merge it to master branch.
Start-up project
# Create a new branch for development. The name of branch should be semantic, avoiding words like 'update' or 'tmp'. We suggest to use feature/xxx, if the modification is about to implement a new feature.
$ git checkout -b branch-name
# Initialization of the project and installation of dependencies.
$ npm run one-stop-setup
# Launching the official website in development mode.
$ npm run start:site
# Launch playground in development mode.
$ npm run star开发模式下启动playgroundt:playground
Test and Submit
# Run the test after you finish your modification. Add new test cases or change old ones if you feel necessary
$ npm test
# If your modification pass the tests, congradulations it's time to push your work back to us. Notice that the commit message should be wirtten in the following format.
$ git add . # git add -u to delete files
$ git commit -m "fix(role): role.use must xxx"
$ git push origin branch-name
Then you can create a Pull Request at AVA.
No one can guarantee how much will be remembered about certain PR after some time. To make sure we can easily recap what happened previously, please provide the following information in your PR.
Eslint can help to identify styling issues that may exist in your code. Your code is required to pass the test from eslint. Run the test locally by $ npm run lint
.
You are encouraged to use angular commit-message-format to write commit message. In this way, we could have a more trackable history and an automatically generated changelog.
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
(1)type
Must be one of the following:
(2)scope
The scope of the modified file, i.e., the packages and modules involved. A single commit usually does not allow multiple packages to be involved, and the order in parentheses is based on the following array order. The specific scope is as follows:
(3)subject
Use succinct words to describe what did you do in the commit change.
(4)body
Feel free to add more content in the body, if you think subject is not self-explanatory enough, such as what it is the purpose or reasons of you commit.
(5)footer
Closes #1, Closes #2, #3
e.g.
fix($compile): [BREAKING_CHANGE] couple of unit tests for IE9
Older IEs serialize html uppercased, but IE9 does not...
Would be better to expect case insensitive, unfortunately jasmine does
not allow to user regexps for throw expectations.
Document change on antvis/AVA#123
Closes #392
BREAKING CHANGE:
Breaks foo.bar api, foo.baz should be used instead
Look at these files for more details.
AVA uses semantic versioning in release process based on semver.
master
branch is the latest stable version.
master
master
or next
branch as well as all bug-fix except security issues. In such way, we can motivate developers to update to the latest stable version.In the release of every stable version, there will be a PM who has the following responsibilities in different stages of the release.
History
as node CHANGELOG. Don't forget to correct content in documentation which is related to the releasing version. Commits can be generated automatically.
$ npm run commits
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。