Add a project governance doc (#1912)
* Add a project governance doc Signed-off-by: Dave Thaler <dthaler@microsoft.com> * Add note about tracing Signed-off-by: Dave Thaler <dthaler@microsoft.com> Signed-off-by: Dave Thaler <dthaler@microsoft.com> Co-authored-by: Anurag Saxena <43585259+saxena-anurag@users.noreply.github.com>
This commit is contained in:
Родитель
fcce18ecb9
Коммит
f2a04af907
|
@ -78,7 +78,7 @@ submitting a feature or substantial code contribution, please discuss it with th
|
||||||
ensure it follows the product roadmap. You might also read these two blogs posts on contributing
|
ensure it follows the product roadmap. You might also read these two blogs posts on contributing
|
||||||
code: [Open Source Contribution Etiquette](http://tirania.org/blog/archive/2010/Dec-31.html) by Miguel de Icaza and
|
code: [Open Source Contribution Etiquette](http://tirania.org/blog/archive/2010/Dec-31.html) by Miguel de Icaza and
|
||||||
[Don't "Push" Your Pull Requests](https://www.igvita.com/2011/12/19/dont-push-your-pull-requests/) by Ilya Grigorik.
|
[Don't "Push" Your Pull Requests](https://www.igvita.com/2011/12/19/dont-push-your-pull-requests/) by Ilya Grigorik.
|
||||||
All code submissions will be rigorously reviewed and tested by the maintainers, and only those that meet
|
All code submissions will be rigorously [reviewed](docs/Governance.md) and tested by the maintainers, and only those that meet
|
||||||
the bar for both quality and design/roadmap appropriateness will be merged into the source.
|
the bar for both quality and design/roadmap appropriateness will be merged into the source.
|
||||||
|
|
||||||
For all new Pull Requests the following rules apply:
|
For all new Pull Requests the following rules apply:
|
||||||
|
|
|
@ -0,0 +1,39 @@
|
||||||
|
Project Governance
|
||||||
|
==================
|
||||||
|
|
||||||
|
Reviewing Pull Requests
|
||||||
|
-----------------------
|
||||||
|
|
||||||
|
Pull requests need at least two approvals before being eligible for merging.
|
||||||
|
Besides reviewing for technical correctmess, reviewers are expected to:
|
||||||
|
|
||||||
|
* For any PR that adds functionality, check that the PR includes sufficient tests
|
||||||
|
for that functionality. This is required in [CONTRIBUTING.md](../Contributing.md).
|
||||||
|
* For any PR that adds or changes functionality in a way that is observable
|
||||||
|
by administrators or by authors of eBPF programs or applications, check that
|
||||||
|
documentation has been sufficiently updated. This is required in
|
||||||
|
[CONTRIBUTING.md](../Contributing.md).
|
||||||
|
* Check that there are no gratuitous differences in public APIs between eBPF for
|
||||||
|
Windows and Linux.
|
||||||
|
* Be familiar with, and call out code that does not conform to, the eBPF for Windows
|
||||||
|
[coding conventions](DevelopmentGuide.md).
|
||||||
|
* Check that errors are appropriately logged where first detected (not at each
|
||||||
|
level of stack unwind).
|
||||||
|
|
||||||
|
When multiple pull requests are approved, maintainers should prioritize merging PRs as follows:
|
||||||
|
|
||||||
|
| Pri | Description | Tags | Rationale |
|
||||||
|
| --- | ------------ | --------- | ---------------------- |
|
||||||
|
| 1 | Bugs | bug | Affects existing users |
|
||||||
|
| 2 | Test bugs | tests bug | Problem that affects CI/CD and may mask priority 1 bugs |
|
||||||
|
| 3 | Additional tests | tests enhancement | Gap that once filled might surface priority 1 bugs |
|
||||||
|
| 4 | Documentation | documentation | Won't affect CI/CD but may address usability issues |
|
||||||
|
| 5 | Dependencies | dependencies | Often a large amount of low hanging fruit. Keeping the overall PR count low gives a better impression to newcomers and observers. |
|
||||||
|
| 7 | New features | enhancement | Addresses functionality requested in a github issue |
|
||||||
|
| 8 | Performance optimizations | optimization | Doesn't do anything that isn't already working, but improvements do help users |
|
||||||
|
| 9 | Code cleanup | cleanup | Good to do but generally doesn't significantly affect any of the above categories |
|
||||||
|
|
||||||
|
Release Process
|
||||||
|
------------------
|
||||||
|
|
||||||
|
See [Release Process](ReleaseProcess.md).
|
Загрузка…
Ссылка в новой задаче