SIG and code governance docs

governance/SIG-charter-template.md

@@ -0,0 +1,35 @@
+# Proposed name: SIG-??????
+
+## Objective
+
+One or two sentences describing the group's purpose.
+
+## Membership
+
+*Who can join? How can they join? Who can read the group's activity?*
+
+Example:
+
+> Everyone involved in the packaging, distributing or embedding of TensorFlow is
+> welcome to join the group. To participate, request an invitation to join the
+> mailing list. Archives of the mailing list will be publicly accessible.
+
+## Resources
+
+*Links to essential resources: proposed mailing list, Github repo, key documents, etc.*
+
+## Contacts
+
+*Minimum highlight a group leader, and somebody to reach out to for
+administrative purposes*
+
+* *Project lead: A N Other [@githubhandle](https://github.com/githubhandle) -
+  another at companyname*
+* For administrative questions, contact Edd Wilder-James
+  [@ewilderj](https://github.com/ewilderj) - ewj at google
+
+## Code of Conduct
+
+As with all forums and spaces related to TensorFlow, SIG-?????? is subject to
+the [TensorFlow Code of
+Conduct](https://github.com/tensorflow/tensorflow/blob/master/CODE_OF_CONDUCT.md).

governance/SIG-request-template.md

@@ -0,0 +1,44 @@
+# Request for SIG
+
+## What is this group for?
+
+Describe the need the group fills. Who is the audience?
+Provide evidence that work is already ongoing in this area.
+
+## Who will be part of it?
+
+Describe:
+
+* group leader
+* a second for the leader
+* one or more interested parties who will also be in the group -- provide
+  evidence of the sustainability of the group
+
+What will be your membership policy?
+
+## What initial problems will the group tackle?
+
+*List potential goals for the group*
+
+## What modes of communication do you intend to use?
+
+*A mailing list is a minimum. We recommend regularly scheduled VC calls to focus
+on agenda items. Slack or other chat channels are optional.*
+
+## Launch plan
+
+*Describe how the group will be launched. Example follows*
+
+```
+1.  `VC call with initial interested parties to finalize charter and initial group goals`
+1.  `SIG set up with initial group members`
+1.  `SIG added to community pages on tensorflow.org`
+1.  `Write blog post about SIG and its goals`
+1.  `Leader starts off mailing list discussion about initial work items`
+```
+
+# Charter
+
+Please draft the SIG's charter using the [SIG Charter Template](SIG-charter-template.md).
+
+

governance/SIGS.md

@@ -0,0 +1,125 @@
+# TensorFlow Special Interest Groups (SIGs)
+
+## What makes a good SIG?
+
+The ideal scope for a SIG will meet a well-defined domain, where the majority
+participation will be from the community. Additionally, there should be
+sufficient evidence that there are community members willing to engage and
+contribute should the interest group be established.
+
+Not all SIGs will have the same level of energy, breadth of scope, or governance
+models, so we should expect some variability.
+
+## Non-goals: What a SIG is not
+
+The intent of a SIG is to facilitate collaboration on shared work. A SIG is
+therefore:
+
+*   **Not a support forum**: a mailing list and a SIG is not the same thing
+*   **Not immediately required**: early on in a project's life, you may not know if you have shared work or collaborators
+*   **Not free labor**: energy is required to grow and coordinate the work collaboratively.
+
+Our approach to SIG creation will be conservative: thanks to the ease of
+starting projects on GitHub, there are many avenues where collaboration can
+happen without the need for a SIG.
+
+## SIG playbook
+
+### Research and consultation
+
+Proposers of groups should gather evidence for approval, as specified below.
+Some possible avenues to consider are:
+
+*   A well-defined problem or set of problems the group would solve
+*   Consultation with community members who would benefit, assessing both the
+    benefit and their willingness to commit
+*   For existing projects, evidence from issues and PRs that contributors care
+    about the topic
+*   Potential goals for the group to achieve
+*   Resource requirements of running the group
+
+Even if the need for a SIG seems self-evident, the research and consultation is
+still important to the success of the group.
+
+### Creating the new group
+
+The new group should follow the below process for chartering. In particular, it
+must demonstrate:
+
+*   A clear purpose and benefit to TensorFlow (either around a sub-project or
+    application area)
+*   Two or more contributors willing to act as maintainers, existence of other
+    contributors, and evidence of demand for the group
+*   Resources it will initially require (usually, mailing list and regular VC
+    call.)
+
+Approval for the group will be given by a decision of the TF Community Team,
+defined as being the maintainers of the _tensorflow/community_ project. The team
+will consult other stakeholders as necessary.
+
+Before entering the formal parts of the process, it is advisable to consult with
+the TensorFlow community team, *[email protected]*. It is highly
+likely that conversation and iteration will be required before the SIG request
+is ready.
+
+The formal request for the new group is done by submitting a charter as a PR to
+_tensorflow/community_, and including the request in the comments on the PR (see
+template below). On approval, the PR for the group will be merged and the
+required resources created.
+
+### Template Request for New SIG
+
+This template will be available in the community repo: [SIG-request-template.md](SIG-request-template.md).
+
+### Chartering
+
+Each group will be established with a charter, and be governed by the TensorFlow
+code of conduct. Archives of the group will be public. Membership may either be
+open to all without approval, or available on request, pending approval of the
+group administrator.
+
+The charter must nominate an administrator. As well as an administrator, the
+group must include at least one maintainer as lead (these may be the same
+person), who will serve as point of contact for coordination as required with
+the TF community team.
+
+This charter will be posted initially to the group mailing list. The _community_
+repository in the TensorFlow Github organization will archive such documents and
+policies ([example from Kubernetes](https://github.com/kubernetes/community)).
+As any group evolves its practices and conventions, we expect it to document
+these within the relevant part of the community repository.
+
+### Collaboration and inclusion
+
+While it is not mandated, the group should choose to make use of collaboration
+via scheduled conference call or chat channels to conduct meetings. Any such
+meetings should be advertised on the mailing list, and notes posted to the
+mailing list afterwards. Regular meeting helps drive accountability and progress
+in a SIG.
+
+TensorFlow community team members will proactively monitor and encourage the
+group to discussion and action as appropriate.
+
+### Launching
+
+Required activities:
+
+*   Notifying TensorFlow general mailing lists (discuss@, developers ML) of new group
+*   Adding SIG to the community pages on TensorFlow web site
+
+Optional activities:
+
+*   Creating a blog post for the TensorFlow Medium.com blog community
+
+### Health and termination of SIGs
+
+The TF community team will make best effort to ensure the health of SIGs. From
+time to time it will request the SIG lead to provide a report of the SIG's work,
+which will be used to inform the broader TensorFlow community of the activity of
+the group.
+
+If a SIG no longer has a useful purpose or interested community, it may be
+archived and cease operation. The TF community team reserves the right to
+archive such inactive SIGs, in order to maintain the health of the project at
+large, though it is a less preferable outcome. A SIG may also opt to disband if
+it recognizes it has reached the end of its useful life.

governance/code-and-collaboration.md

@@ -0,0 +1,93 @@
+
+# TensorFlow Governance: Code and Collaboration
+
+## Projects
+
+A **project** is the primary unit of collaboration. It can either have its own
+repo, or be a part of another repo (e.g. a directory in _tensorflow/models_).
+
+
+## Contributors
+
+Anyone can submit a PR contribution to any project, as long as they have signed
+the CLA and follow the guidelines in
+[CONTRIBUTING.md](https://github.com/tensorflow/tensorflow/blob/master/CONTRIBUTING.md).
+Their code must be reviewed by a maintainer, and must pass all applicable tests.
+
+Code reviews check for code quality and style, including documentation, and
+enforce API compatibility guarantees and other policies. Contributions may be
+rejected for strategic reasons unrelated to the code in question. For instance,
+because a feature may be too costly to maintain, or because it would duplicate
+APIs.
+
+## Maintainers
+
+A project has one or more **maintainers**. 
+
+Maintainers have write access to the repo containing their project. That means
+they can review PRs—an approving review will allow PRs to be merged. They can
+also change labels (which means they can trigger tests), add assignees and
+reviewers, and they can be assigned to issues and PRs.
+
+Note that for some repos being a maintainer may not allow direct commit access,
+which is reserved for administrators or bots. *tensorflow/tensorflow* is a case
+in point, due to the complexity around releasing, only a small group of release
+engineers are administrators. In this case maintainers have approval rights.
+
+If a repo is shared between many projects, we use GitHub's CODEOWNERS to
+identify owners and route PRs to them for review. Because of the way CODEOWNERS
+works, it is not possible to use the GitHub routing mechanism everywhere -- for
+example, the TensorFlow CODEOWNERS file is mainly for informational purposes, as
+to not impede merges.
+
+Once there are more than a couple of maintainers for a project, we will create a
+GitHub team for the project maintainers. This allows for easier maintenance, and
+opens up some [GitHub
+tooling](https://help.github.com/articles/about-team-discussions/) for
+communication. Larger projects can facilitate coordination and contribution
+through establishing a
+[TensorFlow SIG](SIGS.md).
+
+
+### Repositories requiring synchronization
+
+For some projects initiated by Google (including the _tensorflow/tensorflow_
+repo), the infrastructure which synchronizes and merges internal and external
+changes requires that all merges are performed by a Google employee. In such
+cases, Google sets up an on-call rotation which merges PRs once they pass tests
+(and a specific label is applied to the PR in order to notify the rotation to
+merge it). This does not preclude non-Google contributors from becoming
+maintainers. In this case, the maintainers of the project decide on what should
+be merged, then the actual merging is performed as a service. In some cases,
+Google-internal tests may fail and may have to be fixed: the Google employee
+will work with the submitter to achieve this.
+
+
+### Achieving maintainer status
+
+Maintainers may elevate a contributor to maintainer status, on evidence of
+previous contributions and established trust.
+
+## Collaboration
+
+Maintainers are free to agree on their preferred form of collaboration and
+decision making, with the requirement that regular communication about decisions
+must be made publicly accessible—this can happen after the fact, for example in
+the form of publishing meeting minutes, reviews, or announcements. Communication
+about topics such as admitting other maintainers, or as of yet undisclosed
+security issues, can be kept confidential.
+
+If significant engagement from multiple parties is encountered, the group may
+request the formation of a SIG to formalize collaboration and cooperation. The
+threshold for SIG formation includes:
+
+*   A clearly stated purpose
+*   Two or more non-maintainers willing to contribute code, and evidence of
+    existing demand for the group
+*   Project maintainers willing to be in the group and shepherd contributions
+
+For further details on SIGs, read [TensorFlow SIGs](SIGS.md).
+
+As with most structures, a project doesn't need a SIG to get started, but should
+find a home in one if it has proven itself as an ongoing concern, as SIGs are
+the primary organizational vehicle for the contributor community.