- From: Benjamin Young <bigbluehat@hypothes.is>
- Date: Thu, 5 Nov 2015 10:35:35 -0500
- To: Robert Sanderson <azaroth42@gmail.com>
- Cc: Ivan Herman <ivan@w3.org>, W3C Public Annotation List <public-annotation@w3.org>
- Message-ID: <CAE3H5F+tOsCTabJYJJJM2rXehYiYhM-HWJ0bbj-MoxSFE9m2sg@mail.gmail.com>
+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