- From: Kai Scheppe <k.scheppe@t-online.de>
- Date: Thu, 30 Apr 2015 14:54:58 +0200
- To: chaals@yandex-team.ru, Jeff Jaffe <jeff@w3.org>, Arthur Barstow <art.barstow@gmail.com>, "public-w3process@w3.org" <public-w3process@w3.org>
- CC: Coralie Mercier <coralie@w3.org>
On 29.04.2015 21:04, chaals@yandex-team.ru wrote: > >> Everybody's gut reaction is to create a process or use a tool of some >> sort, in the hope that this will change human nature. >> It will not. >> First you need the culture, then the process or tool to support it. > True. Including the fact that we do need a process to support what we > do - there is too much work spread over too many people for us to > somehow hope that everyone already talked to everyone. We can see even > within HTML that this idea (which is wired into WHATWG) doesn't really > work. Precicely, which is why there must be focus on the most important things first. It preserves resources, helps keep the overview and ensures faster delivery. >> I think what is missing at W3C is a slightly different outlook and >> hands on people work. >> More agility, less waterfall. >> >> Suggestions for a solution: >> - deliver quicker results by focusing on the most important things >> first and do that well > Agreeing what those are, and what "do them well" means is actually > quite difficult. If we agree that the "horizontal review" that W3C > provides - accessibility, internationalisation, hopefully improving > security review, etc, is a value, then we could operationally define > "do it well" as "have the horizontal review folks and implementors > happy so far…" I think agreement can be fostered by creating a vision, a goal. Usually this is done by a product owner. In this case it can be the WG. Very often I think the problem is clear, but the solution, in terms of what needs to work and how, is not. If this "user story", or better "epic", is created it might help to determine what the important points are. To be sure, the way to the solution still has to be discovered, but it should be obvious which behavior or functionality is desired in the final product. >> - embrace incompleteness in specs and allow for practical usage to >> show where the journey needs to go (Kaizen is the model here) >> - use short intervals to publish new iterations, which should consist >> mostly of addendums and few corrections >> - chairs need to lead much more strongly and, for example, drop >> issues if work is not being done or debated endlessly, because >> obviously it is not important enough to obtain a result > These three things seem really key to me. W3C can produce simple specs > fast, or at least as fast as it can deal with the horizontal review > questions, and get them implemented. But too often there is a sense > that everything has to go into version 1 - sometimes because there is > a lack of trust that problems shunted to a version 2 will be dealt > with in the real world, sometimes for other reasons. > A culture that aimed to produce versions of specs, somewhere between > the original W3C model of "make a spec and then stop" which is an > assumption somewhat baked into the process and patent policy, and the > "what's the spec today" approach of the "living standard" proponents, > would represent a real improvement. +1 > Stability matters - for people who are trying to build a business that > needs to make contracts based on a known goal, among others. But > evolution of technology is also an important reality, and holding > specs back artificially to enable easier harmonisation is just a > recipe for being left behind by that evolution. I don't think specs are held back artificially. They are merely not allowed to come into a usable state by attempt to solve all problems at once. What I propose is a focus on expanding a spec with each increment and avoid making changes as much as possible. That will create the necessary stability. > >> - create a much stronger focus for groups, by providing the role of >> moderator who has no technical stake in a specification, but solely >> works with the participants to keep them focused > That's what a good chair (or chairing team) does. I've had enough > discussions with enough different people over the last few years to > think that there is a real problem here and we are not doing a good > job of recognising it, let alone fixing it. > Chairing a group at W3C should be an honour people strive to be good > enough to earn, and be based on chairing ability, rather than > belonging to the right industry sector, technical ability in the > particular field which is as often a distraction from chairing as it > is a help, or the like. But to get there from here we have to take a > pretty robust approach to assessing, educating and as needed replacing > our chairs. Perhaps. I think the technical abilities of a chair are key. But it is too much to ask that this technical expert can also function just as expertly as a moderator. I was proposing introducing moderators in parallel to a chair. The skill set to do so is quickly developed and can be self taught. Sure, professional moderators would be great, but that is out of scope. But primarily it is the freedom to observe and act on group dynamics without the burden of chairing as well, that will help drive results. -- Kai
Received on Thursday, 30 April 2015 12:55:25 UTC