diff options
-rw-r--r-- | CONTRIBUTING.md | 48 | ||||
-rwxr-xr-x | docs/generator/buildyaml.sh | 2 |
2 files changed, 46 insertions, 4 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index fa06565269..213dbfaf36 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -20,9 +20,33 @@ Community growth allows the project to attract new talent willing to contribute. Is there anything that bothers you about netdata? Did you experience an issue while installing it or using it? Would you like to see it evolve to you need? Let us know. [Open a github issue](https://github.com/netdata/netdata/issues) to discuss it. Feedback is very important for open-source projects. We can't commit we will do everything, but your feedback influences our road-map significantly. **We rely on your feedback to make Netdata better**. -#### Help the developers understand what they have to do +### Sponsor a part of Netdata -NetData is all about simplicity and meaningful presentation. It's impossible for a handful of people to know which metrics really matter when monitoring a particular software or hardware component you are interested in. Be specific about what should be collected, how the information should be presented in the dashboard and which alarms make sense in most situations. +Netdata is a complex system, with many integrations for the various collectors, backends and notification endpoints. As a result, we rely on help from "sponsors", a concept similar to "power users" or "product owners". To become a sponsor, just let us know in any Github issue and we will record your GitHub username in a "CONTRIBUTORS.md" in the appropriate directory. + +#### Sponsor a collector + +Netdata is all about simplicity and meaningful presentation. A "sponsor" for a collector does the following: + - Assists the devs with feedback on the charts. + - Specifies the alarms that would make sense for each metric. + - When the implementation passes QA, tests the implementation in production. + - Uses the charts and alarms in his/her day to day work and provides additional feedback. + - Requests additional improvements as things change (e.g. new versions of an API are available). + +#### Sponsor a backend + +We already support various [backends](backends) and we intend to support more. A "sponsor" for a backend: +- Suggests ways in which the information in Netdata could best be exposed to the particular backend, to facilitate meaningful presentation. + - When the implementation passes QA, tests the implementation in production. +- Uses the backend in his/her day to day work and provides additional feedback, after the backend is delivered. + - Requests additional improvements as things change (e.g. new versions of the backend API are available). + +#### Sponsor a notification method + +Netdata delivers alarms via various [notification methods](health/notifications). A "sponsor" for a notification method: +- Points the devs to the documentation for the API and identifies any unusual features of interest (e.g. the ability in Slack to send a notification either to a channel or to a user). +- Uses the notification method in production and provides feedback. +- Requests additional improvements as things change (e.g. new versions of the API are available). ## Experienced Users @@ -37,7 +61,7 @@ Most of our documentation is in markdown (.md) files inside the netdata GitHub p ## Developers -We expect most contributions to be for new data collection plugins. You can read about how external plugins work [here](collectors/plugins.d/). Additional instructions are available for [Node.js plugins](collectors/node.d.plugin) and [Python plugis](collectors/python.d.plugin). +We expect most contributions to be for new data collection plugins. You can read about how external plugins work [here](collectors/plugins.d/). Additional instructions are available for [Node.js plugins](collectors/node.d.plugin) and [Python plugins](collectors/python.d.plugin). Of course we appreciate contributions for any other part of the NetData agent, including the [daemon](daemon), [backends for long term archiving](backends/), innovative ways of using the [REST API](web/api) to create cool [Custom Dashboards](web/gui/custom/) or to include NetData charts in other applications, similarly to what can be done with [Confluence](web/gui/confluence/). @@ -90,3 +114,21 @@ Your contributions should be bundled with related documentation to help users un When you contribute code to Netdata, you are automatically accepting that you will be responsible for maintaining that code in the future. So, if users need help, or report bugs, we will invite you to the related github issues to help them or fix the issues or bugs of your contributions. +### Your first pull request + +There are several guides for pull requests, such as the following: +- https://thenewstack.io/getting-legit-with-git-and-github-your-first-pull-request/ +- https://github.com/firstcontributions/first-contributions#first-contributions + +However, it's not always that simple. Our [PR approval process](#pr-approval-process) and the several merges we do every day may cause your fork to get behind the Netdata master. If you worked on something that has changed in the meantime, you will be required to do a git rebase, to bring your fork to the correct state. A very easy to follow guide on how to do it without learning all the intricacies of GitHub can be found [here](https://medium.com/@ruthmpardee/git-fork-workflow-using-rebase-587a144be470) + +One thing you will need to do only for your first pull request in Netdata is to accept the CLA. Until you do, the automated check for the CLA acceptance will be showing as failed. + +### PR approval process + +Each PR automatically [requires a review](https://help.github.com/articles/about-required-reviews-for-pull-requests/) from the code owners specified in `.github/CODEOWNERS`. Depending on the files contained in your PR, several people may be need to approve it. + +We also have a series of automated checks running, such as linters to check code quality and QA tests. If you get an error or warning in any of those checks, you will need to click on the link included in the check to identify the root cause, so you can fix it. + +One special type of automated check is the "WIP" check. You may add "[WIP]" to the title of the PR, to tell us that the particular request is "Work In Progress" and should not be merged. You're still not done with it, you created it to get some feedback. When you're ready to get the final approvals and get it merged, just remove the "[WIP]" string from the title of your PR and the "WIP" check will pass. + diff --git a/docs/generator/buildyaml.sh b/docs/generator/buildyaml.sh index 6b982d40be..dbc75a74d0 100755 --- a/docs/generator/buildyaml.sh +++ b/docs/generator/buildyaml.sh @@ -108,6 +108,7 @@ echo -ne " - 'docs/Why-Netdata.md' - 'docs/a-github-star-is-important.md' - REDISTRIBUTED.md - CHANGELOG.md + - CONTRIBUTING.md " echo -ne "- Installation: @@ -210,7 +211,6 @@ navpart 2 web/api/health "" "" 2 navpart 2 web/api/queries "" "Queries" 2 echo -ne "- Hacking netdata: - - CONTRIBUTING.md - CODE_OF_CONDUCT.md - 'docs/Netdata-Security-and-Disclosure-Information.md' - CONTRIBUTORS.md |