Add contributing guidelines (#71)

* Update issue templates
* Add CONTRIBUTING.md file
* Update the main readme links. Add a new section about testing.
* Bump file.d version in makefile
* Generate docs

Co-authored-by: Sandu Kiritsa <[email protected]>

Author: ssnd

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,24 @@
+---
+name: Bug report
+about: Create a report to help us improve file.d
+title: 'Bug: '
+labels: bug
+assignees: ''
+
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**To Reproduce**
+Steps to reproduce the behavior:
+1. 
+2. 
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Additional context**
+Version:
+Platform:
+Add any other context about the problem here.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,20 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: 'Feature:'
+labels: enhancement
+assignees: ''
+
+---
+
+**Is your feature request related to a problem? Please describe.**
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+**Describe the solution you'd like**
+A clear and concise description of what you want to happen.
+
+**Describe alternatives you've considered**
+A clear and concise description of any alternative solutions or features you've considered.
+
+**Additional context**
+Add any other context or screenshots about the feature request here.

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,5 @@
+# Description
+
+Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
+
+Fixes # (issue)

CONTRIBUTING.md

@@ -0,0 +1,65 @@
+# Welcome to file.d contributing guide
+Thank you for investing your time in contributing to our project! This set of basic guidelines will help us make file.d development as easy, effective and transparent as possible for everyone involved.
+In this guide you will get an overview of the contribution workflow from opening an issue, creating a PR, reviewing, and merging the PR.
+
+## Issues
+### Bug reports
+Before reporting a bug please use the Github search and check if the issue has already been reported/fixed.
+
+A great bug report should include: 
+- A quick summary and/or background
+- Steps to reproduce
+- Sample code (if necessary)
+- What you expected would happen
+- What actually happens
+- Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)
+- Context -- platform, versions of the software software and everything that you think may be important to reproduce and fix the newfound bug.
+
+Here's an example of a [great bug report](http://www.openradar.me/11905408).
+Make sure to use the bug report template available when creating a new issue.
+
+
+### Feature requests
+Please provide as many details and as much context as possible. Use the feature request template available when reporting a new issue.
+
+## Pull requests
+Every pull request description should include the number of the issue it's resolving. Usually this looks like "Closes #<>" text in the PR description.
+
+Pull requests with new features, bug fixes and improvements are very helpful and should remain focused on one main thing and avoid containing unrelated commits.
+Please stick to the coding conventions used throughout the project (indentation, accurate comments, etc.).
+
+Adhering to the following process is the best way to get your work included in the project:
+1. Fork the project, clone your fork, and configure the remotes.
+```bash
+git clone https://github.com/<your-username>/file.d.git
+cd file.d
+git remote add upstream [email protected]:ozontech/file.d.git
+```
+2. If you cloned a while ago, get the latest changes from upstream.
+```bash
+git checkout master
+git pull upstream master
+```
+3. Create a new topic branch (off the master branch) to contain your feature, change, or fix.
+  The branch name should have the following format <issue-no>-<short-topic-name>: the number of the issue that this branch solves, followed by a hyphen and a short name for the main feature you're developing.
+  Awesome branch names: `80-contrib-guide`, `76-ban-metric`.
+  Branch names that should be avoided: `no-gh-issue-number`, `80`, `very-long-feature-description-bla-bla-bla-bla`.
+4. Commit your changes in logical chunks. Please adhere to these [git commit message guidelines](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) or your code is unlikely be merged into the main project. Use Git's [interactive rebase](https://docs.github.com/en/get-started/using-git/about-git-rebase) feature to tidy up your commits before making them public.
+5. Locally merge the upstream master into your topic branch
+```bash
+git pull [--rebase] upstream master
+```
+6. Push the branch to your fork
+```bash
+git push origin <topic-branch-name>
+```
+7. Open a pull request with a clear title and description.
+
+
+## Collaborating guidelines
+
+The main rule for now is that every PR requires at least two approvals from the core file.d team members, unless it's a small fix (like a typo). Usually by approve we mean commment "LGTM" in the PR.
+
+Note that this set of rules can (and should) be extended in the future.  
+Feel free to discuss and propose improvements to this guidelines!
+

Makefile

@@ -1,5 +1,4 @@
-VERSION ?= v0.5.2
-
+VERSION ?= v0.5.3
 UPSTREAM_BRANCH ?= origin/master
 
 .PHONY: prepare

README.idoc.md

@@ -10,6 +10,10 @@
 
 > ⚠ Although we use it in production, `it still isn't v1.0.0`. Please, test your pipelines carefully on dev/stage environments.  
 
+## Contributing
+`file.d` is an open-source project and contributions are very welcome!
+Please make sure to read our [contributing guide](/CONTRIBUTING.md) before creating an issue and opening a PR!
+
 ## Motivation
 Well, we already have several similar tools: vector, filebeat, logstash, fluend-d, fluent-bit, etc.
 
@@ -41,11 +45,13 @@ TBD: throughput on production servers.
 
 **Output**: @global-contents-table-plugin-output|links
 
+
 ## What's next
 * [Quick start](/docs/quick-start.md)
 * [Installation](/docs/installation.md)
 * [Examples](/docs/examples.md)
 * [Configuring](/docs/configuring.md)
 * [Architecture](/docs/architecture.md)
-* [Contributing](/docs/contributing.md)
+* [Testing](/docs/testing.md)
+* [Contributing](/CONTRIBUTING.md)
 * [License](/docs/license.md)

README.md

@@ -10,6 +10,10 @@
 
 > ⚠ Although we use it in production, `it still isn't v1.0.0`. Please, test your pipelines carefully on dev/stage environments.  
 
+## Contributing
+`file.d` is an open-source project and contributions are very welcome!
+Please make sure to read our [contributing guide](/CONTRIBUTING.md) before creating an issue and opening a PR!
+
 ## Motivation
 Well, we already have several similar tools: vector, filebeat, logstash, fluend-d, fluent-bit, etc.
 
@@ -41,13 +45,15 @@ TBD: throughput on production servers.
 
 **Output**: [devnull](plugin/output/devnull/README.md), [elasticsearch](plugin/output/elasticsearch/README.md), [gelf](plugin/output/gelf/README.md), [kafka](plugin/output/kafka/README.md), [postgres](plugin/output/postgres/README.md), [s3](plugin/output/s3/README.md), [splunk](plugin/output/splunk/README.md), [stdout](plugin/output/stdout/README.md)
 
+
 ## What's next
 * [Quick start](/docs/quick-start.md)
 * [Installation](/docs/installation.md)
 * [Examples](/docs/examples.md)
 * [Configuring](/docs/configuring.md)
 * [Architecture](/docs/architecture.md)
-* [Contributing](/docs/contributing.md)
+* [Testing](/docs/testing.md)
+* [Contributing](/CONTRIBUTING.md)
 * [License](/docs/license.md)
 
 <br>*Generated using [__insane-doc__](https://github.com/vitkovskii/insane-doc)*

docs/contributing.md

@@ -0,0 +1,11 @@
+## Testing
+In order to start tests, use standard `go test` command:  
+```go
+go test ./...
+```
+
+If you want to launch only the fast tests, consider using `-short` flag.  
+In order to start end-to-end test you should add `e2e` tag:  
+```go
+go test -tags=e2e ./...
+```