Re: [webappsec] pre-Agenda: Conf Call work mode

I agree with Brian, despite the fact that conf calls make my life as
an editor a lot easier. Unless we figure out how to resolve issues
that Brian mentioned (issues that I have often had too), I don't think
we should increase our reliance on conf calls. They should be
restricted for the issues that absolutely are not making any progress
and the decision should be clearly communicated with detailed notes on
the discussion on the call available publicly.

The only point I disagree with Brian on is that I don't think
everything should be on a public _mailing list_. Any public forum,
including GitHub is fine by me since it allows an outsider to view and
follow along in the discussions.

cheers
Dev

On 3 April 2015 at 13:49, Brian Smith <brian@briansmith.org> wrote:
> Brad Hill <hillbrad@gmail.com> wrote:
>> I think it has proven valuable to socialize discussion of tricky issues and
>> establishing consensus verbally has allowed us to move quickly through
>> things that would block for a long time on the mailing list.  I also like
>> the social accountability it provides for work items, etc.
>
> As an outside participant, I think your conference call has a negative
> effect on social accountability. Multiple times in the past the output
> of the conference call has been "we've decided X" and it isn't clear
> at all who *actively* participated in arriving at that decision (vs.
> just remaining silent during a call for objections, or not attending,
> for example) or what reasoning was used to reach the decision.
>
> Conversely, when consensus is achieved on the public mailing list or
> the issue tracker, it is clear who actively participated and what the
> arguments were.
>
>> 1) Editors would select a teleconference date at which they'd commit to
>> discussion of their spec.  This should be no less than every 3 months, in
>> keeping with a goal of producing a heartbeat draft.
>>
>> 2) Editors would be responsible (with assistance from the chairs as desired)
>> for batching up and keeping track of issues on the list and tracker which do
>> not reach a natural consensus.
>>
>> 3) Prior to the call, Editors would be responsible to work with the chairs
>> to produce an agenda of outstanding issues.  The agenda would contain some
>> background information.
>>
>> 4) Teleconference participants can use plan this to "do their homework" on
>> the outstanding issues for a single spec, and with some introduction on the
>> call from the Editor(s), and so participate more meaningfully.  Participants
>> that are only interested in a single spec can plan in advance to attend the
>> relevant calls even if they do not want to participate on a regular basis.
>
> 1-4 can and should happen even for the public mailing list
> discussions. IMO, the main improvement needed is a more detailed and
> accurate schedule for the working group's work in general, and
> establishing target dates for resolving specific issues.
>
>> 5) The goal of each call should be to resolve enough issues for the
>> Editor(s) to be able to produce a heartbeat draft or advance the document
>> status in the following week.
>
> IMO, Issues should be resolved on the public mailing list, and not in
> the call. If an issue is stuck, then it makes sense to discuss it in a
> teleconference to find a way to unstick it, but the rationale and
> accountability for any actual decision should be clear on the public
> mailing list.
>
> Cheers.
> Brian
>

Received on Monday, 6 April 2015 01:57:11 UTC