Governance

The Heron project was initially developed at Twitter and is now led by a group of self-managing core contributors with additional contributions by the community. Core contributors expect that candidate core contributors will successfully submit a number of patches or new functionality, demonstrate an understanding of project codebase, and express a willingness to be active group members before they become core contributors.

Core contributors are added by two supporting votes from core contributors on the mailing list and no core contributor veto within four business days.

Twitter uses the open source Heron project release builds in production and remains committed to contributing to the open source project roadmap. Therefore, core contributors will roll back changes if, for example, they break the internal Twitter production processes.

Accepting Contributions

Policy

Heron is supported by core contributors, a group of people who cooperatively and actively support the overall project. In contrast, general contributors are not actively supporting the overall project, but instead are contributing individual changes. At this time, the majority of core contributors are currently employed by Twitter or have previously been employed by Twitter (see below for the full list).

We accept well-written, well-tested functional contributions compatible with Bazel builds, in an appropriate directory with clearly documented support policies.

We accept well-written, well-tested bug fixes to built-in functions.

We accept well-written, well-tested feature contributions if a core contributor assumes support responsibilities, i.e., readily answers support questions and works on bugs. This includes feature contributions from external contributors. If there is no core contributor to support a feature, then we will deprecate and subsequently delete the feature - we will give three months’ notice in such cases.

We will not accept untested changes, except in very rare cases with appropriate cause.

We require a pre-commit code review from a core contributor for all changes.

We will roll back changes if, for example, they break the internal Twitter development processes of any of the core contributors.

We are implementing an open governance model where multiple parties have commit access, roll-back rights, and can provide explicit support for features or rules. Contributions are subject to approval (or in rare circumstances veto) by core committers.

We will work with interested parties to improve existing extension points and to establish new extension points if they do not run counter to the internal requirements of any of the core contributors.

Are you done open sourcing Heron?

We hope the open source process is complete. We currently have all code reviews, bug tracking, and design decisions happening publicly, with the Heron community involved. However, as Heron is used in production at Twitter, some changes may simply appear in the Heron repository based on Twitter’s needs, at Twitter’s discretion.. Despite this occasional need to remain flexible in updating the project, we want to support external developers and collaborate to develop and support additional features. Thus, we are opening up the code, even though some of the development is still happening internal to Twitter. Please let us know if anything seems unclear or unjustified as we transition to an open model.

Are there parts of Heron that will never be open sourced?

No - all components of Heron will be fully open sourced and able to be supported by open source tools. Twitter will use the open source releases in production. As with others who may implement and contribute to the Heron project, Twitter may use Heron with some functionality, or employ technology complementing Heron, that is not currently planned to become open sourced.