├── .github └── state.yml ├── template.md ├── README.md └── CONTRIBUTING.md /.github/state.yml: -------------------------------------------------------------------------------- 1 | # Configuration for Probot state plugin - https://github.com/probot/state 2 | states: 3 | - In Progress 4 | - In Review 5 | - Withdrawn 6 | - Deferred 7 | - Accepted 8 | - Rejected 9 | - Implemented 10 | 11 | project: Proposals 12 | -------------------------------------------------------------------------------- /template.md: -------------------------------------------------------------------------------- 1 | --- 2 | state: In Progress 3 | --- 4 | 5 | # Feature name 6 | 7 | > 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. 8 | 9 | ## Motivation 10 | 11 | > 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. 12 | 13 | ## Proposed solution 14 | 15 | > Describe your solution to the problem. Provide examples and describe how they work. Show how your solution is better than current workarounds. 16 | 17 | ## Detailed design 18 | 19 | > 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. 20 | 21 | ## Backward compatibility 22 | 23 | > 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? 24 | 25 | ## Alternatives considered 26 | 27 | > Describe alternative approaches to addressing the same problem, and why you chose this approach instead. 28 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Hubot Evolution 2 | 3 | [proposal-status]: https://apple.github.io/swift-evolution/ 4 | 5 | This repository tracks the ongoing evolution of [Hubot](https://github.com/github/hubot). It contains: 6 | 7 | * [Goals](#goals) for upcoming releases. 8 | * [Proposals](https://github.com/hubotio/evolution/projects/1) to change Hubot 9 | * The [process](CONTRIBUTING.md) that governs the evolution of Hubot. 10 | 11 | This document describes the high-level goals for the next couple months. Smaller features or changes independent of these larger goals will also be made, and some goals may not be reached. 12 | 13 | ## Goals 14 | 15 | Hubot aims to be an automation framework optimized for developers and developer workflows, with great integration with the most popular chat clients and developer tools, and an active community that is sharing scripts and best practices. 16 | 17 | The current focus is: 18 | 19 | 1. Return the project to a “maintained” status by creating a core team, documenting all policies and processes, reviewing stale Issues and Pull Requests, and establishing a regular release cadence. 20 | 2. Modernize the community by consolidating officially supported repositories into one GitHub organization, creating a place for users to get support and contributors to collaborate, improving contributor experience, and establishing this process for evolving Hubot going forward. 21 | 3. Modernize the project by translating CoffeeScript to JavaScript, improving integration with various developer tools, and adding features that make it easier for developers to automate their workflow. 22 | 23 | The high-priority features for upcoming releases are: 24 | 25 | * **Commands**: an explicit interface for exposing discrete pieces of functionality as an alternative to regular expressions (like Slack’s slash commands), along with an RPC spec and implementation for exposing commands to and consuming commands from other services. 26 | 27 | * **Multiple adapters and archetypes**: Adding support for multiple adapters in a single instance, and some notion of archetypes (chat, deployment, CI, github, etc) will allow Hubot scripts to become the glue between the various tools and systems in a developer's workflow. 28 | 29 | * **GitHub integration**: merge with [@probot](https://github.com/probot) and build out first-class support for GitHub. 30 | 31 | * **Improved chat client integration**: slash commands, rich messages, and interactive scripts on platforms that support it. 32 | 33 | --- 34 | 35 | _Thanks to the team at Apple for laying the groundwork for this process, which was inspired by and largely borrowed from [Swift Evolution](https://github.com/apple/swift-evolution)._ 36 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Hubot Evolution Process 2 | 3 | [all-proposals]: https://github.com/hubotio/evolution/projects/1 4 | [chat]: https://hubot-slackin.herokuapp.com/ 5 | 6 | This document outlines how a Hubot feature grows from a rough idea into something that can improve workflows for millions of developers. 7 | 8 | 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.com/hubotio/hubot/blob/master/CONTRIBUTING.md) on the relevant repository. 9 | 10 | ## Goals 11 | 12 | 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: 13 | 14 | * Engage the wider community in the ongoing evolution of Hubot, and 15 | * Maintain the vision and conceptual coherence of Hubot. 16 | 17 | 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. 18 | 19 | ## Participation 20 | 21 | Everyone is welcome to propose, discuss, and review ideas to improve Hubot. 22 | 23 | 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. 24 | 25 | ## How to propose a change 26 | 27 | 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. 28 | 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. 29 | 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. 30 | 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. 31 | 1. **Request a review**: When you are ready for feedback from the Hubot community, change the frontmatter in your proposal from `state: In Progress` to `state: In Review`. 32 | 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. 33 | 34 | ## Review process 35 | 36 | When you change the frontmatter in your proposal from `state: In Progress` to `state: In Review`, a message will be posted in the [#evolution channel in chat][chat] requesting feedback from the community. 37 | 38 | 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. 39 | 40 | After feedback from the community has been gathered, the maintainers will make a decision on whether to `accept` or `reject` the proposal. 41 | 42 | 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. 43 | 44 | Once a proposal has been implemented, the Pull Request will be merged. 45 | 46 | ## Proposal states 47 | 48 | A proposal can be in one of several states: 49 | 50 | * **In Progress**: The authors are still working on the proposal and are not yet ready for review. 51 | * **In Review**: The proposal is ready for review and comments from the community. 52 | * **Withdrawn**: The proposal has been withdrawn by the original submitter. 53 | * **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. 54 | * **Accepted**: The proposal has been accepted and is either awaiting implementation or is actively being implemented. 55 | * **Rejected**: The proposal has been considered and rejected. 56 | * **Implemented**: The proposal has been implemented. Add the `version` to the frontmatter of the proposal and merge the Pull Request. 57 | --------------------------------------------------------------------------------