RE: Followup to "Supergroups" message to AC Forum

It isn't just "supergroups" that need to add deliverables at times.  I don't think the division between longstanding and smaller groups is usefull.

We discussed previously, and I think some WGs may have included in their charters, the notion of rechartering only to add or drop deliverables without extending the duration.  Given the term of the charter isn't changing, the review would be limited only to the deliverables changes.  (that was to not have everything reviewed again until the initial expiration date).  That can be done now, if the AC just agrees to not bring up other topics when the Charter is still within its existing charter period.

I don't think it works to have "permanent" groups, with broad and vague charters that don't get periodic AC review.   The Web Platform WG where it is for anything a WebApp could possibly need and where Members participating have to license every spec produced (and those could be on anything) needs to have clear deliverables so Members know what their obligations may be.  It needs a clear list of deliverables that get updated periodically under Membership review of the Charter.  So, those large groups need review as much as smaller groups with fewer specs.

>-----Original Message-----
>From: Daniel Glazman [mailto:daniel.glazman@disruptive-innovations.com]
>Sent: Monday, 20 June, 2016 06:43
>To: Revising W3C Process Community Group <public-w3process@w3.org>
>Subject: Followup to "Supergroups" message to AC Forum
>
>Hi Process CG,
>
>This is followup to the "Supergroups" message sent by Jeff [1] a while ago to
>the AC Forum. I was extremely busy with the release of BlueGriffon and
>could not comment earlier, sorry for that. But I also noted it did not attract
>a lot of comments in the list...
>
>I ignited the discussion [2] around Supergroups almost two years ago (two
>years...) with a message highlighting five recurrent issues in the WG I know
>best, of course the CSS WG. I can summarize that into the following five
>bullet points:
>
>1. difficulty to give realistic ETAs, that are still mandatory in
>   charters
>2. binding list of deliverables
>3. difficulty to add new deliverables
>4. arbitrary charter duration too often not in line with the WG's
>   intrinsics
>5. _extremely_ high cost of charter renewal
>
>I was then rather puzzled to see Jeff's summary on current work on
>Supergroups does not really seem to address any of these bullet points. I
>think that after two years, we need to speed up a bit here.
>As an example, the CSS WG is currently rechartering, again, and almost
>nothing has changed. Same cost, same endless questions, same ETA
>randomness, same time consumption, same complexity. Woof.
>
>I am then proposing to split Working Groups into two different
>categories:
>
>A. Longstanding Working Groups
>------------------------------
>
>These are Working Groups that we expect to stay for a verrrrry long time,
>like html, CSS, DOM, etc. These WGs never end work, they almost never
>change scope, they add/remove deliverables all the time and they're the
>ones highly impacted by the rechartering cost. Please note such Groups
>already deal with Deliverables in a way that is not entirely in line with the
>Process since they usually don't officially amend Charters to start a new
>work. We really need to adapt our Process to our evolving practice or our
>Process is pointless.
>For such Groups, rechartering would be a fast-track process and I really
>mean it: only an update of the deliverables section. Without Membership
>prior request or formal objection from the AC, the Charter would be
>"updated" and not "renewed".
>The idea is then to keep the same Charter, just updated, with start and end
>dates updated too.
>
>B. Single-Purpose Working Groups
>--------------------------------
>
>These are Working Groups expected to work on a well-predefined set of
>deliverables and shutdown upon completion. They're not expected to need
>an extension, although it could happen from time to time.
>Rechartering of such Groups would retain the current expensive process.
>
>--
>
>Furthermore, we still have a major issue with the list of Deliverables.
>I read many arguments about the usefulness of a list of ETAs for
>deliverables. But let's be very clear: in the cases I know, the complexity of
>the specs we're dealing with and the sometimes counter-productive
>perfectionnism of our Membership make that list of ETAs mostly unrealistic
>if not totally random. The ETA for a spec depends on too many variables,
>and variables the Consortium and even the Chairs have no control upon.
>One of the main gordian knots is the availability of a Test Suite, a time-
>consuming effort that Members don't always easily dive into. That alone
>makes ETAs too often unpredictable.
>
>We have too often in the past hid ourselves behind IPR-related rationales to
>enforce the presence of such ETAs in our Charters. I think it's time to
>acknowledge the fact the release of a Standard is not always a straight line
>and that even with the best intentions in the world, a Standard is not a
>Software project. In some cases, giving an ETA is doable and reliable; in
>others, it's not and there's almost nothing we can do against it. Please note
>this is an opinion other Members also expressed. As an example, ETAs for
>the Deliverables section of the new Charter of the CSS WG are, *again*, a
>problem and a too complex effort. It's mostly useless, sucks our time, and
>let's be serious, nobody ever looks at these dates again.
>
>I think it's highly time for a major - and urgent - revamp here. Don't
>misunderstand me: IPR-related arguments are of course perfectly fine, but if
>they lead to almost random guesstimates that nobody really cares about, we
>are only creating frustration and waste of time/energy. And I don't think we
>have time/energy to waste.
>
>Thanks.
>
>[1] https://lists.w3.org/Archives/Member/w3c-ac-

>forum/2016AprJun/0176.html
>[2] https://lists.w3.org/Archives/Public/www-archive/2013Sep/0011.html

>
></Daniel>
>

Received on Monday, 20 June 2016 20:21:47 UTC