@cryptotaxi247 / netdata-1 / commits / a0fe44119

Contributing.md updates (#4767)

Fixes #4146 Additional links to more detailed instructions per area will be added, as such instructions become available.

Chris Akritidis committed Nov 29, 2018 at 15:00 UTC a0fe44119128258542679f8079200eb3487141d1
2 files changed +46 -4
CONTRIBUTING.md
+45 -3
@@ -20,9 +20,33 @@ Community growth allows the project to attract new talent willing to contribute.
20
21 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**.
22
23 -#### Help the developers understand what they have to do
23 +### Sponsor a part of Netdata
24
25 -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.
25 +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.
26 +
27 +#### Sponsor a collector
28 +
29 +Netdata is all about simplicity and meaningful presentation. A "sponsor" for a collector does the following:
30 + - Assists the devs with feedback on the charts.
31 + - Specifies the alarms that would make sense for each metric.
32 + - When the implementation passes QA, tests the implementation in production.
33 + - Uses the charts and alarms in his/her day to day work and provides additional feedback.
34 + - Requests additional improvements as things change (e.g. new versions of an API are available).
35 +
36 +#### Sponsor a backend
37 +
38 +We already support various [backends](backends) and we intend to support more. A "sponsor" for a backend:
39 +- Suggests ways in which the information in Netdata could best be exposed to the particular backend, to facilitate meaningful presentation.
40 + - When the implementation passes QA, tests the implementation in production.
41 +- Uses the backend in his/her day to day work and provides additional feedback, after the backend is delivered.
42 + - Requests additional improvements as things change (e.g. new versions of the backend API are available).
43 +
44 +#### Sponsor a notification method
45 +
46 +Netdata delivers alarms via various [notification methods](health/notifications). A "sponsor" for a notification method:
47 +- 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).
48 +- Uses the notification method in production and provides feedback.
49 +- Requests additional improvements as things change (e.g. new versions of the API are available).
50
51 ## Experienced Users
52
@@ -37,7 +61,7 @@ Most of our documentation is in markdown (.md) files inside the netdata GitHub p
61
62 ## Developers
63
40 -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).
64 +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).
65
66 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/).
67
@@ -90,3 +114,21 @@ Your contributions should be bundled with related documentation to help users un
114
115 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.
116
117 +### Your first pull request
118 +
119 +There are several guides for pull requests, such as the following:
120 +- https://thenewstack.io/getting-legit-with-git-and-github-your-first-pull-request/
121 +- https://github.com/firstcontributions/first-contributions#first-contributions
122 +
123 +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)
124 +
125 +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.
126 +
127 +### PR approval process
128 +
129 +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.
130 +
131 +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.
132 +
133 +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.
134 +
docs/generator/buildyaml.sh
+1 -1
@@ -108,6 +108,7 @@ echo -ne " - 'docs/Why-Netdata.md'
108 - 'docs/a-github-star-is-important.md'
109 - REDISTRIBUTED.md
110 - CHANGELOG.md
111 + - CONTRIBUTING.md
112 "
113
114 echo -ne "- Installation:
@@ -210,7 +211,6 @@ navpart 2 web/api/health "" "" 2
211 navpart 2 web/api/queries "" "Queries" 2
212
213 echo -ne "- Hacking netdata:
213 - - CONTRIBUTING.md
214 - CODE_OF_CONDUCT.md
215 - 'docs/Netdata-Security-and-Disclosure-Information.md'
216 - CONTRIBUTORS.md