通常希望社群可以一起協作的作者,一定會寫一份捐獻文件的說明書,告訴大家參與專案共同開發的規則是什麼,例如怎麼在本機跑測試,建議 commit 的 log 規則等等。
範例:https://github.com/webdriverio/webdriverio/blob/master/CONTRIBUTING.md
如果你的模組,慢慢地開始有使用者採用,那下一階段會發生的事,就是 issue 跟 PR 快速的增長,所以作者必須要用更聰明的方式管理這些 review 工作,通常最花時間的不是修 BUG,而是溝通的時間成本,所以提供制式化的樣板,可以大大的減少溝通時間。
沒人用也愁,有人用也愁。
## Proposed changes
[//]: # (Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request. If it fixes a bug or resolves a feature request, be sure to link to that issue.)
## Types of changes
[//]: # (What types of changes does your code introduce to WebdriverIO?)
[//]: # (_Put an `x` in the boxes that apply_)
- [ ] Bugfix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] Documentation update
## Checklist
[//]: # (_Put an `x` in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code._)
- [ ] I have read the [CONTRIBUTING](https://github.com/webdriverio/webdriverio/blob/master/CONTRIBUTING.md) doc
- [ ] I have added tests that prove my fix is effective or that my feature works
- [ ] I have added necessary documentation (if appropriate)
## Further comments
[//]: # (If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...)
### Reviewers: @webdriverio/technical-committee
範例:https://github.com/webdriverio/webdriverio/tree/master/.github
除了程式執行結果正確性之外,優良的工程師也會追求程式碼的工整、可讀性、遵循某種開發模式,例如縮排是兩個空白,還是四個空白,每行的程式碼末端是要分號,還是不要分號。
範例:https://github.com/webdriverio/webdriverio/blob/master/.eslintrc.js
作者對於模組的未來要走的方向,有沒有規劃跟想法,甚至新的 Feature 預計完成的時間表規劃。
範例:https://github.com/webdriverio/webdriverio/blob/master/ROADMAP.md