- From: Carine Bournez <carine@w3.org>
- Date: Mon, 20 Jun 2016 19:41:36 +0000
- To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
- Cc: Revising W3C Process Community Group <public-w3process@w3.org>
Hi Daniel, [sorry for the somewhat IPR-related arguments in this email] Splitting your message to keep your list of pain points first: > 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 > Then your proposal: > 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. I think it makes sense, but it would also require amending the patent policy so that the RF commitment and disclosure/exclusion mechanism is per-spec and not per-WG. The PP needs real simplification, but this is far from trivial. Tracking contributions from WG Members who would commit to RF for a spec and not for another is probably impossible, and definitely worse than the current situation. > 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. "Just updating the charter" in terms of changing the ETAs was(is) already possible (charter extensions), but declared not desirable a couple of years ago. The proper "rechartering" is because of the needed RF commitments for the new deliverables. That's where there's room for PP simplification, to try to fix your points 2 and 3 above. > 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. I don't think the rechartering process is very complicated for those anyway. (Except when there was "per activity" rechartering, complexity was artificially increased for the Staff, while may have simplified review from members) > We have too often in the past hid ourselves behind IPR-related > rationales to enforce the presence of such ETAs in our Charters. I I don't think it's ever been useful for IPR-related questions, actually. We could have just a list of deliverables covered by the charter and that's it. > 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. IMHO, the interesting bits of the ETA work is to set priorities between different deliverables, and evaluate estimated complexity of producing each deliverable (compared to each other). You mentioned Testing as a particularly difficult point to estimate, almost impossible to plan. I agree. However, I think it is still important that a best effort strategy is used to draw the groups timelines. Just maybe not in the charters, since they don't get updated that often. -- Carine Bournez /// W3C Europe
Received on Monday, 20 June 2016 19:41:38 UTC