- From: Koji Ishii <kojiishi@gmail.com>
- Date: Fri, 16 Oct 2015 23:08:11 +0900
- To: Chaals McCathie Nevile <chaals@yandex-team.ru>
- Cc: public-editing-tf <public-editing-tf@w3.org>
Thank you for the great advice, Chaals. I think we're moving back to the right track as you suggested, and your words helped me to understand what we're trying is the right track. Thank you again! /koji On Fri, Oct 16, 2015 at 9:15 PM, Chaals McCathie Nevile <chaals@yandex-team.ru> wrote: > Hi Koji, > > On Fri, 16 Oct 2015 13:33:46 +0200, Koji Ishii <kojiishi@gmail.com> wrote: > >> Thank you Chaals, this is very helpful and clear. > > > Great. > >> One question: these are clear for WG, but I suppose we'll need >> something to determine if an issue is whether "we happily agree on" or >> not. If it turns not, go to WG resolutions either by CfC or make a >> minutes with "Resolution"s. That's clear now for me, thank you. >> >> Issues are usually discussed in github issues or F2F, and not everyone >> is tracking every issue. I wish, if it's a rather big decision, even >> if people in the issue discussion or F2F seems to be happy, I wish >> clearer communication to the TF to double-check if "we really happily >> agree on" or not. >> >> For that, I'm wondering if sending CfC to TF ML and using the similar >> process as WG would be good. If any objections, we can raise it to WG >> resolutions. If no objections, we can consider "we happily agreed on >> it". >> >> What do you think? Is it overkill? Are there anything we can learn >> from other TF? > > > I think this is a good practice. It doesn't need to be as formal as a CfC > unless the rest of the TF wants that, but an email to the TF list saying > what is proposed will be helpful to check if we really do agree. > > If there is a proposed decision we *think* has wider implications, or that > some people will be unhappy about but might not read the thread, it is > better to let them know, have the full discussion, and get to a real > agreement than make a decision "under the radar", only to find a year later > that we have to go back over it. > > The modern W3C process actually encourages us to do that, asking to get > "wide review" early... > > cheers > > Chaals > > >> /koji >> >> >> On Fri, Oct 16, 2015 at 7:25 PM, Chaals McCathie Nevile >> <chaals@yandex-team.ru> wrote: >>> >>> On Fri, 16 Oct 2015 11:44:52 +0200, Koji Ishii <kojiishi@gmail.com> >>> wrote: >>> >>>> I merely remember, if I'm not mistaken, there were some discussions >>>> that we don't want to make "decisions" at F2F, because this TF has >>>> several Invited Experts and not all can make every F2F. >>>> >>>> I liked that, but I don't think we have discussed how then we would >>>> make "decisions". >>>> >>>> Can we discuss and set our process for what is, say, consensus for >>>> this TF, how to build it, what kind of things would need WG >>>> resolutions, and so forth? >>> >>> >>> >>> We're part of the Web Platform working group, and the formal decision >>> policy >>> is written in the charter: >>> <http://www.w3.org/2015/10/webplatform-charter.html#decisions> >>> That points to the Work Mode documents, which you should read: >>> <https://github.com/w3c/WebPlatformWG/blob/gh-pages/WorkMode.md> (That >>> document can be changed if the Group makes a decision to do so :) ). >>> >>> Things that need WG resolutions are "the things we don't just happily >>> agree >>> on" - the goal is that we create obvious consensus as we go… but of >>> course >>> it doesn't always work out like that. >>> >>> We can make decisions by either >>> 1. Call for Consensus - send an email, giving a week or so, and asking >>> for a >>> "yes/no" answer on a particular question. >>> 2. To make a decision in a meeting we record it as a Resolution, and send >>> the minutes to the Web Platform admin list. People have 10 days to object >>> - >>> e.g. if they weren't at the meeting, and if they don't, it is a decision. >>> >>> In general these should be technical decisions. Background philosophy, >>> like >>> "should we only allow people to type Cyrillic" or "should we determine >>> error-handling for everything" is legitimate for debate, but formal >>> decisions should be on things where this meets testable reality, like "if >>> someone tries to type Cyrillic, throw" or "error X must be dealt with in >>> the >>> following way…" >>> >>> Does that give enough of a framework? Do you think we need more formality >>> within the TF? >>> >>> cheers >>> >>> Chaals >>> >>> (I'm one of the chairs of the WG, so more formally, decisions are what I >>> and >>> my co-chairs announce they are, subject to the constraints from our >>> charter >>> and the process as noted above). >>> >>> -- >>> Charles McCathie Nevile - web standards - CTO Office, Yandex >>> chaals@yandex-team.ru - - - Find more at http://yandex.com > > > > -- > Charles McCathie Nevile - web standards - CTO Office, Yandex > chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Friday, 16 October 2015 14:08:59 UTC