<trackbot> Date: 29 October 2014

<scribe> meeting: W3C Process 2015 - What is new; What should be new

<scribe> scribe: timeless

SteveZ: this is the session on updating the w3c process
... Steve Zilles, Chair of the Process Document Task Force
... we normally operate in email public-w3process@w3.org
... we have a tracker
... all is available in the Revising the W3 Process CG web page
... I have slides

[ Slide: Process 2015 and 2016 Status ]

SteveZ: what we're doing, and to gather concerns / comments about the process

[ Slide: Status ]

SteveZ: the AB who owns the Process
... said in June
... that we want to work in the open
... in the Process CG
... we put out Process 2014 which is largely an update to Chapter 7
... - how a WG proceeds on a document to NOTE / REC
... that got approved
... in the process of doing that, we left out structural changes that we knew we wanted to make
... the structural changes mixing w/ the content changes
... seemed like it would cause more confusion than it would help
... so we split that into 2015 for the structural bits
... and 2016 for the more substantive bits
... Structural was designed to be non-substantive, but we discovered it isn't always like that

[ Slide: Overall Plan ]

[ Slide: Process 2015 Status ]

SteveZ: we have a draft that removed section 5 (Activities)
... Activities were originally created with the idea that the AC would approve the Activity
... and the Activity would create WGs in that context
... but the AC didn't like that
... the Activity became mostly redundant because WGs needed to have the information
... there were 2 exceptions
... one was creating an Activity relating to IP concerns

issue-121?

<trackbot> issue-121 -- Intellectual property information.in charters -- pending review

<trackbot> http://www.w3.org/community/w3process/track/issues/121

SteveZ: we've transferred that requirement to Chapter 6
... the second thing was
... at every AC meeting (twice a year)
... there was to be an update on Activities

issue-115?

<trackbot> issue-115 -- Revising the Activity Statement for each Activity every 6 months -- pending review

<trackbot> http://www.w3.org/community/w3process/track/issues/115

SteveZ: that was changed to be an update on groups, identifying closure of groups
... etc.
... to keep AC aware of what's going on
... with those two changes, we've removed Chapter 5
... we've also removed 6.2.1.7 Good Standing
... that concept was based on the idea that groups would have a lot of votes
... and the idea was to only allow people who regularly attend meetings to vote
... but over time, WGs generally worked on consensus
... taking straw votes
... Good Standing probably hasn't been used for 5 or even more years
... dropping this simplifies the Process, and simplifies the chair's jobs
... it was observed that if a group wanted to establish such a rule, they could always do it, by putting it in their Charter
... and AC would approve/not
... lastly, removing 6.2.7 Heartbeat
... there's a more reasonable requirement in Chapter 7
... in Chapter 7
... 7.3.2 Revising Public Working Drafts
... it's saying that if something is being mothballed
... "no further work is being done"
... the Team has the obligation to do that if the WG isn't standing
... it's been observed that there are a significant number of documents on /TR/ that are incomplete
... with no expectation that they will progress

[ Slide: Process 2015 Status - continued ]

SteveZ: direct-chairman to chairman contact
... should a collection of WGs want to create a coordination-Group
... there's already enough flexibility to do it
... process is simpler if you don't call out these things

<scribe> ... new groups aren't typically creating coordination-Groups

UNKNOWN_SPEAKER: yesterday morning in the Chair's breakfast
... there was a discussion for a mechanism for identifying when issues arise
... on what other things are doing
... a suggestion was a Twitter channel
... we've been criticized that a lot of things on /TR/ are way too static
... out of date wrt general knowledge about a spec
... the idea is not to go to continuous specifications
... but make /TR/ more reflective in the actual state of things
... one proposal is that Errata be updated no less frequently than Quarterly
... it also says that Errata is specified to be on a separate page
... and it's been pointed out by editors and users, that this isn't an effective way to go
... I can show you an out of date example of what i was trying to do
... here I have a document w/ a proposal
... and in this version, I was going to mark a section w/ Errata in yellow

[ errata-markup-2.html ]

SteveZ: it's been suggested that a more effective way to go
... was to print the replacement text w/ a warning that it's a replacement

<nigel> nigel: +1

richard: that's interesting, but when I print the document for review
... you won't get the interactivity

SteveZ: you'd get the background

chaals: people print in black-and-white
... I have an alternative, that you use an Editor's Draft
... and the ED's will have Errata marked out/folded in
... that seems easier
... all around
... I think the practice is becoming that the EDs are referred from all docs all the time
... it used to be that no /TR/ spec mentioned ED
... you could point to Errata by pointing to the ED

florian: having RECs point to the scratch place
... looks imbalanced

nigel: chaals 's suggestion sounds pretty identical to "Living Standard"

chaals: "I think Living Standards are an Oxymoron"
... [ censored ]
... standards are living in a sense, they change over time
... i believe it's important to have a stable referenced thing

<nigel> nigel: +1

chaals: i work with people who have that as a requirement all the time
... nothing wrong w/ having "here is the draft"
... you have 4 errata, you'll have an ED with a note about that
... if you have 60, you should have someone working on the draft

richard: I can see chaals 's logic
... and have people mostly looking at ED
... concerns
... you'd have to mark Errata in ED as being Errata
... so people would know that there's been a change, a serious change relative to /TR/
... people would look at the /TR/ without thinking there are Errata called out in the ED
... it would be important to call out existence of Errata in /TR/ so people know to look out for ED

SteveZ: worth looking into, but not necessary to solve today
... it doesn't have to be done the same way in every group

burn: if we allow for different ways, that's fine
... once we begin to mandate, I and others will have strong opinions

nigel: to previous slide
... you mentioned "should be updated not less frequently than quarterly"
... it took me time to figure out what it meant
... there might be nothing wrong in a spec

SteveZ: you need to at least have considered the comments that come in
... if there's nothing wrong, then it is up-to-date

florian: do you need to put in "nothing has changed"?

SteveZ: no
... just that
... it's aimed to not be a burden, but to get people to have a mental shift
... updating documents with Errata is part of what you do

richard: i understand the requirement to be that you update the Errata where they happen to be
... not in /TR/
... but real Errata are things that aren't stated correctly in /TR/
... but shouldn't there be a requirement not that we update the Errata, but that we insert into /TR/

SteveZ: my example uses green color with CSS and using <ins>

chaals: Process 2016; there's a fairly serious shift we need to make,
... about versioning specs
... the process assumes "you write a spec, and go away, and disappear"
... and yet errata will be magically updated, even though you disappeared
... nothing happens like that
... in reality, we make specs, and keep evolving them until the specs are obsolete
... the Process and the Patent Policy are really unclear
... and dealing with that will make it clearer how we update things on /TR/
... if you go beyond typographical errors
... at any level, you start running into the IPR policy
... Patents turn on "well we said you have a region"
... of course we meant a square region
... you say square region, and there's a patent on it being square/not being square
... seemingly obvious and trivial changes need to be approached with a great deal of care

richard: wouldn't that apply even if you put an Errata in a different place?

chaals: for the people who really care about the patent stuff
... you don't want to confuse them
... ultimately Errata need to be addressed

SteveZ: to make Errata normative, you need to do an AC to trigger the Patent review

chaals: i'm hoping in Process 2016
... and i'm skeptical about Process 2015
... that (in 2016), there will be significant changes

burn: on previous slide

[ Process 2015 Status - continued ]

burn: there's now a heartbeat requirement for RECs?
... or advice to working groups
... or advice to working groups
... that no Errata approved by the group should remain unreflected in the document for > 3 months

s//... or advice to working groups/

SteveZ: it's not you must publish

<nigel> nigel: +1 to not leaving errata unreflected for too long

SteveZ: it's you must consider

burn: we have only 2 people in our WG
... we have others who are members, but don't participate
... I don't want to touch a document
... it's pretty much done
... clarifications often turn out to be not clarifications in everyone's minds
... but actual changes
... with a specification that is actually done
... it's fine the way it is

SteveZ: the SHOULD is appropriate here
... you "can not do it if you have a good reason"
... you cited a good reason
... it's trying to emphasize thinking about it

chaals: another change is "clarifying what a decision is"
... there's lots of verbage about consensus, how you get there, etc.
... a lot of it is [ censored ]
... my current thinking is to rewrite it
... saying "your goal is to achieve consensus, unless you have administrative decision that 'we just need a decision'"
... there should be a clear "when a chair publishes a statement that we've made a decision"
... there's "when does a group publish", a group makes a decision, what does that mean
... and it isn't clear what does a person do to object
... that's kind of up in the air
... i'd like to take that chapter and crunch it into two paragaphs

nigel: to me, the simplest way is to require that charters state a decision policy

chaals: charters could state that
... but i'd like a flexible model, but clear enough, that you walk into a WG and understand how decisions will be made
... i'm not sure where the boundary is
... but it's important that an AC Member understands that a WG decision means "consensus", or "vote", or "arbitrary decision"
... and the Charter could say that
... i don't know

florian: in CSS,
... we had some attrition on decisions

dbaron: the thing that worries me about Decisions, more than the formality
... is the informal aspects of how we make them
... i'm not sure how Process can help
... in CSS, we've had cases where
... there's a desire to reach Consensus
... but there's no desire to make sure that people have thought about the issue

florian: that's what Good Standing was for

dbaron: there was an example Monday morning in CSS
... the editors weren't present
... and then the editors showed up
... and asked what happened
... I want us to find a way to actually make good decisions

burn: decision making
... one thing I found very confusing
... when I started working in W3C
... was the lack of a clear decision making process
... one of the things I now like about W3C
... is that the Group decides how to make decisions
... with a good Chair
... it allows you to adjust for Cultural issues
... it comes down to a Chair making a decision
... I like decisions by attrition
... when some people say "oh, i don't care"
... sometimes that's how decisions have to be made
... you have to guard against key-stakeholders not being present
... if that's happening

timeless: I have a problem as a scribe
... where i've scribed the same problem
... year on year
... i wish people would have read
... it's related to Good Standing

nigel: we just write "what to do"
... we don't explain "why we decided to do it"
... i don't have a proposal to do that
... but recording the reasoning behind a particular thing
... it's helpful for the reader
... and helpful to the people updating
... and it's helpful to the scribing

dbaron: Decisions by attrition often being good
... i'm a little skeptical about that
... decisions by attrition are part of the reason most of the browser vendors aren't participating in the HTML WG
... the browser vendors were attrittioned out

<Zakim> chaals, you wanted to note "rationale" in a decision is useful, and listing the decisions is a good practice, so you can refer there. Institutional memory and all that.

burn: i didn't say all

SteveZ: he made the point that key stakeholders

chaals: institutional memory makes WGs able to work better than coming along and work better
... sometimes you might want to come along 4 years ago and change a decision
... there needs to be flexibility for a group to figure out when a group wants to toss stuff around
... and a way to ask "is there a decision"
... decision might be "we do not have a position one way or the other"
... but it's unhelpful to know "what a decision is"
... and there's no way to argue
... we don't always have good chairs
... and don't always have good WG function

[ Process 2015 Status ]

richard: we're not talking about Activities going away

SteveZ: "Activities" as a Process step, they go away
... no step presented to AC
... Team is left with option of creating mechanisms to help present the work of the consortium
... to deal with substantive issues
... i'm beginning to think Decision Process is substantive, probably not in 2015
... goal is to get stable version of 2015 and begin reviewing/prioritizing issues in 2016
... issues are in tracker
... group edited documents ok?

issue-138?

<trackbot> issue-138 -- Does the process assume ‘an’ editor, or is group-editing formally ok? -- open

<trackbot> http://www.w3.org/community/w3process/track/issues/138

<chaals1> [Yes, anyone or everyone in the WG can be appointed editor]

SteveZ: earlier discussion about ED/WG Draft

<scribe> ... new technologies since when this Process was originally written

UNKNOWN_SPEAKER: need to grow the process

richard: would you have no editor named in the field?

SteveZ: correct
... you have groups like that
... another in thing i didn't mention

<Josh_Soref> W3 Process Tracker

SteveZ: another thing is role of Team
... a random set of privileges are listed under Director
... the rest are scattered in the document
... so in good style, we'll probably remove the director list and leave things where they apply in the document

[ Schedule ]

SteveZ: goal to have a draft of Process 2015 reviewed in Feb/Mar at AB Meeting
... document for AC Review in April
... to be open at May AC Meeting in ...

dbaron: Paris

SteveZ: last year we had another session so people could input comments

<dbaron> May 5-7, Paris

SteveZ: have AC Review close and results announce in May/June timeframe

[ Questions ]

<Zakim> joanie, you wanted to ask how and where she can participate in the discussion of ways to address issues of history and rationale for spec items

joanie: "is the answer in the minutes", "is the answer in the ML"
... i don't have a lot of cycles, but I have ideas
... i'm raising my hand to volunteer on that problem

SteveZ: Process ML public-w3process@w3.org
... a good place where discussions go on
... unless someone suggests a better place
... the issue of the topic, of what is a decision, and how is it recorded
... is relevant to that ML
... we try to identify emails
... I'll check to make sure there's an issue
... and try to make sure emails identify the issue

<Zakim> nigel, you wanted to raise issue of "evidence of implementation" and to raise issue of "do CRs have to have exit criteria?"

nigel: you mentioned to offer a chance to raise issues
... how clear is the section on "evidence of implementation"
... to exit CR, you have to demonstrate implementation
... we had an argument between editor and chair
... i'm on the side that we have to write down
... and staff backs us up
... that could be clarified

SteveZ: you have to file a report to get out of PR

nigel: do you have to be up front what your criteria are?

SteveZ: you have to write it down

nigel: it's ambiguous
... there's one document at PR without exit criteria

SteveZ: i accept the point
... much like wide-review, we may need clarification in implementation consideration

nigel: on wide-review
... there's a set of questions from the Director might ask
... but there's no indication about what the expected answer is

SteveZ: the intent was to be unclear

nigel: it was successful

SteveZ: we felt that we didn't want people to checklist things
... we were trying to convey the things to think about
... they don't need to say yes to everything
... but to build a body of evidence
... we didn't say you have to do all of them
... you might say how many do i have to do

nigel: yeah
... in that section, it would be really helpful to state the wider goal

burn: the rationale for that decision being vague should be embedded
... citing the earlier discussion

SteveZ: plugging the next session on Wide Review
... it's break time

richard: thanks SteveZ

SteveZ: thank you everyone, i appreciate the comments
... and thanks to timeless for scribing

[ Adjourned ]

<nigel> ACTION: SteveZ Open an issue to add liaisons to what's considered in the Wide Review paragraph 7.2.3.1 [recorded in http://www.w3.org/2014/10/29-w3process-minutes.html#action01]

<trackbot> Created ACTION-37 - Open an issue to add liaisons to what's considered in the wide review paragraph 7.2.3.1 [on Steve Zilles - due 2014-11-05].

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/szilles/SteveZ/
Succeeded: s/simpler/structural/
Succeeded: s/7.2.1/7.3.2 Revising Public Working Drafts/
Succeeded: s/joanie: can you get the people to your right to present+//
WARNING: Bad s/// command: s//... or advice to working groups/
Succeeded: s/pubhs/publish/
Succeeded: s/9 AC/AC/
Succeeded: s/us/is/
Succeeded: s/rrsagent, generate minute//
Found Scribe: timeless
Inferring ScribeNick: timeless

WARNING: No "Topic:" lines found.

Present: David_Baron Steve_Faulkner Josh_Soref Steve_Zilles Jingwang_Oi Joanmarie_Diggs Daniel_Burnett Richard_Ishida Chaals_Nevile Shiwoo_Kang Yoo_Jiwoong Florian_Vioal Jacob_Goldstein nigel
Found Date: 29 Oct 2014
Guessing minutes URL: http://www.w3.org/2014/10/29-w3process-minutes.html
People with action items: an issue open stevez

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report