Skip to content

Latest commit

 

History

History
890 lines (721 loc) · 48.7 KB

Organization_Operational_Process.md

File metadata and controls

890 lines (721 loc) · 48.7 KB
Raw

Organization Operational Document

Governance

Meetings and Decision Making

Processes

Intellectual Property Rights

Terminology and Conventions

Governance and Roles

Membership Levels

The Organization Membership Levels are:

  • Steering
  • General
  • Contributor

Steering and General memberships also require the organization to be a Linux Foundation member. Contributor members do not also need to be a Linux Foundation member.

Membership Benefits

Membership Benefits
Steering General Contributor
Pricing
Price $20,000 $5,000 $0
Leadership
Eligible to participate in the Steering Committee Yes
Eligible to vote in Working Group meetings Yes Yes
Eligible to observe Working Group meetings Yes Yes Yes
Contribution
Contribute to Working Groups Yes Yes Yes
Propose new working groups Yes Yes Yes
Counted towards minimum support quorum of a Work Package Yes Yes
Voting
Approval of Publications, Working Group formation and Governance Yes
Vote in a Steering Committee Supermajority vote Yes
Vote in a Working Group Supermajority vote Yes Yes
Access to Meetings
Attend Working Group meetings Yes Yes Yes
Attend SIG meetings Yes Yes Yes
Attend Marketing Committee meetings Yes Yes Yes

Organization Structure

Committees and Working Groups

  • Steering Committee

  • Specification Working Group

  • Open Source Working Group

  • Marketing Committee

The Steering Committee decides on the priorities or order of business for the organization. The Working Groups and Marketing Committee organise work packages and report to the Steering Committee.

Special Interest Groups (SIGs)

  • AI Special Interest Group
  • Hardware Special Interest Group
  • Image Special Interest Group
  • Language Special Interest Group
  • Math Special Interest Group

The Special Interest Groups (SIGs) facilitate an open forum for sharing knowledge, demonstrating new work and discussing relevant technical topics.

The "rules of the road" for SIG meetings are as follows:

  • No confidential or trade secrets should be shared
  • Discussions should be high level and should avoid implementation details, these discussions and work belong in the Working Groups

Technical Steering Committee

One of the more important duties of the Steering Committee is the approval of the Specifications and other works produced as a consensus product of the Working Groups.

  • For at least the first two years after formation of this project, each Steering Member may designate a Steering Committee participant.
  • Effective as of the later of: either (i) two years after formation of this project, or (ii) 60 days after the Steering Committee reaches 15 members, the Steering Committee will select the Steering Committee from among the Steering Member membership class, according to the following procedure:
    • All members of the Steering Member membership class are eligible to be nominated for, and seek election to, each Steering Member position.
    • The Steering Committee will invite nominations for the election for open Steering Committee positions from all members of the Steering Member membership class. Any nominations must be submitted by the nominee in writing no later than 30 days after the date of the invitation from the Steering Committee.
    • The vote for the election of open Steering Committee positions shall create a new term of [two] years from the date of such vote.
    • Each then-current Steering Committee member may vote with respect to all Steering Committee candidates, including, without limitation, voting for themself.
    • The vote for all Steering Committee positions will be held at the same time, and shall be conducted by secret ballot.
    • In each election, each Steering Committee member will be given the same number of votes as the number of open Steering Committee positions. By way of example, if 11 Steering Committee are open, each Steering Committee member will be given 11 votes to vote for candidates seeking a position. Each Steering Committee member may cast one vote per candidate. Candidates receiving the highest number of votes will be elected to an open Steering Committee position; provided, however, in order to be elected a candidate must receive a minimum of 50% of the votes cast for such open position. If all Steering Committee positions are not filled pursuant to the procedure above, then the Steering Committee may choose to conduct a run-off election for each remaining open position.
  • Each Steering Committee meeting is called on a regular interval, although this interval can be ad-hoc as long as the proper notice is given.
  • Proper notice of the Steering Committee (SC) meeting is given to its representatives including an agenda with the topics to be voted by the SC having been prepared with a proper notice period, typically one week.
  • The Steering Committee will endeavor to make all decisions by consensus. Where the Steering Committee cannot reach consensus with respect to a particular decision, the Steering Committee will make that decision by a Supermajority Vote.
  • Motions are made and accepted by a vote of the designated Steering Committee members. Members may debate the motion, make changes if thought fit, accept or reject the motion. It is an important principle that there is an opportunity for questions and clarifications of the motion in the process.
  • The votes are taken only by the chairperson of the Steering Committee, unless a deputy has been appointed by the Steering Committee.
  • Minutes of the meeting are taken to record the attendance, votes and their outcomes.

Working Groups (WG)

Working Groups (WGs) are chartered by the Steering Committee to handle one or more Work Packages

Marketing Committee

The Steering Committee will appoint the chairperson for the Marketing Committee

The group typically focuses on the following:

  • Managing internal and external communications.
  • Responsibility for press releases.
  • Maintains the website.
  • Coordinates participation at events.
  • Manages the communication strategy.

The Technical Steering Committee approves any plans made by the committee as well as press release content. Marketing Committee participation is open to all members.

Organization Roles

Participants

Note: A Participant is any individual creating content or commenting on an issue or pull request.

  • Participants MUST read the Project documentation (e.g.: this operational document, contribution guidelines, README, and Release Planning documents) before attenting to submit an Issue or Pull Request
  • Participants are not allowed to fork a project to build a feature that has been rejected by the Working Group

Editors

Note: An Editor is a subset of Participants who have been given write access to the repository for a specification. They will advance the day-to-day evolution of the specification

Note: Editor. “Editors” are responsible for ensuring that the contents of the document accurately reflect the decisions that have been made by the group, and that the specification adheres to formatting and content guidelines. A Working Group may select a new Editor or Editors upon Approval of the Working Group Participants.

Maintainers

“Maintainers” are responsible for organizing activities around developing, maintaining, and updating the specification(s) and/or open source projects developed by the Working Groups. Maintainers are also responsible for determining consensus and coordinating contributions and reviews. Each project will designate one or more Maintainer. A project may select a new or additional Maintainer(s) upon Approval of the Working Group.

  • Maintainers SHOULD keep communications with the members via GitHub Issues or Pull Requests rather than one to one communications
  • Maintainers MUST keep the project documentation up to date (e.g.: contributing, readme and release planning documents)
  • Maintainers SHOULD use GitHub "Labels" to indicate the type of “Review & Approval” assigned to each Pull Request
  • Maintainers SHOULD close contributions that do not follow the rules, or meet the right quality or do not fall within the agreed scope of the project

Working Group Chairperson

  • In performing their tasks, Working Group Chairpersons SHALL maintain strict impartiality and act in the interest of the Organization.

  • Chairperson MAY limit the amount of time allocated to a particular agenda item or discussion point.

  • Chairperson SHALL, after a reasonable period of discussion time, use means to quickly reach a decision including (but not limited to):

    • a statement of the Chairperson’s view of group consensus, which shall be accepted by the group if there are no objections.
    • assignment of action items to progress the issue in a short a time period as possible.
    • invite single or few objectors to no longer sustain their objections.
    • informal voting.
    • formal voting.

  • Chairperson MAY require that new information be provided about an issue before earlier decisions can be reopened/revisited.

  • The work and progress of the group is appropriately communicated through regular status reports to the Steering Committee.

  • The Chairperson MAY delegate tasks to another vice-chairperson, including chairing the group as and when necessary.

The checklist for Working Group chairs outlining the general roles and responsibilities is available in this Appendix

Elections

The chairperson roles for the Steering Committee, Specification Working Group, Open Source Working Group and Marketing Committee are intended to be appointed to individuals through an annual democratic election. The Steering Committee will determine the election process.

Meetings and Decision Making

Note: Effective group meetings allow the Steering Committee, Committee Teams and Working Groups to discuss complex issues and talk through ideas and solutions. It is recommended to keep a Meeting Minutes record for each meeting.

  • Working Groups are encouraged to schedule regular conference calls.
  • The Meetings MUST be announced at least 7 days in advance for conference calls, and 1 month for face to face meetings.
  • All the Organization members are contractually bound by the IPR policy under terms of the Membership Application and these IPR Guidelines must be followed.
  • Meetings SHALL have an antitrust statement and an IPR information where a reminder of the IPR policy and the duties and obligations of members is provided.
  • A meeting attendee list MUST be produced for each meeting. This is especially necessary to determine which members can vote in a Supermajority vote.

Meeting Agenda

Note: An effective Meeting Agenda enables teams to organize its topics and give a fair chance for every topic to be discussed.

Meeting Minutes

Note: It is important to record the key issues discussed during the meeting, motions proposed or voted, and activities to be undertaken. Also, it should be recorded meeting attendance, specially if there is a voting requirement associated with members attendance.

Please refer to the Organization Agenda & Meeting Minutes Template

Technical Decision Making

Decision Making

Decision Making - Consensus-Based Decision Making

Working Groups make decisions through a consensus process (“Approval” or “Approved”). While the agreement of all Participants is preferred, it is not required for consensus. Rather, the chairperson will determine consensus based on their good faith consideration of a number of factors, including the dominant view of the Participants and nature of support and objections. The chairperson will document evidence of consensus in accordance with these requirements. Consensus will not be deemed to have been met in the event of a sustained objection from one or more Working Group participants.

Appeal Process - Decisions may be appealed, and that appeal will be considered by the chairperson in good faith, who will respond in writing within a reasonable time.

Ways of Working - Inspired by American National Standards Institute’s (ANSI) Essential Requirements for Due Process, Community Specification Working Groups must adhere to consensus-based due process requirements. These requirements apply to activities related to the development of consensus for approval, revision, reaffirmation, and withdrawal of Community Specifications. Due process means that any person (organization, company, government agency, individual, etc.) with a direct and material interest has a right to participate by: a) expressing a position and its basis, b) having that position considered, and c) having the right to appeal. Due process allows for equity and fair play. The following constitute the minimum acceptable due process requirements for the development of consensus.

Openness - Participation shall be open to all persons who are directly and materially affected by the activity in question. There shall be no undue financial barriers to participation. Voting membership on the consensus body shall not be conditional upon membership in any organization, nor unreasonably restricted on the basis of technical qualifications or other such requirements. Membership in a Working Group’s parent organization, if any, may be required.

Lack of Dominance - The development process shall not be dominated by any single interest category, individual or organization. Dominance means a position or exercise of dominant authority, leadership, or influence by reason of superior leverage, strength, or representation to the exclusion of fair and equitable consideration of other viewpoints.

Balance - The development process should have a balance of interests. Participants from diverse interest categories shall be sought with the objective of achieving balance.

Coordination and Harmonization - Good faith efforts shall be made to resolve potential conflicts between and among deliverables developed under this Working Group and existing industry standards.

Consideration of Views and Objections - Prompt consideration shall be given to the written views and objections of all Participants.

Written procedures - This governance document and other materials documenting the Community Specification development process shall be available to any interested person.

Chairpersons need to ensure efficient and effective decision-making:

  • The decision making process is intended to be as inclusive as possible.
  • Attempts to use consensus to make decisions should be taken.
  • If consensus cannot be reached, voting mechanisms MAY be used.
  • Formal notice SHALL be given for decision making, e.g.:
    • Inclusion of a document on an agenda, proposing a specific decision to be taken (e.g. Pull Request).
    • Inclusion of an item directly in the agenda (e.g. proposed next meeting date).
    • Items proposed for approval via the group mailing list (e.g. agreement on a document revision).
    • Inclusion of a document for decision in an e-vote (Supermajority) vote.

The above list is not exhaustive.

  • Proposals SHALL be available for a given period.

Seeking Consensus

  • Groups shall endeavour to reach consensus on all decisions.
  • Informal methods of reaching consensus are encouraged (e.g. a show of hands virtual or physical).
  • Groups SHOULD attempt to ensure contributions relating to the same subject matter are considered together before being disposed.
  • However the chairperson SHALL ensure that progress is not delayed by unavailable contributions or participants.
  • Agreement SHALL be sought in all forms of meeting.

Handling objections when seeking consensus

  • Objections from a small minority SHOULD be minuted and the objecting delegates SHOULD be questioned if having their objections minuted is sufficient and they agree to not sustain their objections.
    • If such agreements are secured, then there is consensus for approving the proposal.
    • If such agreements are not secured, then the proposal is not agreed and further action SHALL be taken (e.g. the proposal is withdrawn, updated, or voted on).
    • Members are discouraged from sustaining their objections when it is clear that they would be overruled by a vote were one to take place.
  • In real-time meetings, consensus can be determined by receiving no sustained objections to a proposal.
    • Efforts to immediately resolve or record objections can be taken to attempt to achieve consensus.
  • Where attendance is sparse when viewed from normal participation levels, potentially controversial proposals SHOULD be made available to the broader membership.
  • The chairperson is responsible for ensuring such opportunity for participation in the decision making process.
  • Sparsely attended meetings SHOULD NOT be used to drive through proposals that would not have broad support.
  • Following a decision-making meeting, a summary of decisions and document dispositions SHALL be published as soon as is practical.
    • This will be addressed if the meeting minutes are available in a timely fashion.
  • When there is insufficient time for review in a real-time meeting, non-real-time consensus approaches SHOULD be considered.
  • In non-real time meetings consensus SHOULD be developed by using a suitable period.
    • Using the group mailing list
    • Using GitHub "Review and Approval" label
  • Proposals SHALL be available for a given period.

Using Supermajority vote to achieve agreement

Phrasing of Voting Questions

  • The chairperson ensures that questions to be voted upon SHALL be phrased in a concise and unambiguous manner.
  • Questions SHOULD NOT be phrased as the “The group SHALL not do xyz”. Examples of appropriate questions are:
    • SHALL the group agree the Specification?
    • SHALL the liaison be approved?
    • SHALL the new Work Package be approved?
    • SHALL the existing Work Package be stopped?
    • If the issue is to choose between two options (i.e. A or B), an example of the appropriate question may be:
    • SHALL the group agree Option A or Option B?
  • The option receiving no less than 3/4 of the Supermajority Votes SHALL be the decision of the group.
  • If the issue is to choose between three or more options, the group SHOULD use informal voting to reduce the number of options to two, and then use formal voting, if necessary.

Voting on Technical Issues

  • Before voting, a clear definition of the issues SHALL be provided by the chairperson.
  • Members eligible to vote, SHALL only be entitled to one vote each.
  • Each member MAY cast its vote as often as it wishes, and the last vote it casts counts.
  • Voting MAY be performed electronically.
  • Voting MAY be performed by show of hands and members announcing their vote verbally one by one, or paper ballots.
  • The result of the vote SHALL be recorded in the meeting minutes.
  • Groups MAY use informal voting to reach consensus. If the Group is still unable to reach consensus, then a formal vote MAY be taken.
  • Each member’s electronic vote SHALL be electronically acknowledged to confirm participation in the vote.
  • The voting period for proposals are:
    • In-person-meetings require at least 30 days prior written notice
    • Teleconference meetings require at least 7 days prior written notice
    • Electronic voting MUST remain open for no less than 7 days.

Processes

Specification Approval Process

Review & Approval

Review & Approval

When developing a standard the approval or rejection of a contribution follows a democratic process; the majority.

The goal for standards development is to reach interoperability, therefore “forking” is not the solution to a technical dispute. If there is a sustainable objection in a contribution the resolution is via a vote, see Seeking Consensus.

The Review & Approval process implies that all the contributions need to be accepted by the Working Group.

Review & Approval Process

  • Review period:
    • Period of time during which the contribution will be under review before being merged.
      • The minimum period shall be:
        • 0 days for minor, editorial changes (examples include typos or small improvements to the documentation of an API)
        • 7 days for major changes to non-API modifications (such as changes to the documentation of an API)
        • 14 days for any changes to API definitions and new major features

0 days imply that the contribution can be merged without Working Group review

Working Groups can decide in their own CONTRIBUTION guidelines what a minor or major change means.

  • Comments or Objections:

    • During the Review & Approval process members MAY raise comments or objections.
      • Comments MUST be taken in consideration by the Working Group, but they MAY be dismissed if they group thinks that they are not relevant.
      • Objections MUST be taken in consideration and they cannot be dismissed by the Working Group without being reviewed.
      • If a contribution receives an objection the group MUST resolve the issue, with the person that raise the objection, before deciding the status of the contribution. If the objection is sustained, meaning the person doesn’t remove it, then the group will have to recur to a vote to resolve it.

  • Approval Criteria:

    • A contribution is considered approved and therefore it can be merged if:
      • The contribution has not received any sustainable objection during the review period, AND
      • At least 3 reviewers have indicated that they agree with the contribution
    • If during the review period a contribution receives a comment or objection, it is up to the group or maintainer to accept it or not. In any case, in order to merge the contribution at least 3 reviewers MUST indicate that they agree with the contribution.

UXL Foundation Process Flows

Work Packages

UXL Foundation Work Units

UXL Foundation Work Units

Work Package

  • The Work Package (WP) SHALL describe the scope and expected deliverables and SHALL require WG approval
  • WPs are the means by which release packages (version x.y.z) are defined
Epics
  • It could be a feature, customer request or business requirement
  • It is recommendable to define a list of Epics that will be part of the release package for the corresponding Work Package
  • The WG SHOULD define a placeholder for each Epic with few lines of description
  • The Epics can be broken down in user stories and tasks which are not defined in detail at the creation of the Work Package

Specification Development Process

  1. Pre-Draft. Any Participant may submit a proposed initial draft document as a candidate Draft Specification of that Working Group. The Maintainer will designate each submission as a “Pre-Draft” document.
  2. Draft. Each Pre-Draft document of a Working Group must first be Approved to become a ”Draft Specification”. Once the Working Group approves a document as a Draft Specification, the Draft Specification becomes the basis for all going forward work on that specification.
  3. Working Group Approval
    1. Once a Working Group believes it has achieved the objectives for its specification as described in the Scope, it will submit it to the Steering Committee for approval.
    2. The Steering Committee may not Approve a Draft Specification as an “Approved Specification” (and, for the purposes of the Patent Policy, an “Approved Deliverable”), prior to expiration of a review period of not less than 45 days after delivery of the Draft Specification to all members of the Steering Committee and Working Groups.
    3. Any Draft Specification approved by vote of the Steering Committee becomes an “Approved Specification” and, for the purposes of the Patent Policy, an “Approved Deliverable”.
  4. Publication and Submission. Upon the designation of a Draft Specification as an Approved Specification by the Steering Committee, the Maintainer will publish the Approved Specification in a manner agreed upon by the Steering Committee (i.e., Working Group Participant only location, publicly available location, Working Group maintained website, Working Group member website, etc.). The publication of an Approved Specification in a publicly accessible manner must include the terms under which the Approved Specification is being made available.
  5. Submissions to Standards Bodies. The Steering Committee of the UXL Foundation may submit a Draft Specification or Approved Specification to another standards development organization by vote. No Draft Specification or Approved Specification may be submitted to another standards development organization without the vote of the Steering Committee. Upon an affirmative vote of the Steering Committee regarding such a submission, the applicable Maintainer or Maintainers, or any other individuals so directed by the Steering Committee, will coordinate the submission of the applicable Draft Specification or Approved Specification to the other standards development organization as directed by the Steering Committee. Working Group Participants that developed that Draft Specification or Approved Specification agree to grant the copyright rights necessary to make those submissions.

Specifications Life Cycle

Specifications Life Cycle

In this section the diagram below depictures the development phases of technical documents.

Technical Specifications Development Phases
Phase Description
Work Package In this phase the group agrees the scope of the work to be developed.
Any member can provide a new Work Package proposal, the document is discussed among the group and further elaborated. The group will vote whether the Work Package is formally approved and endorsed by the majority of the group or rejected.
If the proposal is approved, the Work Package is moved to the next phase, Technical Development.
Development A Technical Specification MAY be composed of one or more documents:
  • Requirements Document, (RD)
    • It contains the business requirements (non technical requirements). The business requirements are derived from the Use Cases described in the RD document.
  • Architecture Document, (AD)
    • Document that describes all functional elements of the system and its interfaces or reference points.
  • Technical Specification Document(s), (TS)
    • It refers to a set of documented requirements to be satisfied by a material, design, product, or service. It helps to understand the configuration and architecture of a system.
  • Supporting Document(s), (SUP)
    • Contains profile data, metadata, schemas, etc.
Note: in some cases the group MAY agree to develop a single document that contains the above list as sections. Each document will follow the phases described in the above diagram.
Consistency Review In this phase, the document(s) developed by the WG are formally reviewed by the group. A Review period is open for members to submit their comments. After this period, the Working Group will address the issues received.
WG Approval Once the WG completes the Consistency Review the document(s) MUST be agreed by the WG (in a Review & Approval) before sending the document(s) to the Steering Committee for formal Ratification.
Ratification Once the WG approves the document(s), the document(s) are sent to the Steering Committee for Ratification.
Publication | Maintenance Upon Steering Committee Ratification, the document(s) are ready for Publication.
  • To publish the document(s), the Maintainer will create a new Release Tag.
  • A new Release Tag will be produce with the content in the "main" branch and stored in the Release section of the GitHub repository.
  • The WG SHOULD open a *dialogue* with the public via GitHub Discussions.
  • The input collected during the Maintenance phase SHOULD be used to improve the Technical Specifications as well as to collect business requirements for future releases.

UXL Foundation Technical Specifications Development Phases

UXL Foundation Technical Specifications Development Phases

Best Practices for Specifications and Open Source Projects

GitHub Flows

It is suggested to follow the principles of Trunk Based Development whenever is possible to avoid divergence and forking of the projects.

UXL Foundation Git Flow

UXL Foundation GitHub Workflow GitHub Work Flow - Public Repositories
Branch Description
Rel vX.Y.Z Release-tag's contain all the different versions of the Technical Specifications that have been approved by the Working Group and ratified by the Technical Steering Committee. The name of the release tag will follow [Semantic Versioning](#semantic-versioning) principles.
main This branch contains the latest version of the Technical Specfication approved by the Working Group. Its content will be moved into a release-tag, afer the Consistency Review and Technical Steering Committee Ratification phases.

GitHub Access Rights

GitHub Access Rights
Role Access Rights
Participants TRIAGE - Can read and clone this repository. Can also create issues and pull requests.
Editors WRITE - Can read, clone, and push to this repository. Can also manage issues and pull requests.
Maintainer ADMINISTRATOR - Can read, clone, and push to this repository. They can also manage issues, pull requests, and some repository settings.

Documentation

Semantic Versioning

Semantic Versioning

Semantic Versioning Document Version
Field Use Description
X Major Version Indicator This mandatory field SHALL identify the major version of the document as determined by the WG. Major versions contain major feature additions; MAY contain incompatibilities with previous document or specification revisions; and MAY change, drop, or replace existing interfaces. Initial releases are “1_0”.
Y Minor Version Indicator Minor version of the document. This mandatory field SHALL identify the minor version of the document. It is incremented every time a minor change is made to the approved document version. Minor versions MAY contain minor feature additions, be compatible with the preceding Major_Minor specification revision, and MAY provide evolving interfaces. The initial minor release for any major release is “0”, i.e. 1_0
Z Service Indicator Service indicator for the document. Incremented every time a corrective update is made to the Approved (not draft) document version by the WG. This field is OPTIONAL, and SHALL be provided whenever a service release of the document is made. The first service indicator release SHALL be “_1” for any Major_Minor release. Service indicators are intended to be compatible with the Major_Minor release they relate to but add bug fixes. No new functions will be added through the release of Service Indicators.

Proposing a new SIG or Working Group

As opportunities to collaborate on new areas, or to focus on specific subject matter are identified new groups may be set up within the foundation.

Any member of the UXL Foundation can propose a new Special Interest Group or Working Group. The member should create an issue on the UXL Foundation repository with the following information.

  • Proposed group name
  • Proposed group leader(s)
  • Outline of the purpose of the group and benefit to the foundation
  • Outline of the planned output of the group
  • Names of other members who support the proposal

Propose a new group

Propose a new group

Proposing a new project or specification

As opportunities to bring in new projects or specifications to the foundation arise, the following will be used to guide the discussion and approval for adding a new project or specification to the foundation.

Any member of the UXL Foundation can propose adding a new project or specification to the foundation. The member should create an issue on the UXL Foundation repository with the following information.

  • Proposed project or specification name
  • Proposed maintainers for the project or specification
  • Outline of the purpose of the project or specification and benefit to the foundation
  • Information about the project or sp
  • Names of other members who support the proposal

Propose a new project or standard

Propose a new project or standard

Intellectual Property Rights

Copyright

The foundation does not require that every contributor include their copyright notice in contributed files.

Instead, a more general statement can be used, where is the specific name of that being contributed to e.g. oneDNN:

  • Copyright Contributors to the <project name> project.

This statement is intended to communicate the following:

  • the work is copyrighted;
  • the contributors of the code licensed it, but retain ownership of their copyrights; and

Other Copyright Rules

  • If your contribution contains content from a third party source who didn't contribute it themselves, then you should not add the notice above.
  • You should not change or remove someone else's copyright notice unless they have expressly (in writting) permitted you to do so.

Licenses

Software Code Licenses

Ideally, the project SHOULD communicate the software license information via three different metods:

  • In the README file
  • Inside of the repository with a License.txt document
  • Inside of each code file created by the group

Statement in README File

Insert in the README file the Apache 2.0 License:

[![License](https://img.shields.io/badge/License-Apache_2.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)

The README file will display:

  • License

In addition, it is recommended to include a plain text statement of the license in the README file, for accessibility purposes as well as enabling parsing by automated tooling. This can be done by including a "License" section with:

  • This project is licensed under the Apache 2.0 license.

License File in the Repository

Insert in the repository a file called License.txt.

The Maintainer can copy the corresponding license file and upload it to the project repository.

License Reference in each Source Code File

The recommendation is that projects SHOULD use SPDX short-form license identifiers in all source code and documentation files that are original to the project.

Each source code created by the project SHOULD have one of these SPDX license identifiers: (depending on the type of source code license allocated to the project)

  • for Apache 2.0 license:
# SPDX-License-Identifier: Apache-2.0

# Copyright Contributors to the UXL Foundation

If the project needs to include source code or documents from a different upstream project, the recommendation is to retain those files in unmodified form (don't add identifiers).

Also consider to:

  • keep these files in sync with the upstream project
  • ask the upstream project to insert the identifiers on their source code files / documents.

[Organization_Name] Software License Policy

This policy is intended to assist UXL Foundation Technical Working Groups to handle Software Licenses in the Projects.

Recommended SafeGuards

1. Escalation Path

  • Any question about licensing should be resolved by the Working Group (WG), if the WG cannot resolve it, then the question can be sent to the Steering Committee
    • LF doesn’t provide legal advice or comments about license compatibility (unless LF identifies some clear incompatibilities)
    • The Steering members may need to involve their Legal Counsel to make a license decision
    • Only the Steering Committee can decide if a component created by the Project can be delivered under a different license than the Project License

2. Linked Libraries & 3 Party Software

  • It is not recommended to pull software code, under different license than the Project License, into the project repository. Use linked libraries instead.
  • If 3rd party software is embedded, it should be under the Project License. If different licenses are used, then create a NOTICE file listing all the 3rd party license notice.
  • As a rule, if a software code developed by UXL Foundation has an external dependency to a code distributed under GPL 2.0, then UXL Foundation members need to consult with their legal counsel to decide under what license the UXL Foundation software code should be released. In other words, if the code developed by UXL Foundation doesn’t work without the reference to the external code under GPL 2.0, then the license to release the UXL Foundation code should be evaluated.

3. License Compatibility

  • Any upstream license needs to be compatible with the Project License
  • Any copyleft license inserted in a project repository needs to be flagged to the Organization Team

4. Binary Distribution

  • It is a good practice to point users to the libraries so they can compile them on their own
  • If the group decides to ship binaries, the binaries should be ONLY for the code developed under the Project License.
  • If there are any other binaries under different license, then each binary should be distributed in its own files. Binaries under a license different than the Project License CANNOT packed with the same binaries than the ones created by the group

Technical Document License

In projects where the main deliverables are technical documents, each document MUST have a legal disclaimer.

The legal disclaimer to insert in each project document SHOULD be:

© `UXL Foundation` YEAR, All rights reserved.

“THESE MATERIALS ARE PROVIDED “AS IS.”  The parties expressly disclaim any warranties 
(express, implied, or otherwise), including implied warranties of merchantability, non-infringement, 
fitness for a particular purpose, or title, related to the materials. The entire risk as to 
implementing or otherwise using the materials is assumed by the implementer and user. 

IN NO EVENT WILL THE PARTIES BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF 
INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES 
OF ACTION OF ANY KIND WITH RESPECT TO THIS DELIVERABLE OR ITS GOVERNING AGREEMENT, WHETHER 
BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT 
THE OTHER MEMBER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.”

GitHub

Terminology and Conventions

Language

The default language for writing documentation is American English, English (United States).

Conventions

The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

Note: It is recommended to use the following terminology when writing Technical Specifications:

MUST: This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.

SHOULD: This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

MAY: This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

Definitions

Definitions
Committee Team A group chartered by the Steering Committee to perform specific support tasks
Editor(s) A member of a Working Group who is responsible to edit and maintain a document.
e-Vote Electronic Vote.
Issue(s) An important topic or problem for debate or discussion. Normally Issues are tracked in Github.
Maintainer A Maintainer is the person (or persons) *responsible for the direction or movement* of an Organization Working Group or those contributors who lead an open source project. They are committed to improving, driving, and ensuring an outcome and are the final control point for contributions.
Member(s) A person that belongs to a company that has signed the Membership Agreement, Project and Working Group Charter(s)
Membership Application A document that provides legal information about rights and obligations of being a member company of Organization.
Participant A Participant is any individual creating content, code or commenting on an Issue or Pull Request.
Project Charter A legal document that describes the Organization Project.
Pull Request It indicates what changes are suggested to a branch in a repository on GitHub.
Release It is the distribution of the final version of a specification or software project
Review & Approval A special process that is used to convey agreement or disagrement on a topic.
Semantic Versioning It is a versioning scheme to convey backwards or not backwards compatibility of a release.
Steering Committee A committee that decides on the priorities or order of business of the Organization
Supermajority Vote An affirmative vote of no less than 3/4 eligible members
Working Group A group of experts working together to achieve predefined objectives. The group formalize its objectives and goals in a formal document, the Working Group Charter.
Working Group Charter A document that contains the scope, objectives and goals of a particular group.
Work Package It is a group of related tasks within a project. Each Work Package can be broken down into one or more groups.

Abbreviations

Definitions
AD Architecture Document
IPR Intellectual Property Rights
WG Working Group
PR Pull Request
REQ Requirements
RD Requirement Document
SUP Supporting Document
TS Technical Specification
TSC Technical Steering Committee