AB/2017 Priorities

From W3C Wiki
< AB
Jump to: navigation, search

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 (WebCrypto)
    • Specs maintained elsewhere (HTML5)
    • Specs whose follow-on work distracts from maintenance (many?)
    • 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?
    •  ??
  • Prescriptions
    • Policies and Procedures optimized for maintenance
    • Process doc changes
    • Culture changes
    • Patent Policy changes? (hope not!)
  • Treatment Plan
    • 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
    • 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):

Charter Approval Agility

Leads: 1) Mike; 2) David

Deliverable(s):

  • Clarity on resolution of objections

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

/TR

Lead: Tantek

Deliverable(s):

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

Tooling

Lead: Léonie

Deliverable(s):

  • 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).