Re: Proposal: Asynchronous review process for specification changes

Thank you for the responses and for the suggestion of waiting for the next
charter period to start using a new review process for specification
changes.

On Thursday a resolution was made to apply for a one year extension to the
current WoT Working Group Charter, which would then presumably end on 31st
January 2023.

Have I understood correctly that the decision process for speeding up the
decision process would therefore take 18 months from proposal (August 2021)
to implementation (February 2023)?

That unfortunately would not do much to help with meeting the deadlines
proposed for the current charter period, which is currently my primary
concern.

Regards

Ben

On Fri, 12 Nov 2021 at 14:22, Mccool, Michael <michael.mccool@intel.com>
wrote:

> Yes, the charter renewal would be a good chance to document and improve
> our decision making processes.  Sorry I missed this discussion Wednesday,
> but I do feel it’s important.
>
> Michael
>
>
>
> *From: *Kazuyuki Ashimura <ashimura@w3.org>
> *Date: *Thursday, November 11, 2021 at 2:23 PM
> *To: *Ben Francis <ben@krellian.com>
> *Cc: *public-wot-wg@w3.org <public-wot-wg@w3.org>, member-wot-wg@w3.org <
> member-wot-wg@w3.org>, team-wot@w3.org <team-wot@w3.org>
> *Subject: *Re: Proposal: Asynchronous review process for specification
> changes
>
> On Fri, 12 Nov 2021 02:24:08 +0900,
> Ben Francis wrote:
> >
> > [1  <text/plain; UTF-8 (7bit)>]
> > [2  <text/html; UTF-8 (quoted-printable)>]
> > Hi all,
> >
> > This is just a gentle nudge to say that I haven't yet received any
> feedback on this
> > proposal, though other working group members have expressed an interest
> in
> > adopting a process along these lines.
> >
> > I'd be really grateful for any feedback, positive or negative, since I
> am still
> > struggling to get timely reviews on specification contributions and
> deadlines are
> > looming!
> >
> > I feel sure we could make more progress if we made more effective use of
> the
> > tools available to us.
>
> Thanks, Ben!
>
> As I mentioned at the end of the Architecture call today:
>   https://www.w3.org/2021/11/11-wot-arch-minutes.html#t08
> I think we need to identify which Issues and Pullrequests need what
> level of discussion (i.e., GitHub online discussion only or live
> discussion during the TF calls) as part of the potential asynchronous
> review process, and would suggest we have further discussion about
> that (and the whole potential process) on this thread and during the
> WoT main call.
>
> Please note that as we confirmed at the beginning of the Architecture
> call today:
>   https://www.w3.org/2021/11/11-wot-arch-minutes.html#t03
> we're wrapping up our specs and need to freeze Architecture by Dec-15
> and freeze Profile by Jan-31 respectively.
>
> So I personaly think it might make sense to apply the potential
> asynchronous decision making policy to the next Charter period.
>
> Thanks,
>
> Kazuyuki
>
>
> >
> > Ben
> >
> > On Tue, 3 Aug 2021 at 16:27, Ben Francis <ben@krellian.com> wrote:
> >
> >  Dear members of the WoT Working Group,
> >
> >  At the end of the WoT Architecture call last week Michael McCool and I
> had a
> >  brief conversation about the approval process for landing pull requests
> on W3C
> >  WoT specifications. I suggested that there might be an opportunity to
> make the
> >  review process more efficient by using asynchronous tools, rather than
> the
> >  current approach of only merging pull requests following a resolution
> in a
> >  synchronous weekly conference call.
> >
> >  Currently:
> >
> >  1 It is common to get to the end of a two hour meeting without having
> >  managed to review all of the open pull requests in a given repository
> >  2 If anyone is missing from the call who may have feedback, the
> discussion is
> >  often deferred for a week or more until they are available to join a
> call
> >  3 When pull requests are reviewed there isn't always a clear resolution
> about
> >  whether or not to merge and discussion can end up being paused until the
> >  following week
> >  4 Sometimes only small changes are needed to a pull request before
> landing
> >  it, but it has to wait another week for a chance for another review
> >
> >  Based on experience from other W3C Working Groups I'd therefore like to
> >  propose using GitHub's in-built code review tools to formally review
> pull
> >  requests without having to wait for the stars to align in a weekly call.
> >
> >  It seems to me that this form of asynchronous decision making would
> also be
> >  more in line with the Working Group's existing Decision Policy.
> >
> >  Non-normative Changes
> >
> >  * For non-normative or editorial changes to the wording of a
> specification, I
> >  propose that a code review approval from a single Editor of the
> specification
> >  should be sufficient to merge a pull request.reating
> >
> >  Normative Changes
> >
> >  * For normative or breaking changes to a specification, I propose that
> an
> >  approval be required by all active Editors of a specification. Editors
> should
> >  use GitHub's code review tool to either:
> >
> >  * Approve the pull request (approval may be conditional on making some
> >  small changes like fixing typos before landing, noted in a comment)
> >  * Request changes to the pull request, explained in a comment
> >  * Comment to say that they have no strong opinion, deferring to the
> opinion
> >  of other editors
> >
> >  * A pull request can be landed once all editors have either provided
> their
> >  approval or deferred to the other editors
> >  * Editors are expected to provide formal reviews, but all members (and
> >  non-members) may contribute to the public discussion on GitHub
> >  * If consensus can not be reached asynchronously, then a synchronous
> >  discussion in a web conference may be needed to arrive at a consensus.
> If a
> >  unanimous decision can not be reached then Chairs may call for a group
> >  vote to resolve a deadlock in line with the Working Group's existing
> Decision
> >  Policy
> >  * If there are Editors of a specification who are not currently
> regularly
> >  available for reviews and are not able to consistently review changes
> within
> >  a week or so, I propose that they should temporarily or permanently be
> >  moved to an "inactive" or "emeritus" editors list so that they don't
> block the
> >  review process
> >
> >  Note that the beauty of version control is that decisions need not be
> final. It is
> >  easy to revert a change or modify it with a follow-up commit. There are
> also
> >  plenty of opportunities to provide feedback on changes after they have
> >  landed, through the various stages of W3C publication.
> >
> >  I further suggest this process could be aided by:
> >
> >  1 Descriptive commit messages and pull request titles, ideally
> referencing an
> >  issue number that a patch relates to
> >  2 Configuring a simple template for pull requests where authors can
> select
> >  whether they consider the change to be normative/breaking or
> >  non-normative/editorial and therefore which level of review they are
> >  requesting
> >
> >  I would value your feedback on this proposal, which could potentially be
> >  discussed in tomorrow's main WoT call.
> >
> >  It is also my hope that more efficient asynchronous working practices
> may
> >  eventually allow for a drastic reduction in the number of W3C WoT
> meetings
> >  conducted each week, which has in recent months ballooned out of
> control to
> >  around twelve hours a week.
> >
> >  Best regards
> >
> >  Ben
> >
> >  --
> >  Ben Francis
> >  Founder
> >  Krellian Ltd.
> >
> >  *
> >
> > --
> > Ben Francis
> > Founder
> > Krellian Ltd.
> >
> > *
>


-- 
Ben Francis
Founder
Krellian Ltd. <https://krellian.com>