docs: add Scope community baseline documentation (weaveworks#3192)

* Rename code of conduct for consistency

* Add maintainers file

* Steal governance and contributing documents from CNI

* docs: adapt goverance documents to Scope

Author: Alfonso Acosta

code-of-conduct.md CODE-OF-CONDUCT.md

@@ -0,0 +1,114 @@
+# How to Contribute
+
+Scope is [Apache 2.0 licensed](LICENSE) and accepts contributions via GitHub
+pull requests. This document outlines some of the conventions on development
+workflow, commit message formatting, contact points and other resources to make
+it easier to get your contribution accepted.
+
+We gratefully welcome improvements to documentation as well as to code.
+
+# Certificate of Origin
+
+By contributing to this project you agree to the Developer Certificate of
+Origin (DCO). This document was created by the Linux Kernel community and is a
+simple statement that you, as a contributor, have the legal right to make the
+contribution. See the [DCO](DCO) file for details.
+
+# Email, Chat and Community Meetings
+
+The project uses the the scope-community email list and Slack:
+- Email: [scope-community](https://groups.google.com/forum/#!forum/scope-community)
+- Chat: Join the [Weave community](https://weaveworks.github.io/community-slack/) Slack workspace and use the [#scope](https://weave-community.slack.com/messages/scope/) channel
+
+When sending email, it's usually best to use the mailing list. The maintainers are usually quite busy and the mailing list will more easily find somebody who can reply quickly. You will also be potentially be helping others who had the same question.
+
+We also meet regularly at the [Scope community meeting](https://docs.google.com/document/d/103_60TuEkfkhz_h2krrPJH8QOx-vRnPpbcCZqrddE1s/). Don't feel discouraged to attend the meeting due to not being a developer. Everybody is welcome!
+
+## Getting Started
+
+- Fork the repository on GitHub
+- Read the [README](README.md) for getting started as a user and learn how/where to ask for help 
+- If you want to contribute as a developer, continue reading this document for further instructions
+- Play with the project, submit bugs, submit pull requests!
+
+## Contribution workflow
+
+This is a rough outline of how to prepare a contribution:
+
+- Create a topic branch from where you want to base your work (usually branched from master).
+- Make commits of logical units.
+- Make sure your commit messages are in the proper format (see below).
+- Push your changes to a topic branch in your fork of the repository.
+- If you changed code:
+   - add automated tests to cover your changes
+- Submit a pull request to the original repository.
+
+## How to build and run the project
+
+```bash
+make
+./scope launch
+```
+
+## How to run the test suite
+
+You can run the linting and unit tests by simply doing
+
+```bash
+make tests
+```
+
+There are integration tests for Scope, but unfortunately it's hard to set them up in forked repositories and the setup is not documented. Help is needed to improve this situation: https://github.com/weaveworks/scope/issues/2192
+
+# Acceptance policy
+
+These things will make a PR more likely to be accepted:
+
+ * a well-described requirement
+ * tests for new code
+ * tests for old code!
+ * new code and tests follow the conventions in old code and tests
+ * a good commit message (see below)
+
+In general, we will merge a PR once two maintainers have endorsed it.
+Trivial changes (e.g., corrections to spelling) may get waved through.
+For substantial changes, more people may become involved, and you might get asked to resubmit the PR or divide the changes into more than one PR.
+
+### Format of the Commit Message
+
+We follow a rough convention for commit messages that is designed to answer two
+questions: what changed and why. The subject line should feature the what and
+the body of the commit should describe the why.
+
+```
+scripts: add the test-cluster command
+
+this uses tmux to setup a test cluster that you can easily kill and
+start for debugging.
+
+Fixes #38
+```
+
+The format can be described more formally as follows:
+
+```
+<subsystem>: <what changed>
+<BLANK LINE>
+<why this change was made>
+<BLANK LINE>
+<footer>
+```
+
+The first line is the subject and should be no longer than 70 characters, the
+second line is always blank, and other lines should be wrapped at 80 characters.
+This allows the message to be easier to read on GitHub as well as in various
+git tools.
+
+## 3rd party plugins
+
+So you've built a Scope plugin. Where should it live?
+
+Until it matures, it should live in your own repo. You are encouraged to annouce your plugin at the [mailing list](https://groups.google.com/forum/#!forum/scope-community) and to demo it at a [community meetings](https://docs.google.com/document/d/103_60TuEkfkhz_h2krrPJH8QOx-vRnPpbcCZqrddE1s/).
+
+If you have a good reason why the Scope maintainers should take custody of your
+plugin, please open an issue so that it can potentially be promoted to the [Scope plugins](https://github.com/weaveworks-plugins/) organization.

CONTRIBUTING.md

@@ -0,0 +1,36 @@
+Developer Certificate of Origin
+Version 1.1
+
+Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
+660 York Street, Suite 102,
+San Francisco, CA 94110 USA
+
+Everyone is permitted to copy and distribute verbatim copies of this
+license document, but changing it is not allowed.
+
+
+Developer's Certificate of Origin 1.1
+
+By making a contribution to this project, I certify that:
+
+(a) The contribution was created in whole or in part by me and I
+    have the right to submit it under the open source license
+    indicated in the file; or
+
+(b) The contribution is based upon previous work that, to the best
+    of my knowledge, is covered under an appropriate open source
+    license and I have the right under that license to submit that
+    work with modifications, whether created in whole or in part
+    by me, under the same open source license (unless I am
+    permitted to submit under a different license), as indicated
+    in the file; or
+
+(c) The contribution was provided directly to me by some other
+    person who certified (a), (b) or (c) and I have not modified
+    it.
+
+(d) I understand and agree that this project and the contribution
+    are public and that a record of the contribution (including all
+    personal information I submit with it, including my sign-off) is
+    maintained indefinitely and may be redistributed consistent with
+    this project or the open source license(s) involved.

DCO

@@ -0,0 +1,58 @@
+# Scope Governance
+
+This document defines project governance for the project. This is (and probably will always be) a Work in Progress.
+
+## Goals and Principles
+
+Scope's community goals and principles:
+
+1. Transition from a primarily Weaveworks project to a true community-driven project with autonomous governance. Weaveworks noticed interest from various actors and decided to nurture a community and see where it can lead the project.
+2. Fill-in the needs of the community with a chop-wood-and-carry-water attitude: expect to give back before you take if you want to make an impact. Demands and suggestions from community members will be taken into account but actions and help will be more-highly appreciated.
+
+## Code of Conduct
+
+The Scope community abides by the CNCF [code of conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md). Here is an excerpt:
+
+_As contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities._
+
+As a member of the Scope project, you represent the project and your fellow contributors.
+We value our community tremendously and we'd like to keep cultivating a friendly and collaborative
+environment for our contributors and users. We want everyone in the community to have
+[positive experiences](https://www.cncf.io/blog/2016/12/14/diversity-scholarship-series-one-software-engineers-unexpected-cloudnativecon-kubecon-experience).
+
+## Voting
+
+The Scope project aims to employ "organization voting" to ensure no single organization can dominate the project. [Alfonso Acosta](https://github.com/2opremio) will take of the initial maintenance until enough voters join the community. Once the community reaches critical mass and sufficient maintainers are designed, the voting-based governance will start.
+
+Individuals not associated with or employed by a company or organization are allowed one organization vote.
+Each company or organization (regardless of the number of maintainers associated with or employed by that company/organization) receives one organization vote.
+
+In other words, if two maintainers are employed by Company X, two by Company Y, two by Company Z, and one maintainer is an un-affiliated individual, a total of four "organization votes" are possible; one for X, one for Y, one for Z, and one for the un-affiliated individual.
+
+Any maintainer from an organization may cast the vote for that organization.
+
+For formal votes, a specific statement of what is being voted on should be added to the relevant github issue or PR, and a link to that issue or PR added to the maintainers meeting agenda document.
+Maintainers should indicate their yes/no vote on that issue or PR, and after a suitable period of time, the votes will be tallied and the outcome noted.
+
+## Changes in Maintainership
+
+New maintainers are proposed by an existing maintainer and are elected by a 2/3 majority organization vote.
+
+Maintainers can be removed by a 2/3 majority organization vote.
+
+## Approving PRs
+
+Non-specification-related PRs may be merged after receiving at least two organization votes.
+
+## Github Project Administration
+
+Maintainers will be given write access to the [weaveworks/scope](https://github.com/weaveworks/scope) GitHub repository.
+
+## Changes in Governance
+
+All changes in Governance require a 2/3 majority organization vote.
+
+## Other Changes
+
+Unless specified above, all other changes to the project require a 2/3 majority organization vote.
+Additionally, any maintainer may request that any change require a 2/3 majority organization vote.

GOVERNANCE.md

@@ -0,0 +1 @@
+Alfonso Acosta <fons@syntacticsugar.consulting> (@2opremio)