AB/2017 Priorities

From W3C Wiki
< AB
These are past priorities. For the current AB Priorities see AB/Priorities

The AB has identified (at the F2F meeting in Berlin in February 2017) the following 2017 priorities:

2017 AB Priorities

High priority

Maintenance

Leads: 1) Tantek; 2) Mike

Deliverable(s):

Approach

  • Identify classes of maintenance challenges
    • WGs that shut down
      • Web Crypto, PNG, Math, Media Fragments
    • Specs maintained elsewhere
      • HTML, Web Workers, Web Sockets
      • Web Messaging, Progress Events, Server-Sent Events, CORS, Web Notifications?
    • Specs whose follow-on work distracts from maintenance (touch events?)
    • Specs whose follow-on work stalls (SVG)
    • others?
  • Diagnoses
    • Team prioritizes new work over maintenance?
    • Maintenance is unglamorous?
    • W3C consensus culture / patent policy discourages stewardship by an individual?
    • No W3C Process path for substantive errata without a Working Group
  • Prescriptions
  • Treatment Plan
    • What's missing?
      • Monitoring system wide for spec issues
      • Switching Groups from "normal work mode" to "maintenance work mode"
    • What have we already agreed to do that hasn't been done yet?
      • Spec template has links to bug reporting mechanism and errata list
      • Specs that need not be maintained marked as obsolete
        • 100% failure of proposed obsoleted specs
          • P3P nothing done. Still looks "current".
          • PICS Recommendations[1][2][3][4] errantly marked "superseded" (prior to this discussion?) by a closed Working Group, not a spec! ("Protocol for Web Description Resources (POWDER)" which itself appears to have died 8 years ago, so add all six POWDER RECs+NOTEs to the list to Obsolete)
    • Who needs to be in the discussion, when?
      • AB, Team now
      • Chairs (sanity check procedure changes)
      • Process CG

Funding & W3C Structure (4 hosts)

Leads: Virginie; Chris

Deliverable(s):

  • Sketch of a plan for a sustainable funding operation (including Hosts)

Build a Security Review Community

Lead: Jeff

Deliverable(s):

  • Build a security review committee

Approach

  • Size the problem. How many times per year do we need security reviews?
  • Current capabilities.
    • How often can the review be a self-assessment using the self-assessment guide?
    • How many reviews per year are provided by people outside the WGs?
  • Assess how IETF and others are achieving their reviews
  • Process considerations
  • Develop approaches to building a community
    • Outreach to researchers
    • Education to our WGs
    • Financial Incentives
      • Cost to bring in experts
      • Sources of funds (including W3C budget as initial focus)

Medium priority

Security call for action

Leads: 1) chaals; 2) JudyZ

Deliverable(s):

  • A call for action at every AC/TPAC

Outcomes:

April 2017 AC

Incubation & REC Track Best Practices

Lead: Mike

Deliverable(s):

Main issues so far:

  • Some communities strongly prefer to incubate in a WG not an IG or CG
  • Pushback from those advocating incubation before Rec Track who fear that doesn't address the challenges that led to the readiness criteria in the first place

Approach

  • Identify concrete examples of successful incubation in a WG (CSS WG is probably the clearest)
  • Clearly define the historical problems of WG incubation that we are trying to avoid
  • Understand the reasons why some communities don't accept the idea of incubating in CGs
  • Seek a middle ground that mitigates both the historical problems with WG incubation and the reasons why some communities resist CG incubation

Open questions

  • How can we rigorously identify examples of success and failure?
  • Could we modify the Process to require the readiness criteria to be met before FPWD or CR?

Charter Approval Agility

Leads: 1) Mike; 2) David

Deliverable(s):

  • Principles used to determine when to sustain or over-rule objections
  • Clearer guidance on when work should be chartered in a CG, IG, or WG
  • Advice to AC reps considering a formal objection

Issues

  • Should there be a more rigorous/predictable set of criteria or is this essentially the Director's judgment call?
  • How should the Director communicate a decision on how to handle objections; should there be a formal communication, or even another formal ballot?
  • How does this question relate to the incubation question? Is meeting the Rec Track Readiness criteria necessary/sufficient to form a WG?
    • What if the criteria aren't met but there are many members supporting a WG?
    • Is meeting the criteria sufficient to form a WG even if there are objections?
  • What does "can't live with" mean? ["our membership is at risk?" "W3C as a viable entity is at risk?" ]
  • How to balance many "supports" vs a small number of objections; how to weigh "doesn't support but doesn't object" against support/object votes.

Approach to getting issues resolved

  • Seek agreement on abstract rules for handling objections [see Rawls "Theory of Justice" and Shapiro "Negotiating the Non-Negotiable"], apply
  • Analyze notable chartering controversies -- would applying the abstract rules have led to a workable decision?

IPR tracking for contributions, in the "Github age"

Leads: chaals; Léonie

Deliverable(s):

  • What do groups do today to track contribution IPR? (Limited to WG. IGs don't produce Recs, CGs are outside the process altogether)
  • Tooling:
    • what tools are available
    • how are they maintained?
    • what should be used?

Lower priority

Role of Director

Lead: David

Deliverable(s):

  • Suggest modifications to W3C's standing documents; start with Process Document
  • see the TAG Briefing Piece (AB-only) that the AB is working on, on the role of the TAG and the Director's role with respect to the TAG

/TR

Lead: Tantek

Deliverable(s):

  • By year-end, /TR represents clearly what should be implemented for the Web

Tooling

Lead: Léonie

Deliverable(s):

  • Tooling
  • Aggregate map of all tools in use.

See Also

Working Draft section

This is a workspace for the W3C Advisory Board to develop and iterate individual, collective, and consensus views on our priorities for 2017. After some discussion, we anticipate prioritizing the different inputs at our F2F meeting in Berlin in February 2017.

20170223 AB f2f prioritization on paperboard

Jeff compiled unique suggested priorities from the wiki here, and from conversations at the 2017-02-22 AB f2f (day 1) --labelled "(YEST.)/(Y)". Each proposal is complemented with concrete deliverable(s) the AB proposes.

After votes, 9 proposals crop up, ranked between (H)igh, (M)edium and (L)ow.

  • (TC) (H) 1. Maintenance & REC Track Best Practices - Leads: 1) Tantek; 2) Mike
  • (TC) (M) 2. Security - Leads: 1) chaals; 2) JudyZ
    • A call for action at every AC/TPAC
  • (TC) (H) 3. Funding (CMN) & W3C Structure (4 hosts) - Leads: Virginie; Chris
    • Sketch of a plan for a sustainable funding operation (including Hosts)
  • (TC) (L) 4. Role of Director - Lead: David
    • Suggest modifications to W3C's standing documents; start with Process Document
  • (JJ) (M) 5. Incubation & REC Track Best Practices - Lead: Mike
    • Revision of Mike's document
  • (JJ) 6. WHATWG
    • By year-end, HTML is a partnership again between W3C and WHATWG
  • (JJ) (M) 7. Charter Approval Agility - Leads: 1) Mike; 2) David
    • Clarity on resolution of objections
  • (JJ) 8. Trademarks
    • By year-end, Regularly implement the AB's direction on us of trademark
  • (JJ) 9. (L) /TR - Lead: Tantek
    • By year-end, /TR represents clearly what should be implemented for the Web
  • (CMN) 10. Global
    • (Volunteer) translations (of specs)
  • (CMN) 11. Formal Process / Informal Procedure
    • Collecting pain points via a Chair survey
  • (CMN) (L) 12. Tooling - Lead: Léonie
    • Aggregate map of all tools in use
  • (MC) 13. Strategy Function& Incubation Deep Dive
  • (YEST.) 14. Adapting to Open Source Focus
    • Roadm-ap on how W3C navigates specs vs. open source
  • (Y) 15. Member Agreement
  • (Y) (M) 16. IPR/GitHub - Leads: chaals; Léonie
    • Define contribution
    • Tooling: what should be used?
  • (Y) 17. Privacy
  • (JJ) 18. Adding Value
    • Identify 1 spec that should be brought to W3C
  • (JJ) (H) 19. Build a Security Review Committee - Lead: Jeff
    • Build a security review committee

Initial Thoughts and Input

At this stage it is useful to list proposed topics as well as specific targets for what the AB can do for these topics.

Tantek

From 2017-01-09 (AB only link)

If I were to cherry pick from AB#Priorities_2016, for 2017:

1. Maintenance and Best Practices for REC track (which I see as two ends of the same funnel)

With process 2016 completed, we have made great progress on this IMO. OTOH there is still much (productive) work to be done, as evidenced by:

a. The continued (healthy) debates of incubation and differences of (potential) member influence (e.g. Verifiable Claims discussions)

b. Mixed results with REC publishing from 2016. On the good side, nearly all 2016 RECs look like "practical" additions to the Web Platform (in contrast to previous years, per the analysis I informally gave at the 2016 Dec f2f), with the exception of WebIDL, which was essentially obsolete when published (and we should call for it to be officially obsoleted immediately, since its announcement itself recommends not implementing it).

Chaals: +1 (note Cwilso also suggests this). In particular, actually obsoleting some specs: P3P, CC/PP, PICS, POWDER, old versions of HTML, all seem reasonable candidates to suggest.

Some work could profitably be done on refactoring the TR page - I'm not sure the AB is ideal for this, but it needs to be done. IMHO collecting translations is also an important aspect of curating W3C's specifications, and I am concerned about how this happens.

2. Security. In the past year, security problems related to the just w3c, or web (e.g. phishing) and the internet as a whole (IoT) have reached a new (bad) level of severity and impact on the w3c / web / internet / countries elections / etc.

I considered recommending this first, but I'm not sure we can be as productive with it as 1, so this is 2. Anyway, I think the situation with online security has gotten so bad that it behooves us to do whatever we can at the w3c / web level to improve it. I see this as a responsibility for w3c to bear as part of leading the web to its full potential (it is being held back by security problems).

Chaals: this is important, but it is pretty unclear that the AB is qualified, let alone the appropriate group to work on it. For that reason, -1.

3. Funding. (any/all sources of funding/models for W3C, lots to work on here too, see other thread).

Chaals: +1


4. Role of the Director. This continues to be important to the future of the W3C, and something really only the AB (in coordination with W3T) can work on, so we should.

Chaals: +1

Jeff Jaffe

2017-01-09

1. Incubation and starting new specs in W3C. Last year we produced a document called Best Practices for Rec Track (link?). This was a very helpful document and the Team has found it helpful to guide the community on how to get things started in W3C in a way that will lead to success.

While last year's document was a good start, the community is bubbling with ideas on how to make the document better. Manu Sporny provided a thoughtful blog post entitled Rebalancing how the Web is built. There are have been numerous email threads about the readiness of Verifiable Claims (link?). There was a rich debate about where CSS should do incubation. There is a new debate starting on how to define incubation. The AB needs to bring the various W3C stakeholders together and achieve a consensus on these topics.

2. Relationship between W3C and WHATWG. The W3C and WHATWG have had an uneasy partnership for years. The web is better off if we are working together rather than working at cross purposes. This is the area where the Team most needs the advice of the AB, because it has been a thorny problem. The AB, whose members are often from the same companies as WHATWG participants are therefore best positioned to give advice on how to improve this situation.

In recent discussions with the AB (December F2F, and 9 January call), the AB has counseled that this should not be a major focus. I raise it nonetheless: if the role of the AB is to advise on areas where the Team needs help - this is the area we need advice. Of course, if the consensus of the AB is not to focus on it, I will abide by the consensus.

3. Agility of charter approvals. There has been an increase in formal objections to Charters. Certainly there are many reasons for this. This project is to study the recent history so that we can improve the situation going forward and add to the agility of charter approval.

Chaals: This seems to be part of your issue 1, and I hope it is considered in that way.

4. Trademark. In late December, the AB agreed to increase usage of the W3C prefix for specs to improve our leverage of our trademark. The Team has the task to advice the next level of details on this topic. The Team can use continued AB review and advice.

Chaals: I think this is largely an inappropriate approach to the problems it is suggested to solve, and we should stop spending time on it.

5. /TR. Under the AB's guidance, the Team has taken an action to revamp /TR. The Team can use continued AB review and advice.

Chaals: See above comments on Tantek's issue 1.

Chris

Chaals: These duplicate things above.

1. Funding and W3C Structure. How the W3C acquires funds, how the Host structure uses those funds, and what contracts the W3C accepts.

[JJ] This should include AB Action 159 [1], as well as some creative thinking about new sources of funds.

[1] https://www.w3.org/Member/Board/track/actions/159

2. Maintenance and Best Practices for REC track, and incubation on the front end. In short, continuing to refine the Process.

3. Role of the Director. This continues to be important to the future of the W3C, and something really only the AB (in coordination with W3T) can work on, so we should.


Chaals

1. Being more Global

We're still bad at understanding, and working with, the world outside North America and Western Europe, and very bad at it for a large number of regions. We have made significant progress, but there is a lot more to do.

2. Formal Process, informal procedures

The Process document is still over-complicated and should be simplified and clarified. Again, this is ongoing work. At the same time, it is not clear that our practice actually matches what we say, and we should ensure that what we do is relevant and what we say we do.

In particular this includes the role of the Director, the function of the TAG and AB, and making the AC as efficient as possible from each side's perspective.

3. Curating our work

This is largely the "TR" and "incubation" questions mentioned above.

4. Tooling

How we decide to adopt and update tools. What happened to the Loomio experiment? Where is Unitas? What tools do we actually have deployed, which of them work, which of them are sustainably maintained, and what important tasks are we unable to do beyond list translations of specifications? Who has serious problems using the tools we currently rely on?

Mike

For the last couple of years, I wanted the AB to focus on making W3C work better: Incubate specs until there is viable community that is behind a draft before starting a WG; make WGs work better so they get to Rec (or admit failure and shut down) quickly and efficiently, and maintain Recs after they are published. As Jeff notes, we've made good progress on the first, but there are challenges we need to address. The second one seems to be in Philippe's capable hands since the re-org and I think the AB can watch and learn from how the Project Management function works for the next year. Maintenance remains a challenge. So my priorities are:

1. Strategy and Incubation

  • Is the Strategy team up and running well? Do they apply the rec track readiness criteria (RTRC ) and work give constructive guidance on how to improve them?
  • Does W3M and the Strategy team take the time to assess the existing standards landscape, and how W3C could fill gaps, before proposing new work?
  • What is “incubation” in the W3C context? Can we come up with a useful metaphor to explain it better than we have?
  • Can incubation happen in WGs as well as CGs? (the answer probably has to be “yes” since the CSS and AG WGs are balking at doing their incubation work in a CG). If so, does anything have to change in the process document to make incubation in WGs work better?
  • Can/Should we make the RTRC more rigorous, by more operationally defining the criteria and clarifying whether some combination of the criteria are necessary or sufficient?
  • Would applying these criteria unfairly change the balance among web platform implementers, web site/app developers, independent experts, technology advocates, and theorists that W3C has fostered over its history?

2. Maintenance - Refining the Process and team policies to ensure that that the specs with broad consensus and patent commitments have their bugs fixed and ambiguities clarified

  • Is the Team applying the AB's previous guidance (e.g., updating spec boilerplate to point to a bug reporting mechanism)?
  • Does the formal process and patent policy get in the way? If so, what can we do to mitigate that?
  • Culture: Why do Recommendations tend not to be maintained as well as WHATWG living standards are? Is there something we can do to foster a culture of ownership/stewardship within W3C's constraints?

3. Role of the Director - Is W3C willing to fade to black when TimBL rides off into the sunset one way or another? If not, we need to wrestle with some questions:

  • Could an actual human being who did not invent the Web credibly do what Tim does? (Not the 95% of the "Director" duties delegated to the team, the 5% or whatever that requires his personal attention).
  • Is it worthwhile to revise the Process Doc and Member Agreement to clarify who really does the 95% of the "Director" duties that are delegated?
  • Could W3M handle 100% of the Director duties when the time comes?
  • Could the AB and TAG evolve to be the authoritative deciders of governance and technical issues? (The current TAG clearly does not want to, based on discussion at their recent F2F)
  • Should we invent some other entity, e.g. an actual Board of Directors, that would decide matters on which no consensus seems possible? If so, who would choose it, and how would it operate?

4. Various hard problems that the AB probably can't solve

  • Security (I agree with Chaals that the AB doesn't really have the ability to address this, but don't object to discussing it)
  • Funding (Until there's some sort of Board with real power and access to the information W3M doen't share with the AB, I'm not sure it's worth a lot of our time)
  • Relationship with WHATWG. Jeff notes "the AB has counseled that this should not be a major focus. I raise it nonetheless: if the role of the AB is to advise on areas where the Team needs help - this is the area we need advice. " So it's worth some AB time considering what the Team should do, but not make a major investment. FWIW, I advise a) learning from what WHATWG does well (such as maintenance); b) don't get into "turf wars" but accept that work gravitates toward venues where there is a critical mass of expertise; c) focus on making W3C a more desirable venue for communities of experts that might be tempted to gravitate toward WHATWG (even if that gets resistance from other W3C stakeholders).

David

  1. Maintenance. I think PLH and I are on similar lines here. I like to look at it as a workflow and ask what our best practice is at each stage.
    1. Ingest: do we make it easy to report bugs on our documents, and to see what bugs have been reported and the resulting discussion and resolution? No, for a reasonable number of documents. Some have links to actively maintained errata pages (but getting an erratum on there is manual). Some link to mailing lists (bad). Some documents have no links at all (see DNT the last time I looked). Some have links to GitHub Issues and a link to report a new issue (good). Proposal: revise the template and *insist* that anything post CR has the two links (a) report a bug and (b) see bugs reported and their discussion. Note that you can automate this using GitHub, BugZilla, or whatever tool the WG likes.
    2. Finding them ourselves. If we don't have test suites, we might not find ambiguities; at least the test author would have an idea what the 'right' answer is and some implementations fail. We gotta do betta.
    3. Disposition. We've had a hard-nosed attitude that 'inactive' WGs should be closed, but I think we mis-defined inactive as not doing much. Inactive means, I think, not doing what you are supposed to be doing. I see no problem with chartering a WG, keeping its membership, to do 'maintenance' -- discussing bugs, proposing resolutions, maintaining an WG WD, and periodically pushing it out. It doesn't even need a termination date. The editor can be 'strong', authorized to push a new WG WD after a notice ("I'll push a WD from this ED next Friday unless anyone objects") and so on.
  2. Funding and W3C structure. I see these as two (at least) separate questions.
    1. How is 'external' funding handled? There is a simplistic view that externally funded folks should be shown as representing the funded body, not as team (e.g. MIT), but of course some contracts fund 1/4 of a person.
    2. Host structure. I am concerned that the overhead cost of some hosts may be high, and I think that we somehow have to make the W3C more manageable. Ideally, we make the CEO more powerful. Less ideally, if the CEO is actually only the senior Director 'among equals', perhaps at the AC meeting we need regional meetings hosted by the regional directors, so that at least AC Reps know who is formally managing the money they contribute? I look forward to getting more data here.
  3. Charter approval agility.
    1. I doubt that abstract and formal rules are going to help here except with the most obvious of cases. For example, if responding to objections changes, in any way, the deliverables list or the characterization of deliverables, that might imply an IPR change, and that suggests we may need to re-ballot.
    2. However, on agility, I wonder if we can use the 'if anyone asks' technique more? That is, we send a notice to the AC "The FruitAPI WG Charter has changed as a result of charter review, and there is a new deliverable, GrapeFruit Sling 1.0. We will re-ballot this as a formal AC Charter review if requested by any AC rep in the two weeks following this email." This has the advantage that if no-one asks, we go ahead; the disadvantage, that as soon as anyone does ask (we don't need to wait the full 2 weeks) we might have added up to 2 weeks to the charter re-approval delay.
    3. In terms of writing good charters, we could do with a template update, clearer terms, and clearer guidance. Which dates are required, and which optional or can be estimated (and will be seen as such)? And so on. I think that revising the template may be a good way to go.
    4. In terms of writing a charter, surely Rec-track readiness is the place to look for guidelines on "are we ready for a WG?"? And these are guidelines: if you keep answering questions the wrong way ("no, we don't have a working prototype"), then your chances of acceptance go down and down. Maybe the AC needs an informative "readiness report" (sort of like the congressional budget office).
    5. We need to emphasize that FOs need to say (a) something new, that has not been previously litigated and (b) contain a proposed fix.
  4. Role of the Director. More soon...
  5. Being more global. We have tried this so many times, but as Chaals says, we could and should do so much better. Random ideas:
    1. the concern and complaints and suggestions from the non-western/non-english -- what do they say?
    2. conference calls are a dreadful way to run a global community; as we know from the AB, it's terribly hard to schedule them. They're also tricky for accessibility.
    3. it's great that the various communities have their own chat tools (wechat, etc.) but these are islands and we're supposed to be building bridges.
    4. have we focused too much on linguistic concerns and not nearly enough on cultural? For example, in some cultures, only important people are expected to speak in large gatherings.
  6. WhatWG. I don't think there is much to do from our side except try to modernize and make it irrelevant or un-necessary.
  7. Tooling. We have *got* to do more to modernize tooling. Old tools (the bots) are limping with the loss of Zakim. Webex integration is poor. Where are the dashboard? What happened to the experimental tools we had? We lost the ability to list externally-made translations recently; it really feels as though we are going backwards. The one thing I would expect a funded organization to have is good infrastructure.

Judy Zhu

1. Maintenance

Prescription:

  • Decide the location of maintenance work, in a CG, IG or WG?

2. Funding

Approach: As a starting point, we can do the following:

  • Analyze the current condition of funding including the cost of hosts, comparison (info provided by W3M). If it includes sensitive info, we can start with comparison.
  • Explore cost reduction solution.
  • Explore new funding source.

3. Build a Security Review Community

Issue:

  • Security is increasingly important in Web. Currently the security work within W3C is sort of scattered and lack of enough consideration. Therefore, a security review community is needed.

Approach:

  • We can utilize groups (Web Security IG, Privacy IG, etc.) which now are doing some security review work. How to make better use of their resources?
  • Clearly define the role and rights of Security Review Community. Should we define it as a mandatory step in process, or the security review comments can be ignored?

4. Security call for action

Approach:

  • Arrange security topics In AC/TPAC meeting, and outreach experts to share security related cases and issues, discussing security trends, new security technologies, new standard potential topics, etc.
  • When arrange TPAC sessions, give priorities to security related sessions.
  • Arrange some workshops (financial security, IoT security, blockchain security, etc.) in TPAC, as well as joint meetings between security group (Web security, Privacy, Web APP security, etc.) and other WGs/IGs.
  • Recommend WG to start security considerations and security reviews as early as possible. Define Security review as a mandatory step in process?

5. Incubation

Issue:

  • In terms of preference to incubate in a WG not CG, maybe it is because of the informality and lack of W3C staff support, and uncertainties of transforming to WG/IG?

Approach:

  • Define the principle and scope of incubation in CG, IG and WG, that is, what should be incubated in a CG, and what should be incubated in an IG/WG.
  • Absorb some ideas from Manu’s inputs.

6. Charter approval agility

Approach:

  • Need to discuss and find out best practices to resolve objections, e.g. email discussion, AB coordination, W3C team coordination?
  • Need to find better way to let members submit and resolve objections. Currently it involves many tools (email, Github, WiKi, WBS, etc.), scattered and easy to be omitted. Recommend to use one unified tool, including functionalities like comments recording, assignment, notification, etc.

7. IPR/GitHub

Approach:

  • How to set access rights, e.g. only members can join GitHub;
  • How to judge if an account belongs to W3C member employees?
  • For the technical discussions, should it go to GitHub or email discussions?

8. TR (Technical Report)

Approach:

  • Define a best practice to indicate that, before a recommendation is published, the editors /authors need to specify the implementation status of the spec.

9. Tooling.

Approach:

  • List all the tools in use, including use cases and usage frequency;
  • Investigate the drawbacks and issues for each tool, and find out solutions, e.g. update or replace, or new tools.
Retrieved from "https://www.w3.org/wiki/index.php?title=AB/2017_Priorities&oldid=115974"