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
|
||||
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.
|
||||
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.
|
||||
|
||||
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).
|
Загрузка…
Ссылка в новой задаче