Outline Hubot Evolution process

CONTRIBUTING.md

@@ -0,0 +1,56 @@
+# Hubot Evolution Process
+
+[all-proposals]: https://github.com/hubotio/evolution/pulls?utf8=%E2%9C%93&q=is%3Apr
+[chat]: https://hubot-slackin.herokuapp.com/
+
+This document outlines how a Hubot feature grows from a rough idea into something that can improve workflows for millions of developers.
+
+This process covers all changes to Hubot, such as new features or adding, changing, or removing any APIs (no matter how small). Smaller changes, such as bug fixes, optimizations, or other improvements can be contributed via the [normal contribution process](https://github/github/hubot/blob/master/CONTRIBUTING.md) on the relevant repository.
+
+## Goals
+
+This process aims to leverage the collective ideas, insights, and experience of the community to improve the Hubot project and ecosystem. Its two primary goals are:
+
+* Engage the wider community in the ongoing evolution of Hubot, and
+* Maintain the vision and conceptual coherence of Hubot.
+
+There is a natural tension between these two goals. Open evolution processes are, by nature, chaotic. Yet, maintaining a coherent vision requires some level of coordination. This process aims to strike a balance that best serves the entire Hubot ecosystem.
+
+## Participation
+
+Everyone is welcome to propose, discuss, and review ideas to improve Hubot.
+
+The Hubot maintainers are responsible for the strategic direction of Hubot. Maintainers initiate, participate in, and manage the public review of proposals and have the authority to accept or reject changes to Hubot.
+
+## How to propose a change
+
+1. **Check prior proposals**: many ideas come up frequently, and may either be in active discussion, or may have been discussed and rejected. Please check the [list of proposals][all-proposals] before proposing something new.
+1. **Consider the goals of the upcoming release**: Each major release is focused on a [specific set of goals](README.md) described early in the release cycle. When proposing a change, please consider how your proposal fits in with the larger goals of the upcoming release. Proposals that are out of scope may still be considered, but will likely be postponed.
+1. **Socialize the idea**: Before starting the review process, it's helpful to gauge interest from the community. Ideally, the idea would have come up in a discussion in another issue or in [chat][] and the consensus was to start an evolution proposal.
+1. **Develop the proposal**: open a Pull Request with a rough sketch of the proposal using the [proposal template](template.md) in the [_drafts](https://github.com/hubotio/evolution/new/master/_drafts) directory. Prototyping an implementation and its uses along with the proposal is encouraged, because it helps ensure both technical feasibility of the proposal as well as validating that the proposal solves the problems it is meant to solve.
+1. **Request a review**: When you are ready for feedback from the Hubot community, change the frontmatter in your proposal from `status: in-progress` to `status: in-review`.
+1. **Address feedback**: be responsive to questions and feedback about the proposal. When the proposal is sufficiently detailed and clear, and addresses feedback from earlier discussions of the idea, the `accepted` label will be added and a maintainer will be assigned to manage the review.
+
+## Review process
+
+When you change the frontmatter in your proposal from `status: in-progress` to `status: in-review`, a message will be posted in the [#evolution channel in chat][chat] requesting feedback from the community.
+
+Reviews should usually be completed in a single week, but can run longer for particularly large or complex proposals. To avoid delays, it is important that the proposal authors be available to answer questions, address feedback, and clarify their intent during the review period.
+
+After feedback from the community has been gathered, the maintainers will make a decision on whether to `accept` or `reject` the proposal.
+
+Once a proposal has been accepted, the file should be renamed to `proposals/###-feature-name.md`, where `###` is the Pull Request number. It is usually up to the proposal author to implement it or discuss with the maintainers who will lead the implementation.
+
+Once a proposal has been implemented, the Pull Request will be merged.
+
+## Proposal states
+
+A proposal can be in one of several states:
+
+* `in-progress`: The authors are still working on the proposal and are not yet ready for review.
+* `in-review`: The proposal is ready for review and comments from the community.
+* `withdrawn`: The proposal has been withdrawn by the original submitter.
+* `deferred`: Consideration of the proposal has been deferred because it does not meet the [goals of the upcoming release](README.md). Deferred proposals will be reconsidered when scoping the next major release.
+* `accepted`: The proposal has been accepted and is either awaiting implementation or is actively being implemented.
+* `rejected`: The proposal has been considered and rejected.
+* `implemented`: The proposal has been implemented. Add the `version` to the frontmatter of the proposal and merge the Pull Request.

template.md

@@ -0,0 +1,27 @@
+---
+status: in-progress
+---
+
+# Feature name
+
+> A short description of what the feature is. Try to keep it to a single-paragraph "elevator pitch" so the reader understands what problem this proposal is addressing.
+
+## Motivation
+
+> Describe the problems that this proposal seeks to address. If the problem is that some common pattern is currently hard to implement, show how one can currently get a similar effect and describe its drawbacks. If it's completely new functionality that cannot be emulated, motivate why this new functionality would help developers create better workflows. Include any links to Issues or Pull Requests where the need for this feature came up.
+
+## Proposed solution
+
+> Describe your solution to the problem. Provide examples and describe how they work. Show how your solution is better than current workarounds.
+
+## Detailed design
+
+> Describe the design of the solution in detail. The detail in this section should be sufficient for someone who is *not* one of the authors to be able to reasonably implement the feature.
+
+## Backward compatibility
+
+> Describe how this change affects compatibility with existing community packages. Will they break? Will they produce different behavior? If "yes" to either of these, is it possible to support the old behavior alongside the new behavior? Can scripts be written in a way that they work before and after this change?
+
+## Alternatives considered
+
+> Describe alternative approaches to addressing the same problem, and why you chose this approach instead.