[GitHub] huijunwu closed pull request #2926: Update governance.md and clean up Twitter related content

[GitBox <gi...@apache.org>]

huijunwu closed pull request #2926: Update governance.md and clean up Twitter related content
URL: https://github.com/apache/incubator-heron/pull/2926
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/website/content/docs/contributors/community.md b/website/content/docs/contributors/community.md
index f3472c4e46..7d7785963e 100644
--- a/website/content/docs/contributors/community.md
+++ b/website/content/docs/contributors/community.md
@@ -7,7 +7,7 @@ title: Community
 
 Discussion about Heron happens on GitHub and over mailing list.
 
-* GitHub: [twitter/heron](https://github.com/apache/incubator-heron)
+* GitHub: [apache/incubator-heron](https://github.com/apache/incubator-heron)
 * Heron User Google Group: [heron-users@googlegroups.com](https://groups.google.com/forum/#!forum/heron-users)
 * Heron on Twitter: [@heronstreaming](https://twitter.com/heronstreaming)
 
@@ -41,8 +41,7 @@ you should post on [mailing list](https://groups.google.com/forum/#!forum/heron-
 of opening GitHub issues.**
 
 ### Submitting a Patch
-1. Read the Heron [governance plan](../governance) and accept the
-[Twitter Contributor License Agreement](https://engineering.twitter.com/opensource/cla) (CLA).
+1. Read the Heron [governance plan](../governance).
 
 2. Discuss your plan and design, and get agreement on
 [mailing list](https://groups.google.com/forum/#!forum/heron-users).
diff --git a/website/content/docs/contributors/governance.md b/website/content/docs/contributors/governance.md
index 4d9646bf7a..ef0fc455a6 100644
--- a/website/content/docs/contributors/governance.md
+++ b/website/content/docs/contributors/governance.md
@@ -6,40 +6,30 @@ The Heron project was initially developed at Twitter and is now led by a group o
 
 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
 Please also see our [contribution guidelines](../community).
 
 
 ### 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).  
-
-1. We require all contributors to agree to [Twitter's Contributor License Agreement (CLA)](../license).
-
-2. We accept well-written, well-tested functional contributions compatible with Bazel builds, in an appropriate directory with clearly documented support policies.
+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.
 
-3. We accept well-written, well-tested bug fixes to built-in functions.
+1. We accept well-written, well-tested functional contributions compatible with Bazel builds, in an appropriate directory with clearly documented support policies.
 
-4. 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.
+2. We accept well-written, well-tested bug fixes to built-in functions.
 
-5. We will not accept untested changes, except in very rare cases with appropriate cause.
+3. 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.
 
-6. We require a pre-commit code review from a core contributor for all changes. 
+4. We will not accept untested changes, except in very rare cases with appropriate cause.
 
-7. We will roll back changes if, for example, they break the internal Twitter development processes of any of the core contributors.
+5. We require a pre-commit code review from a core contributor for all changes. 
 
-8. 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.
+6. 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.
 
-9. 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.
+7. 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.
+Contact the heron developers at: dev@heron.incubator.apache.org.
 
-### 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.  
 ### Core Committers
-Contact the core team at: heron-dev@googlegroups.com.
 
 The current group is:
 


 

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services