W3C home > Mailing lists > Public > public-annotation@w3.org > November 2015

Re: Proposed Working Mode

From: Benjamin Young <bigbluehat@hypothes.is>
Date: Thu, 5 Nov 2015 10:35:35 -0500
Message-ID: <CAE3H5F+tOsCTabJYJJJM2rXehYiYhM-HWJ0bbj-MoxSFE9m2sg@mail.gmail.com>
To: Robert Sanderson <azaroth42@gmail.com>
Cc: Ivan Herman <ivan@w3.org>, W3C Public Annotation List <public-annotation@w3.org>
+1 to focusing our productivity and/or accumulating things we know we'd
like to address in the future for possible re-chartering content.

Onward annotators!
Benjamin
--
Developer Advocate
http://hypothes.is/

On Wed, Nov 4, 2015 at 5:45 PM, Robert Sanderson <azaroth42@gmail.com>
wrote:

>
> Definitely!  Having a clear definition of what we would work on, and
> hopefully having at least half-formed proposals in that space, seems a much
> stronger argument towards rechartering rather than extending and closing.
> Thanks for adding that, Ivan :)
>
> Rob
>
> On Wed, Nov 4, 2015 at 2:40 PM, Ivan Herman <ivan@w3.org> wrote:
>
>> Rob, everyone
>>
>> maybe it is worth adding that we may want to include in the discussions
>> the possibility to postpone issues to be considered by a re-chartered, new
>> WG. Whether the group will be rechartered (after the current charter runs
>> out) or not and, if yes, when is, of course, not decided at this point, but
>> having a clear list of issues that are flagged accordingly is actually a
>> good input for a rechartering process. And it is also a help to separate
>> the issues from those that we definitely must handle before the end of the
>> current charter.
>>
>> Ivan
>>
>> On 5 Nov 2015, at 05:45, Robert Sanderson <azaroth42@gmail.com> wrote:
>>
>>
>> All,
>>
>> As mentioned on the call today, I'd like to propose that we try and take
>> a breadth first rather than depth first approach to our issues.
>>
>> To be discussed, but as fodder for that discussion:
>>
>> Our charter runs out October 1st 2016. By then we should have at least
>> the model, protocol and findtext specifications in Candidate Recommendation
>> with a good set of tests and implementations.   There is no guarantee that
>> the group would be rechartered to continue work, however it's a much easier
>> sell if we can demonstrate concrete and steady progress towards delivering
>> the specifications that we've signed up to produce.  Given all the various
>> timing issues, having the specs in a reasonable state by April/May 2016
>> seems like an important deadline to try and meet.
>>
>> In order to get to that state, we need to streamline our process somewhat
>> to avoid bogging down on any one issue or having non-productive calls.
>>
>> My proposal is that we focus our energies around the github issues and
>> are conscientious to transcribe important list discussions as new issues or
>> comments on existing ones.  On the calls we can then pre-select a set of
>> issues to discuss with a timebox of around 15 minutes per issue.  At the
>> end of the time allocated, we should see what the feeling is around any
>> proposed way forwards with a straw poll, but move on to other issues
>> regardless of the outcome.  Any objections should be then written up with a
>> description of what it would take to change their mind or an alternative
>> solution that would address the requirement.  These would go to the issue
>> (or the list) over the week following the call so that they can be thought
>> about and addressed the next time the issue comes up.  Conversely, if
>> everyone is happy with the proposal, then great, and the editors can move
>> forwards to writing up the resolution.
>>
>> At this stage, I feel (as editor and chair) that there is insufficient
>> time to make sweeping changes to the current approaches. We can't afford
>> another 3 month discussion on roles and expect to meet the timeline
>> needed.  This we need a process that will not railroad decisions despite
>> valid technical concerns or squash productive discussions, but we also need
>> to make progress and determine whether concerns are valid and the
>> discussions actually productive :)
>>
>> This would not cover non technical issues, nor issues that span WGs.
>> Frederick and I would treat these as guidelines to ensure progress rather
>> than hard and inflexible rules to squash discussions.
>>
>> Thoughts?
>>
>> Rob
>>
>> --
>> Rob Sanderson
>> Information Standards Advocate
>> Digital Library Systems and Services
>> Stanford, CA 94305
>>
>>
>>
>> ----
>> Ivan Herman, W3C
>> Digital Publishing Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153
>> ORCID ID: http://orcid.org/0000-0003-0782-2704
>>
>>
>>
>>
>>
>
>
> --
> Rob Sanderson
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305
>
Received on Thursday, 5 November 2015 15:36:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:42 UTC