UNPKG

@antv/my-f2/CONTRIBUTING.md

Version:

5.71 kBMarkdownView Raw

1# Contribution Guide
2
3If you have any comment or advice, please report your [issue](https://github.com/antvis/my-f2/issues),
4or make any change as you wish and submit an [PR](https://github.com/antvis/my-f2/pulls).
5
6## Reporting New Issues
7
8- Please specify what kind of issue it is.
9- Before you report an issue, please search for related issues. Make sure you are not going to open a duplicate issue.
10- Explain your purpose clearly in tags(see **Useful Tags**), title, or content.
11
12AntV group members will confirm the purpose of the issue, replace more accurate tags for it, identify related milestone, and assign developers working on it.
13
14## Submitting Code
15
16### Pull Request Guide
17
18If 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.
19
20```bash
21# 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.
22$ git checkout -b branch-name
23
24# Run the test after you finish your modification. Add new test cases or change old ones if you feel necessary
25$ npm test
26
27# 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.
28$ git add . # git add -u to delete files
29$ git commit -m "fix(role): role.use must xxx"
30$ git push origin branch-name
31```
32
33Then you can create a Pull Request at [my-f2](https://github.com/antvis/my-f2/pulls).
34
35No one can garantee 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.
36
371. Need: What function you want to achieve (Generally, please point out which issue is related).
382. Updating Reason: Different with issue. Briefly describe your reason and logic about why you need to make such modification.
393. Related Testing: Briefly descirbe what part of testing is relevant to your modification.
404. User Tips: Notice for my-f2 users. You can skip this part, if the PR is not about update in API or potential compatibility problem.
41
42### Style Guide
43
44Eslint 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`.
45
46### Commit Message Format
47
48You are encouraged to use [angular commit-message-format](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit-message-format) to write commit message. In this way, we could have a more trackable history and an automatically generated changelog.
49
50```xml
51<type>(<scope>): <subject>
52<BLANK LINE>
53<body>
54<BLANK LINE>
55<footer>
56```
57
58（1）type
59
60Must be one of the following:
61
62- feat: A new feature
63- fix: A bug fix
64- docs: Documentation-only changes
65- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
66- refactor: A code change that neither fixes a bug nor adds a feature
67- perf: A code change that improves performance
68- test: Adding missing tests
69- chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
70- deps: Updates about dependencies
71
72（2）scope
73
74The scope could be anything specifying place of the commit change.
75
76（3）subject
77
78Use succinct words to describe what did you do in the commit change.
79
80（4）body
81
82Feel 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 reasone of you commit.
83
84（5）footer
85
86- **If the commit is a Breaking Change, please note it clearly in this part.**
87- related issues, like `Closes #1, Closes #2, #3`
88
89e.g.
90
91```
92fix($compile): [BREAKING_CHANGE] couple of unit tests for IE9
93
94Older IEs serialize html uppercased, but IE9 does not...
95Would be better to expect case insensitive, unfortunately jasmine does
96not allow to user regexps for throw expectations.
97
98Document change on antvis/my-f2#123
99
100Closes #392
101
102BREAKING CHANGE:
103
104  Breaks foo.bar api, foo.baz should be used instead
105```
106
107Look at [these files](https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit) for more detials.
108
109## Release
110
111my-f2 uses semantic versioning in release process based on [semver].
112
113### Branch Strategy
114
115`master` branch is the latest stable version. 
116
117- just checkout develop branch from `master`
118- All new features will be added into `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.
119
120
121### Release Strategy
122
123In the release of every stable version, there will be a PM who has the following responsibilities in different stages of the release.
124
125#### Preparation
126
127- Set up milestone. Confirm that request is related to milestone.
128
129#### Before Release
130
131- Confirm that performance test is passed and all issues in current Milestone are either closed or can be delayed to later versions.
132- Open a new [Release Proposal MR], and write `History` as [node CHANGELOG]. Don't forget to correct content in documentation which is related to the releasing version. Commits can be generated automatically.
133    ```
134    $ npm run commits
135    ```
136- Nominate PM for next stable version.
137
138
139[semver]: http://semver.org/lang/zh-CN/
140[Release proposal MR]: https://github.com/nodejs/node/pull/4181
141[node CHANGELOG]: https://github.com/nodejs/node/blob/master/CHANGELOG.md
142[『我是如何发布一个 npm 包的』]: https://fengmk2.com/blog/2016/how-i-publish-a-npm-package

1	`# Contribution Guide`
2
3	`If you have any comment or advice, please report your [issue](https://github.com/antvis/my-f2/issues),`
4	`or make any change as you wish and submit an [PR](https://github.com/antvis/my-f2/pulls).`
5
6	`## Reporting New Issues`
7
8	`- Please specify what kind of issue it is.`
9	`- Before you report an issue, please search for related issues. Make sure you are not going to open a duplicate issue.`
10	`- Explain your purpose clearly in tags(see Useful Tags), title, or content.`
11
12	`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.`
13
14	`## Submitting Code`
15
16	`### Pull Request Guide`
17
18	`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.`
19
20	```bash
21	`# 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.`
22	`$ git checkout -b branch-name`
23
24	`# Run the test after you finish your modification. Add new test cases or change old ones if you feel necessary`
25	`$ npm test`
26
27	`# 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.`
28	`$ git add . # git add -u to delete files`
29	`$ git commit -m "fix(role): role.use must xxx"`
30	`$ git push origin branch-name`
31	```
32
33	`Then you can create a Pull Request at [my-f2](https://github.com/antvis/my-f2/pulls).`
34
35	`No one can garantee 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.`
36
37	`1. Need: What function you want to achieve (Generally, please point out which issue is related).`
38	`2. Updating Reason: Different with issue. Briefly describe your reason and logic about why you need to make such modification.`
39	`3. Related Testing: Briefly descirbe what part of testing is relevant to your modification.`
40	`4. User Tips: Notice for my-f2 users. You can skip this part, if the PR is not about update in API or potential compatibility problem.`
41
42	`### Style Guide`
43
44	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`.
45
46	`### Commit Message Format`
47
48	`You are encouraged to use [angular commit-message-format](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit-message-format) to write commit message. In this way, we could have a more trackable history and an automatically generated changelog.`
49
50	```xml
51	`<type>(<scope>): <subject>`
52	`<BLANK LINE>`
53	`<body>`
54	`<BLANK LINE>`
55	`<footer>`
56	```
57
58	`（1）type`
59
60	`Must be one of the following:`
61
62	`- feat: A new feature`
63	`- fix: A bug fix`
64	`- docs: Documentation-only changes`
65	`- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)`
66	`- refactor: A code change that neither fixes a bug nor adds a feature`
67	`- perf: A code change that improves performance`
68	`- test: Adding missing tests`
69	`- chore: Changes to the build process or auxiliary tools and libraries such as documentation generation`
70	`- deps: Updates about dependencies`
71
72	`（2）scope`
73
74	`The scope could be anything specifying place of the commit change.`
75
76	`（3）subject`
77
78	`Use succinct words to describe what did you do in the commit change.`
79
80	`（4）body`
81
82	`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 reasone of you commit.`
83
84	`（5）footer`
85
86	`- If the commit is a Breaking Change, please note it clearly in this part.`
87	- related issues, like `Closes #1, Closes #2, #3`
88
89	`e.g.`
90
91	```
92	`fix($compile): [BREAKING_CHANGE] couple of unit tests for IE9`
93
94	`Older IEs serialize html uppercased, but IE9 does not...`
95	`Would be better to expect case insensitive, unfortunately jasmine does`
96	`not allow to user regexps for throw expectations.`
97
98	`Document change on antvis/my-f2#123`
99
100	`Closes #392`
101
102	`BREAKING CHANGE:`
103
104	`Breaks foo.bar api, foo.baz should be used instead`
105	```
106
107	`Look at [these files](https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit) for more detials.`
108
109	`## Release`
110
111	`my-f2 uses semantic versioning in release process based on [semver].`
112
113	`### Branch Strategy`
114
115	`master` branch is the latest stable version.
116
117	- just checkout develop branch from `master`
118	- All new features will be added into `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.
119
120
121	`### Release Strategy`
122
123	`In the release of every stable version, there will be a PM who has the following responsibilities in different stages of the release.`
124
125	`#### Preparation`
126
127	`- Set up milestone. Confirm that request is related to milestone.`
128
129	`#### Before Release`
130
131	`- Confirm that performance test is passed and all issues in current Milestone are either closed or can be delayed to later versions.`
132	- Open a new [Release Proposal MR], and write `History` as [node CHANGELOG]. Don't forget to correct content in documentation which is related to the releasing version. Commits can be generated automatically.
133	```
134	`$ npm run commits`
135	```
136	`- Nominate PM for next stable version.`
137
138
139	`[semver]: http://semver.org/lang/zh-CN/`
140	`[Release proposal MR]: https://github.com/nodejs/node/pull/4181`
141	`[node CHANGELOG]: https://github.com/nodejs/node/blob/master/CHANGELOG.md`
142	`[『我是如何发布一个 npm 包的』]: https://fengmk2.com/blog/2016/how-i-publish-a-npm-package`