Proposed Working Mode

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