[docs] CONTRIBUTING.md and CODE_OF_CONDUCT.md

CODE_OF_CONDUCT.md

@@ -0,0 +1,74 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting Emily: [email protected]. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

CONTRIBUTING.md

@@ -0,0 +1,86 @@
+Contributing to k6
+==================
+
+Thank you for your interest in contributing to k6!
+
+(ﾉ◕ヮ◕)ﾉ*:・ﾟ✧
+
+Before you begin, make sure to familiarize yourself with the [Code of Conduct](CODE_OF_CONDUCT.md). If you've previously contributed to other open source project, you may recognize it as the classic [contributor covenant](http://contributor-covenant.org/).
+
+If you want to chat with the team or the community, you can join our Slack team: [LINK GOES HERE].
+
+Filing issues
+-------------
+
+Don't be afraid to file issues! Nobody can fix a bug we don't know exists, or add a feature we didn't think of.
+
+The worst that can happen is that someone closes it right away and points you in the right direction.  
+
+That said, "how do I..."-type questions are often more suited for Slack.
+
+Contributing code
+-----------------
+
+If you'd like to contribute code to k6, this is the basic procedure. Make sure to follow the **style guide** described below!
+
+1. Find an issue you'd like to fix. If there is none already, or you'd like to add a feature, please open one and we can talk about how to do it.
+
+   Remember, there's more to software development than code; if it's not properly planned, stuff gets messy real fast.
+
+2. Create a fork and open a feature branch based off develop - `feature/my-cool-feature` is the classic way to name these, but it really doesn't matter, as long as you don't hack directly on develop.
+
+3. Create a pull request - make sure you make it from your feature branch to develop!
+
+4. We well discuss implementation details until it's polished and perfect, then a maintainer will merge it.
+
+We use [git flow](http://nvie.com/posts/a-successful-git-branching-model/), so you may recognize our branching structure from, well, every other project that does this. If not, have a look at that post and you'll feel right at home in no time.
+
+Style guide
+-----------
+
+In order to keep the project manageable, consistency is very important. Most of this is enforced automatically by various bots.
+
+**Code style**
+
+As you'd expect, please adhere to good ol' `gofmt` (there are plugins for most editors that can autocorrect this), but also `gofmt -s` (code simplification), and don't leave unused functions laying around.
+
+Continous integration will catch all of this if you don't, and it's fine to just fix linter complaints with another commit, but you can also run the linter yourself:
+
+```
+gometalinter --config gometalinter.json --deadline 10m ./...
+```
+
+**Commit format**
+
+In order to keep the changelog easy to read, all commits must have one of the following prefixes:
+
+* `[feat]` - new features
+* `[fix]` - bug fixes
+* `[change]` - changed behavior
+* `[removed]` - something was removed
+* `[refactor]` - nothing added or removed
+* `[lint]` - fixed linter complaints
+* `[test]` - added or improved tests
+* `[test/fix]` - fixed broken tests
+* `[docs]` - docs and sample code
+* `[docs/fix]` - fixed doc or sample errors
+
+If your commit closes an issue, please [close it with your commit message](https://help.github.com/articles/closing-issues-via-commit-messages/), for example:
+
+```
+[feat] Added this really rad feature
+
+Closes #420
+```
+
+**Language and text formatting**
+
+Any human-readable text you add must be non-gendered (if applicable), and should be fairly concise without devolving into grammatical horrors, dropped words and shorthands. This isn't Twitter, but don't write a novel where a single sentence would suffice.
+
+If you're writing a longer block of text to a terminal, wrap it at 80 characters.
+
+**License**
+
+If you make a new source file, you must copy the license preamble from an existing file to the top of it. We can't merge a PR with unlicensed source files.
+
+This doesn't apply to documentation or sample code; only files that make up the application itself.