Re: Survey: topics for W3C members to consider

Since I filled in a different version of the survey, below are my answers  
to the survey.

Broadly, I ranked things as 1 (no need to discuss), 4 (discuss if there is  
critical mass for a useful session), or 7 (should be discussed). I doubt  
that all the things I ranked as should be discussed will be, and that's OK  
- I'd rather get real progress on a few issues than check of all the  
issues as things we mentioned but did nothing useful about.

I think the comments I wrote are more useful than the numbers. I also  
divided things in my head slightly differently, althugh I don't know if my  
characterisations will help anyone else:

- Value of the AB
- value of the TAG
- When to start or stop work on what
   + These are all questions between the AC and the W3C.
- IPR issues
   + This is complex, and I think we are at a very early stage, better
     suited to email and hallway discussion. Getting the members to re-open
     the patent policy, an getting something changed, is a long-term  
exercise.
     We should be going there, but we shouldn't expect to have it resolved  
in
     November...
- Process documentation
   + What form is the documentation (Process document, chairs' guide, ...)
     is fundamentally an editorial issue, although it needs to take into
     account the various audiences
- The "Social contract"
   + W3C is an outward-looking organisation, and outsiders participate (and
     are appreciated). What are the implications of this in the way we work?
- Document lifecycle
   == this is the big one ==
   + Last call is a pain point in lots of ways.
     . Why? What purposes does it serve, and what does it not do that it
       should?
   + Referencing specifications
     . Lots of different people and groups use the specs we make. Who are
       they, what do they want, how do they find it?
   + Maintenance
     . How do we deal with long-lived specs that slowly change in reality?
   + Reviews, Resources, and tests
     . How do we get the most out of the people who have expertise to
       create tests, provide review, edit specs, but have limited time.
       This topic includes review from TAG, WAI, Security, getting
       implementation reports, and a lot more

On Thu, 22 Mar 2012 15:24:17 +0100, Charles McCathieNevile  
<chaals@opera.com> wrote:

> There is a survey[1] available for this group (thanks Coralie), which I  
> would like people to complete.
...
> [1] https://www.w3.org/2002/09/wbs/50503/CGPDconcerns/


---------------------------------
Process Implementation
----
State your opinion on need to discuss the following concerns at the May AC
Meeting. "1" means do not discuss; "7" means must discuss.


   * Importance of "Educational materials for Working Group Chairs that
might help the Process be understood better and implemented more
consistently." : [ 4 ++++ ]
   * Importance of "Aspects of the Process are inconsistently enforced.": [
1 + (lowest) ]
   * Importance of "The roles & responsibilities of identified people need
updating.": [ 4 ++++ ]

Comments (or a URI pointing to your comments):
2.1 is a no brainer - of course it should happen. If anyone is
volunteering to work on this during the meeting that's great, but otherwise
I think there isn't much point in discussion.

2.2 Understanding how different groups *use* the process in practice would
be very helpful in understanding how to interpret whether it is useful or
problematic. This aspect in particular would benefit from what chairs
(except CSS, who have published what they do in several places in
useful-to-read form) have to say. That may or may not be something we can
get at the AC meeting, but I suspect it is something that chairs could
helpfully comment on in email or responding to a survey.

As a general principle, the process should make requirements for things
that are required. Otherwise they belong in the chairs' toolkit of
'possible ways to run groups,and why you might (not) want to use them'. A
classic example is 'good standing' - it would be great to survey the chairs
on how often this (and other process pieces) are actually used.

2.3 There are administrative-level changes such as figuring out W3C chair,
CEO, etc that probably need no discussion. Within working groups there are
roles such as editor which no longer reflect the assumptions of old (that
the Working Group decides, and the editor implements). I believe this is
material for the chairs' guide, not process, but others may differ.
Certainly input from different working groups is key here.




---------------------------------
Process clarity
----
State your opinion on need to discuss the following concerns at the May AC
Meeting. "1" means do not discuss; "7" means must discuss.


   * Importance of "Going to Last Call (LC) is misleading for Candidate
Recommendation (CR) changes." : [ 4 ++++ ]
   * Importance of "Intergrating implementations into the Process.": [ 4
++++ ]

Comments (or a URI pointing to your comments):
3.1 Touches on things that are hard to change, like the Patent Policy, so
any statement of this kind needs to trigger that part of the discussion.
Since I believe the patent policy is critical to many AC reps, I think this
is a high-priority topic. Last Call is one of the very big pain points in
the current process, for all sorts of reasons.

3.2 As Dom recently wrote on the w3process community group, although we
make specifications, the reason for doing it is to produce interoperable
implementations. Currently there seem to be very different understandings
of what that means - mass-market browsers only? Authoring systems? Tools
that are used on HTML/Web Platform intranets?

Experience has shown that implementation is important (hence CR),
something that was initially taken for granted. Does there need to be more
process about this? Or is it just part of the ground we stand on?




---------------------------------
Complexity of Process Document
----
State your opinion on need to discuss the following concerns at the May AC
Meeting. "1" means do not discuss; "7" means must discuss.


   * Importance of "Heartbeat requirement not enforced or useful.": [ 7
+++++++ (highest) ]
   * Importance of "Process Document too big.": [ 1 + (lowest) ]
   * Importance of "Separate out core process from standing rules.": [ 4
++++ ]

Comments (or a URI pointing to your comments):
4.1 There are repeated issues about how to make references to W3C work,
and a problem that gives rise to these is the fact that we have highly
unstable editor's drafts, generally old recommendations, and working drafts
which are not updated in a timely manner.

4.2 I suspect this is a truism. We should acknowledge it as some to think
about whenever editing.

4.3 This could be useful to people. It is important to understand who
really uses the Process document, and how, in order to make sure it works
for its audiences.




---------------------------------
Speed of document production
----
State your opinion on need to discuss the following concerns at the May AC
Meeting. "1" means do not discuss; "7" means must discuss.


   * Importance of "Schedule delay due to process.": [ 7  +++++++ (highest)
]
   * Importance of "Issue resolution takes (too much) time.": [ 4 ++++ ]
   * Importance of "Lack of test cases is a major contributor to schedule
delay.": [ 4 ++++ ]
   * Importance of "The process may not adequately encourage tests &
testing.": [ 1 + (lowest) ]
   * Importance of "Publication rules place an (unreasonable?) barrier.": [
4 ++++ ]

Comments (or a URI pointing to your comments):
5.1 Is a meta discussion - the question is what can we do in the process
(and for that matter in our implementation of what it says) to work
effectively.

5.2 There are certain process questions, like the idea that we should
publish intermediate recommendations knowing that not all issues are
resolved, in order to stabilise the pieces that we think work well enough
to be useful (see also 6.1). But part of this is "this is hard work" - and
that is simply a fact.

5.3 This is mostly about getting the work of test development done. I
think it revolves around practice, and working - I don't see any particular
process implications.

5.4 I think the process is pretty clear on requirements for tests and
testing. The question is how to make it happen.

5.5 If there are suggestions about particular features that are
unnecessary work, we should examine them. Otherwise, this is just restating
"making good specs is hard work".




---------------------------------
Contextual/Social Framework
----
State your opinion on need to discuss the following concerns at the May AC
Meeting. "1" means do not discuss; "7" means must discuss.


   * Importance of "hat are the various audiences for documents?": [ 7
+++++++ (highest) ]
   * Importance of "Value of the Advisory Board (AB) & Technical Advisory
Group (TAG).": [ 7  +++++++ (highest) ]
   * Importance of "Desire for stable reference.": [ 7  +++++++ (highest) ]
   * Importance of "Find ways to allow experimentation.": [ 1 + (lowest) ]
   * Importance of "The social contract with contributors to
specifications.": [ 7  +++++++ (highest) ]
   * Importance of "Official drafts are disconnected from some audience
needs.": [ 7  +++++++ (highest) ]
   * Importance of "Process document does not match modern development
methodologies & tools.": [ 4 ++++ ]
   * Importance of "Do we have the right processes for starting or stopping
groups and work?": [ 7  +++++++ (highest) ]

Comments (or a URI pointing to your comments):
6.1 This is critical. There are often discussions (e.g. on
public-w3process@w3.org and elsewhere) that begin with assumptions about
the needs of a particular audience. Teasing out the different audiences
makes it clear that there are a complex set of requirements. (I think the
various specs around HTML5 such as H:TML and "Differences between HTML 4
and 5" show some interesting thought in this area).

6.2 This is an important topic for the AC, since their resources are
invested in these things. It is also important to understand the general
roles of the groups.

6.3 This is a subset of 6.1

6.4 This is critical, but it is a meta topic - we have a system for
experimentation. The question is whether it should be improved, and if so
what that means and how we do it, and that is what many other points touch
on.

6.5 This is about W3C members, working group participants, editors, as
well as audiences for specs. As such there are some important topics
covered by this theme.

6.6 This is a subset of 6.1

6.7 Whether the way W3C works is the best fit for what participants in the
ecosystem need is a basic health check. Our current Process document hasn't
changed in 7 years, although the way we typically use it has. It seems like
a meta theme for this entire discussion.

6.8 This is something that the AC should be concerned about, and the Team
in so far as it touches on why people might decide not to join or
participate but work elsewhere.




---------------------------------
Community
----
State your opinion on need to discuss the following concerns at the May AC
Meeting. "1" means do not discuss; "7" means must discuss.


   * Importance of "Can we improve input from 'horizontal' groups (WAI,
I18N, ...)": [ 7  +++++++ (highest) ]
   * Importance of "Last Call (LC) may not be as useful as intended.": [ 7
+++++++ (highest) ]
   * Importance of "What should trigger external review?": [ 7  +++++++
(highest) ]

Comments (or a URI pointing to your comments):
7.1 These reviews provide a major value proposition of W3C. But they are
costly, difficult, and often done under too much pressure to be as good as
we would like. Ways to improve this would be a very good thing.

7.2 It seems that Last Call is one of the major pain points. It is central
to the Patent Policy, but it appears that some of the assumptions that led
to the Process around it are not necessarily true.

7.3 This is important - external review is important for our quality, but
it is often expensive to do, and we should make sure we get the best
possible benefits from it.




---------------------------------
Intellectual Property Rights (IPR) considerations
----
State your opinion on need to discuss the following concerns at the May AC
Meeting. "1" means do not discuss; "7" means must discuss.


   * Importance of "Charter scope & IPR commitments.": [ 4 ++++ ]
   * Importance of "IPR 'calls for exclusion' may not be at the correct time
in the Process.": [ 4 ++++ ]
   * Importance of "Spec maintenance (including IPR commitments).": [ 6
++++++ ]

Comments (or a URI pointing to your comments):
There are some key questions here that form a background to the way we
work - and if we want to change that we need to look at the IPR policy, how
it interacts with participants' and consumers' policies in this area, and
more. It could be a very important topic for the AC in particular, since
they are the ones who often have to do the work of implementing what we
have.

8.3 Is important to the "document lifecycle" topic as well as IPR - the
former is ripe for discussion at the AC meeting, the latter may be
something we are only in the early stages of exploring and better suited to
email and hallway discussion for the moment.


-- 
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

-- 
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Friday, 23 March 2012 15:32:20 UTC