The goal of the Second Screen Community Group (CG) is to explore use of secondary screens from Web pages. Specifically, the CG provides a venue for discussing and incubating early proposals that aim to:
Given wider support and adequate stability, proposals worked on in the CG will be considered for migration to an appropriate W3C or IETF Working Group. The above proposals go beyond the current scope of the Second Screen Working Group (WG).
Membership of the group is open to everybody. Upon joining the group, participants agree to the terms of the W3C Community Contributor License Agreement (CLA).
Under the previous charter, the Second Screen Community Group (CG) delivered the Presentation API Community Group Final Report Specification that provides an API for a Web page to display and control content on a secondary screen. The work was migrated to the W3C Second Screen Working Group (WG) and the Community Group Final Report was provided as input to the Presentation API that is now being worked on in the WG.
The Presentation API allows web applications to use secondary screens to display Web content. The initiating HTML page can request display of an HTML page on the second screen with a message channel between the two pages to enable communication and control. The two pages can both be rendered on the controlling user agent with just the video display sent to the second device (1-UA), or the second page can be rendered on the receiving user agent (2-UA).
The Presentation API abstracts away the means of connecting as well as the underlying connection technologies.
TBD
TBD
The group will only produce Specifications listed in this section.
To add any additional specifications, this Charter must be amended by the process described in the Amendments to the Charter section. All deliverables for which the CLA Patents section applies must be designated as such here.
The CLA Patents section does not apply to Non-Normative Reports. The group may produce such reports, as described in the Scope of Work section.
The CLA Patents section does not apply to Test Suites this group may produce. Any Test Suites developed will use the W3C Software and Document License.
It is anticipated that the group will collaborate with appropriate W3C Working Groups in order to transition specification proposals to the Recommendation Track.
The group operates under the Community and Business Group Process. Terms in this Charter that conflict with those of the Community and Business Group Process are void.
As with other Community Groups, W3C seeks organizational licensing commitments under the W3C Community Contributor License Agreement (CLA). Proposals in this Community Group charter are applicable "Specification" in the CLA. When people request to participate without representing their organization's legal interests, W3C will in general approve those requests for this group with the following understanding: W3C will seek and expect an organizational commitment under the CLA starting with the individual's first request to make a contribution to Deliverables. The section on Contribution Mechanics describes how W3C expects to monitor these contribution requests.
Community Group participants agree to make contributions in the GitHub repository for the project that they are interested in. This may be in the form of a pull request (preferred), by raising an issue, or by adding a comment to an existing issue.
Specifications created for proposals in the Community Group must use the W3C Software and Document License.
All Github repositories attached to the Community Group must contain a copy of the CONTRIBUTING and LICENSE files.
Note: this CG will not use a contrib mailing list for contributions since all contributions will be tracked via Github mechanisms (e.g. pull requests).
Participants in this group choose their Chair(s) and can replace their Chair(s) at any time using whatever means they prefer. However, if 5 participants, no two from the same organisation, call for an election, the group must use the following process to replace any current Chair(s) with a new Chair, consulting the Community Development Lead on election operations (e.g., voting infrastructure and using RFC 2777).
Participants dissatisfied with the outcome of an election may ask the Community Development Lead to intervene. The Community Development Lead, after evaluating the election, may take any action including no action.
This group will seek to make decisions when there is consensus. The Editor(s) of a specification will determine and record consensus decisions through the specification's GitHub repo issue list with assistance from the CG Chair(s). Members of the group may reopen issues with new technical information.
It is the Chairs' responsibility to ensure that the decision process is fair, respects the consensus of the CG, and does not unreasonably favour or discriminate against any group participant or their employer. With that said, the group favours forward motion and dissent will not be allowed to block work on a specification.
If substantial disagreement remains (e.g. the group is divided) and there is a call for assessing consensus after due consideration of different opinions, the Chair should record a decision and any objections. Participants may call for an online vote if they feel the Chair has not accurately determined the consensus of the group or if the Chair refuses to assess consensus. The call for a vote must specify the duration of the vote which must be at least 7 days and should be no more than 14 days. The Chair must start the vote within 7 days of the request. The decision will be based on the majority of the ballots cast.
Initially, the Editor(s) and Chair(s) are the only Committers. It is expected that participants can earn Committer status in a GitHub reposiroty through a history of valuable contributions as is common in open source projects.
The group will conduct all of its technical work on its GitHub repositories (and not in mailing list discussions). This is to ensure contributions can be tracked and to ensure that engagement will scale to a large number of proposals.
Any decisions reached at any meeting are tentative and should be recorded in the repository issues list. Any group participant may object to a decision reached at an online or in-person meeting within 7 days of publication of the decision provided that they include clear technical reasons for their objection. The Chairs will facilitate discussion to try to resolve the objection according to the Decision Process.
The group can decide to work on a proposed amended charter, editing the text using the Decision Process described above. The decision on whether to adopt the amended charter is made by conducting a 30-day vote on the proposed new charter. The new charter, if approved, takes effect on either the proposed date in the charter itself, or 7 days after the result of the election is announced, whichever is later. A new charter must receive 2/3 of the votes cast in the approval vote to pass. The group may make simple corrections to the charter such as deliverable dates by the simpler group decision process rather than this charter amendment process. The group will use the amendment process for any substantive changes to the goals, scope, deliverables, decision process or rules for amending the charter.