GitHub Repositories for OASIS TC Members’ Chartered Work

OASIS TCs that wish to develop TC chartered deliverables using dedicated version control system support may request the creation of GitHub public repositories and/or a Subversion (SVN) repository. Whereas SVN repositories are allocated on a one-per-TC basis, multiple GitHub repositories may be requested by any TC for distinct development projects. Each GitHub repository will be configured using the default setup to support issues tracking, project boards, and a Wiki instance.

Note: As of 2017, OASIS supported two separate Organizations for public GitHub repositories, as described in detail below:

Governance. A GitHub repository for OASIS TC Members’ chartered work is governed by the same OASIS policies as govern a TC Wiki, a TC Subversion repository, a TC JIRA Issues Tracker, a TC Kavi document repository, etc. Unlike the OASIS TC Open Repositories — which also make use of GitHub public repositories for development of open source licensed assets — GitHub repositories for OASIS TC Members’ Chartered Work follow rules in the OASIS TC Process, OASIS IPR Policy, and related policies.

Repository Request. When any TC has decided to create a new GitHub repository, a TC officer (Chair or Secretary) may request a public GitHub repository using the online request form.

Maintainers. When a TC makes request for creation of a GitHub repository, one or more TC Members must be designated to serve as initial Maintainer(s) — sometimes also called “Committer(s)”. Additional or substitute Maintainers may be designated at any time from among qualified TC Members.

All TC members may “contribute” substantive content, as well as provide input via GitHub Issues, comments, GitHub conversations, Wiki edits (etc), but they do not have full Maintainer responsibilities, described below. A regular TC Member can be a “contributor” in the GitHub defined sense: “contributor is someone who has contributed to a project by having a pull request merged but does not have collaborator [ viz, direct write] access.”

A Maintainer, much like a prose specification editor, holds the pen and has direct write access to the GitHub “code” repository. A Maintainer accepts input from all TC members, evaluating it for incorporation into revised content. TC member input is expected in the form of GitHub Issues/Comments, GitHub conversations, pull requests, but might also be taken from the TC discussion list, or from TC meetings.

A Maintainer thus serves in an editorial capacity by having responsibility for assigning and closing issues, creating and associating milestones, creating releases, designating a default branch, creating and applying labels, initiating conversations on pull requests, merging and closing pull requests, assigning evaluation of a pull request, resolving merge conflicts, etc. The Maintainers may also monitor repository activity to help ensure that substantive contributions are made only by TC Members or by parties who agree to the terms of the OASIS Feedback License, as explained in the repository’s CONTRIBUTING file.

Initial Repository Content. At startup, each TC GitHub repository will include default files README, CONTRIBUTING, and LICENSE, provided as boilerplate by OASIS Staff. Maintainers should ensure that content in the CONTRIBUTING and LICENSE files remains unaltered; content in the README file may be adapted to reflect the TC’s project goals (viz., in sections and subsections following “Further Description of this Repository”).

Substantive Contributions and Public Feedback. Contributors to a TC GitHub Repository are expected to be Members of the associated OASIS Technical Committee, for any substantive contributions. Anyone wishing to actively participate in the TC’s technical activity is invited to join as a TC Member. Public feedback on repository content is also accepted: persons who are not TC members are invited to open issues and provide comments using a TC Repository’s GitHub Issues tracking facility or using the TC’s comment list. All such content created in GitHub Issues and/or posted to the TC’s archived comment list is governed by the terms of the OASIS Feedback License.

OASIS TC Open (Source) Repositories versus Repositories for TC Members’ Chartered Work

I. OASIS TC Open Repositories

  • 1)Who contributes? Anyone, OASIS member or not, may fully participate in any repository effort, including OASIS TC Members in any TC and Members in no OASIS TC whatsoever
  • 2) Rules and guidelines? Code development practices and process governed by TC Open Repository Guidelines and Procedures. The governance rules for making substantive contributions include terms presented in the Contributor License Agreements (CLAs), including the required Individual Contributor License Agreement for all contributors, and the Entity Contributor License Agreement when applicable.
  • 3) Public feedback? Rules provide no direct support for submitting public feedback to the sponsoring TC itself, since repository assets are not OASIS TC Work Products
  • 4) Asset use by OASIS TC(s)? Assets developed in the repository may be contributed to any OASIS TC (for use in Work Products) by a TC Member, at TC Member discretion
  • 5) Inbound? Input licensing is governed by the signed Individual Contribution License Agreement (CLA)
  • 6) Outbound? Outbound licensing is governed by FOSS (open source) licenses: BSD-3-Clause, MIT, Apache v2.0, CC-BY 2.0, CC 4.0, Eclipse Public License v1.0, etc
  • 7) Organization URI? GitHub projects use the Organization oasis-open ( )

II. Repositories for TC Members’ Chartered Work

  • 1) Who contributes? Anyone may comment, issue pull requests, and create issues; but routine substantive contributions are expected only from sponsoring TC member participants; all contributions, whether substantive and expected or not, are governed by the terms of the OASIS Feedback License
  • 2) Rules and guidelines? Code and asset development practices and process are governed by the OASIS TC Process and the OASIS Committee Operations Process. The Contributor License Agreements (CLAs) used in OASIS TC Open Repositories are not applicable to GitHub repositories for TC Members’ Chartered work.
  • 3) Public feedback? Policy supports submission of public feedback to the TC, equivalent to submission via the TC comment list, using GitHub Issues, Comments, Pull Requests, Gists, Threaded Conversations…
  • 4) Asset use by OASIS TC(s)? Assets developed in the repository are automatically (inherently) part of official TC work, eligible for incorporation into any TC Work Product
  • 5) Inbound? Input licensing is governed by OASIS policies and agreements for contributions [def] and feedback [def]: IPR Policy: IPR Mode, Copyright Notices, Feeback License
  • 6) Outbound? Outbound licensing is governed by OASIS policies for TCs, including terms in the TC’s selected IPR Mode
  • 7) Organization URI? GitHub projects use the Organization oasis-tcs ( )

Feedback or questions. Send email to TC Administration.

Approved: Fri, 2016-07-29
Effective: Mon, 2016-08-01