From 5ae2b326e977b30315e9ba38a9aa538e1938b843 Mon Sep 17 00:00:00 2001 From: James Rosewell Date: Tue, 1 Sep 2020 20:03:17 +0100 Subject: [PATCH] Initial decentralized web interest group charter. --- decentralized-charter.html | 486 +++++++++++++++++++++++++++++++++++++ 1 file changed, 486 insertions(+) create mode 100644 decentralized-charter.html diff --git a/decentralized-charter.html b/decentralized-charter.html new file mode 100644 index 00000000..53ae1459 --- /dev/null +++ b/decentralized-charter.html @@ -0,0 +1,486 @@ + + + + + + + Decentralized Web Interest Group Charter + + + + + + + + + + +
+

Decentralized Web Interest Group Charter

+

The mission of the Decentralized Web Interest Group is to evolve recommendations + to further the W3C’s One Web purpose by identifying, balancing and mitigating the unintended impacts of proposals + early in the process, encouraging uniform change, and promoting + OpenStand principles.

+ + +

This proposed charter is available + on GitHub. + Feel free to raise issues. +

+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ Start date + + [dd monthname yyyy] (date of the "Call for Participation", when the charter is approved) +
+ End date + + [dd monthname yyyy] +
Charter extensionSee Change History. +
+ Chairs + + [chair name] (affiliation) +
+ Team Contacts + + [team contact name] (0.1 FTE) +
+ Meeting Schedule + + Teleconferences: topic-specific calls may be held or somthing else +
+ Face-to-face: we will meet during the W3C's annual Technical Plenary week; additional + face-to-face meetings may be scheduled by consent of the participants, usually no more than 3 per year. +
+ +

Note: The W3C Process + Document requires “The level of confidentiality of the group's proceedings and deliverables”; however, it + does not mandate where this appears. Since all W3C Working Groups should be chartered as public, this notice has + been moved from the essentials table to the communication section.

+
+ +
+

Scope

+

The web is the primary method of accessing information and services for over 4,000,000,000 people. The + decentralized nature of the web has given individuals and organizations a platform to communicate and operate + businesses around the world.

+

For a decentralized system to properly function, each system component must interact and function in a + consistent, reliable, and stable fashion. Standards enable these decentralized components to interact and + function as if they were an integrated, centralized system. Without the proper assessment, changes to web + standards can thus have significant impacts on people, industries and societies that are challenging for any one + individual or group to foresee.

+

Where changes to web standards impact stakeholder groups that are underrepresented within the W3C these + unintended consequences are often missed or discovered late in the process.

+

To address this challenge, DWIG develops guidelines to assist specification authors in identifying, balancing + and mitigating unintended consequences early in the specification development process. This input enables + proposal authors to address those concerns that might otherwise be raised later as issues or objections, thus + reducing the overall time from proposal to consensus.

+

DWIG may provide input on request to other W3C groups developing web standards to help identify early impacts + on the broader web community beyond the focus of their specification.

+

DWIG provides short commentary on matters presented to the AC for consideration where there is a risk the + matter will impact on the stability or decentralized nature of the web.

+

DWIG aims to include members with diverse skillsets and backgrounds to ensure its work benefits from + disciplines such as business, economics, law, policy and product, whose broad experience are often + underrepresented in other specific interest, incubation and working groups.

+

The web must be a stable and sustainable place for all to operate if the W3C are to continue to advance its + mission.

+
+

Out of Scope

+

The following features are out of scope, and will not be addressed by this Interest group.

+
    +
  • DWIG does not incubate standards or specifications work to avoid overlap with other incubation, interest + and working groups.
  • +
  • DWIG does not define policy decisions related to what are “good” or “bad” changes, but instead provides + guidance to proposal authors and reviewers to ensure they consider potential impacts to stability and + decentralized nature of the web beyond the scope of their group.
  • +
+
+
+ +
+

+ Deliverables +

+

DWIG maintains a Self-Review Questionnaire for concerns of Decentralization, Choice, Auditability, and + Accountability that contribute to the decentralized, stable One Web.

+

DWIG will maintain an introductory document to help proposal authors better understand foreseeable impacts of + their work by summarising and linking to external documents and bodies of work related to relevant topics.

+

DWIG may publish other documents consistent with the above scope.

+

Note: drafts of success + criteria and the questionnaire + have been produced within the Improving Web Advertising + Business Group.

+ +

More detailed milestones and updated publication schedules are available on the group publication status page.

+ +
+

Timeline

+

Put here a timeline view of all deliverables.

+
    +
  • October 2020: First teleconference
  • +
  • October 2020: Draft of Self-review Questionnaire
  • +
  • November 2020: Finalize first draft of Self-review Questionnaire
  • +
+
+
+ +
+

Success Criteria

+
    +
  • Reduce the time associated with the specification development process by helping proposal authors consider a + wider range of issues during the inception of their specifications.
  • +
  • Foreseeable impacts associated with Web standards are mitigated and avoided early in the specification + development process.
  • +
  • Wider adoption of changes in a manner that supports the decentralized, stable One Web.
  • +
+
+ +
+

Coordination

+

For all specifications, this Interest Group will seek horizontal review for + accessibility, internationalization, performance, privacy, and security with the relevant Working and Interest + Groups, and with the TAG. + Invitation for review must be issued during each major standards-track document transition, including FPWD and at least + 3 months before CR, + and should be issued when major changes occur in a specification.

+

Issue: The paragraph above replaces line-item liaisons and dependencies with individual + horizontal groups. There's been a suggestion to name and individually link the specific horizontal groups + inline, instead of pointing to a page that lists them.

+

Issue: The requirement for an invitation to review after FPWD and before CR may seem a bit + overly restrictive, but it only requires an invitation, not a review, a commitment to review, or even a response + from the horizontal group. This compromise offers early notification without introducing a bottleneck.

+

Additional technical coordination with the following Groups will be made, per the W3C Process Document:

+

In addition to the above catch-all reference to horizontal review which includes accessibility + review, please check with chairs and staff contacts of the Accessible + Platform Architectures Working Group to determine if an additional liaison statement with more specific + information about concrete review issues is needed in the list below.

+
+

W3C Groups

+
+
[other name] Working Group
+
[specific nature of liaison]
+
+

Note: Do not list horizontal groups here, only specific WGs relevant to your work.

+
+
+

External Organizations

+
+
[other name] Working Group
+
[specific nature of liaison]
+
+
+
+ +
+

+ Participation +

+

Participation in DWIG is open to the public. Participants who do not represent a W3C Member should join as + Invited Experts. Invited Experts in this group are not + granted access to Member-only information.

+

Anyone may subscribe to the group's public mailing list and engage in discussion. Those who intend to + contribute to deliverables will be asked to join the group.

+

The group encourages questions, comments and issues on its public mailing lists and document repositories, as + described in Communication.

+

Participants in the group are required (by the W3C Process) to follow the W3C Code of Ethics and Professional Conduct.

+
+ +
+

+ Communication +

+

+ Technical discussions for this Interest Group are conducted in public: the meeting minutes from + teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue + tracking will be conducted in a manner that can be both read and written to by the general public. Working + Drafts and Editor's Drafts of specifications will be developed on a public repository and may permit direct + public contribution requests. The meetings themselves are not open to public participation, however. +

+

+ Information about the group (including details about deliverables, issues, actions, status, participants, and + meetings) will be available from the Decentralized Web Interest Group home page. +

+

+ Most Decentralized Web Interest Group teleconferences will focus on discussion of particular specifications, and + will be conducted on an as-needed basis. +

+

+ This group primarily conducts its technical work on GitHub + issues. + The public is invited to review, discuss and contribute to this work. +

+

+ The group may use a Member-confidential mailing list for administrative purposes and, at the discretion of the + Chairs and members of the group, for member-only discussions in special cases when a participant requests such a + discussion. +

+
+ +
+

+ Decision Policy +

+

+ This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 3.3). Typically, an + editor or other participant makes an initial proposal, which is then refined in discussion with members of the + group and other reviewers, and consensus emerges with little formal voting being required.

+

+ However, if a decision is necessary for timely progress and consensus is not achieved after careful + consideration of the range of views presented, the Chairs may call for a group vote and record a decision along + with any objections. +

+

+ To afford asynchronous decisions and organizational deliberation, any resolution (including publication + decisions) taken in a face-to-face meeting or teleconference will be considered provisional. + + A call for consensus (CfC) will be issued for all resolutions (for example, via email and/or web-based survey), + with a response period from one week to 10 working days, depending on the chair's evaluation of the group + consensus on the issue. + + If no objections are raised on the mailing list by the end of the response period, the resolution will be + considered to have consensus as a resolution of the Interest Group. +

+

+ All decisions made by the group should be considered resolved unless and until new information becomes available + or unless reopened at the discretion of the Chairs or the Director. +

+

+ This charter is written in accordance with the W3C + Process Document (Section 3.4, Votes) and includes no voting procedures beyond what the Process Document + requires. +

+
+ +
+

Patent Disclosures

+

The Interest Group provides an opportunity to + share perspectives on the topic addressed by this charter. W3C reminds + Interest Group participants of their obligation to comply with patent + disclosure obligations as set out in Section + 6 of the W3C Patent Policy. While the Interest Group does not + produce Recommendation-track documents, when Interest Group + participants review Recommendation-track specifications from Working + Groups, the patent disclosure obligations do apply. For more information about disclosure obligations for this + group, + please see the W3C + Patent Policy Implementation.

+
+ +
+

Licensing

+

This Interest Group will use the W3C Document + license for all its deliverables.

+
+ +
+

+ About this Charter +

+

+ This charter has been created according to section + 5.2 of the Process Document. In the event of a + conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take + precedence. +

+ +
+

+ Charter History +

+

Note:Display this table and update it when appropriate. Requirements for charter + extension history are documented in the Charter Guidebook (section 4).

+ +

The following table lists details of all changes from the initial charter, per the W3C Process Document (section 5.2.3):

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ Charter Period + + Start Date + + End Date + + Changes +
+ Initial Charter + + [dd monthname yyyy] + + [dd monthname yyyy] + + none +
+ Charter Extension + + [dd monthname yyyy] + + [dd monthname yyyy] + + none +
+ Rechartered + + [dd monthname yyyy] + + [dd monthname yyyy] + +

[description of change to charter, with link to new deliverable item in charter] + Note: use the class new for all new deliverables, for ease of recognition.

+
+
+
+
+ +
+ + + + + \ No newline at end of file