Re: Interim meetings - changing the way we work

[Benoit Claise <[e-mail]>]

On 27/02/2015 16:03, t.p. wrote:
> Inline <tp>
>
> ----- Original Message -----
> From: "Thomas D. Nadeau" <[e-mail]>
> To: "Berger Lou" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Thursday, February 26, 2015 10:23 PM
>> On Feb 26, 2015:5:12 PM, at 5:12 PM, Lou Berger <[e-mail]>
> wrote:
>> Tom,
>> On 2/26/2015 4:48 PM, Thomas D. Nadeau wrote:
>>>> On Feb 26, 2015:4:30 PM, at 4:30 PM, Joel M. Halpern
> <[e-mail]> wrote:
>>>> Thomas, if participants who can not make the conference calls are
> obliged to listen to the full recordings to get the key points of what
> has happened, why, what are the questions, and similar issues that need
> to be visible to the WG, then we are not running an inclusive process
> that allows for participation by the range of individuals we need.
>>> That is the problem. We're really only geared to have full-on, in
> person meetings all the time. That does not lend itself to being
> flexible/agile.  That is not to say that I want to exclude anyone, but
> to be fair, if a subset of people want to move a pile of work forward,
> we shouldn't ENCOURAGE that behavior not stifle.
>> It sounds to that you are describing design team meetings (or, in some
>> cases, an authors meetings).  I'm not sure what makes folks think that
>> the only way folks can collaborate is via the mail list or full on
>> interim meetings.
> Yes.
>>>> There is a reason that the IETF distinguishes between design teams
> meetings, where the design team has to explain their work carefully to
> the WG, and working group meetings.  There has always been a problem of
> not getting as much context as we would like from the WG minutes.  But
> since we explicitly take all resolutions to the list, this is
> ameliorated by folks being able to ask for explanations, by those issues
> being taken to the list promptly, and by the fact that we only met 3
> times a year.  If you have bi-weekly calls and the WG can not tell what
> is going on with those calls, then what you have is a design team.  And
> then the folks involved need to own up to it as a design team,
> understand that they need to explain to the list what they have
> analyzed, their reasoning, and their conclusions.
>>> Design teams should be able to work asynchronously, but with fixed
> schedules and not have to have everything explicitly documented at every
> step.
>> 100% agree.
>>
>> I've been involved in many of such meetings (conf calls, webex, etc.)
>> and the key is that DT/authors' meetings need to be explained and
>> discussed on the list *at a time of their choosing*, which in my
>> experience is usually when a draft is published/updated.
>>
>>> If someone else is curious, they can get involved but not in order to
> slow things down or throw a monkey wrench into the works. If people want
> to keep leaning back on 10 year old process RFCs and arguing "well thats
> just the way we've always done things around here" then this
> organization is going to continue to slow its progress even more - and
> its descent into irrelevancy.  There are a lot of people here (myself
> included) that want to evolve things because they think the IETF still
> has a lot to offer the industry. But if the organization won't evolve,
> people will take the path of least resistance and go elsewhere as they
> have been doing if you haven't noticed.
>> This statement just confuses me as you note below we've always had
> ways
>> for folks to make progress fast -- when there's interest in doing so.
>> It just seems to me that many are enamored with interims and think
> it's
>> the sole/best way of demonstrating progress between full meetings.
>> Perhaps you're just saying that they're mistaken...
> Its not being enamored as much as it being one of the only
> obvious/acceptable vehicles to progress WG-level
> work forward - at least if the management is involved. In NETMOD for
> example, we've broken the interims into two "themes": Yang 1.1 work and
> modeling.  The former is like its own design team, and the latter is
> like many design teams coming to one place every other week.  The former
> not only meets every other week, but discusses issues on the list. But
> to the latter - that is more like a touch point for those subteams.
> Those subteams go off on their own for weeks at a time and iterate as
> needed. And they work without all of the overhead of a formal meeting.
> They may or may not discuss progress on the list until issues come up.
>
> <tp>
> Tom
>
> Take a small group of engineeers, expert in technology, get them to hold
> regular meetings focussed on a narrow range of topics and they can make
> faster progress, as you cite for 'netmod'.
>
> What is also likely to happen, and I see it with netmod, is that they
> will develop their own way of working, their own terminology, their own
> technology even, which de facto raises the bar for anyone else who wants
> to participate or to understand what happened.  They don't mean to
> exclude other people, they just do. (small groups, Psychology 101)
>
> I see 'netmod' as a poster child for this with its issue list, state
> machine for issues and so on.  Even though I was tracking the list when
> the 'Ynn' issue list was created, I don't know where its state machine
> came from.  In recent minutes, I don't know what
> "  AB: I am not sure YANG 1.0 specifies C1 explicitly somewhere.
>    JS: Does A3 not follow from A2?
>    KW: A3 is more a corollary of A2.
>    AB: The high-level problem is how to create and maintain the
>        information needed to achieve A4. "
>
> is about; a brief search of mailing list and I-Ds gave me no explanation
> for A2 to C1.
And what about an email to the NETMOD mailing list, asking this question?
How is this any different than meeting minutes on a physical meeting, on 
which you would have a question?

Regards, Benoit
>
> And if a different group of engineers works on different topics, then
> they will likely, in the absence of any guidance, use different
> technology, different terminology and end up with a way of working that
> is as alien to the first group.
>
> As I said, changing the way we work.
>
> Tom Petch
> </tp>
>
>
>
>
>
> --Tom
>
>
>> Lou
>>
>>> If you want a real example of how this can actually work, watch Anees
> explain how Open Config has done this with just weekly phone calls and a
> bunch of people typing on keyboards. They've done this in less than a
> year, and have rough consensus and (production) running code.  This is
> how the IETF used to operate: people got together, hacked code and got
> things working.  The goal was not having meetings, but producing code
> with rough consensus.
>>>
> https://code.facebook.com/posts/1421954598097990/networking-scale-recap
>>> --Tom
>>>
>>>
>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> On 2/26/15 4:21 PM, Thomas D. Nadeau wrote:
>>>>>> On Feb 26, 2015:4:16 PM, at 4:16 PM, Brian E Carpenter
> <[e-mail]> wrote:
>>>>>> On 27/02/2015 09:08, Thomas D. Nadeau wrote:
>>>>>>>> On Feb 26, 2015:2:42 PM, at 2:42 PM, Benson Schliesser
> <[e-mail]> wrote:
>>>>>>>> Nico Williams wrote:
>>>>>>>>> Yes, but a record that a concall or other interim meeting took
> place,
>>>>>>>>> and who attended, even if there are incomplete or missing
> minutes, is
>>>>>>>>> important for IPR reasons.  Ensuring that such meetings are
> NOTE WELL
>>>>>>>>> meetings is (should be) a priority, and that includes ensuring
> that a
>>>>>>>>> record of that much exists.
>>>>>>>>>
>>>>>>>>> Ideally the concalls and other interims would be recorded.
>>>>>>>> I agree completely. My point was that meeting records (including
> minutes) will inevitably be incomplete, or possibly inaccurate, and that
> relying on the mailing list as an authoritative record is more
> effective.
>>>>>>>> Of course it is disappointing that we can't meaningfully
> translate voice discussions into text, in the minutes or in mailing list
> threads. If there were some magic tool e.g. that took better minutes
> then I'd be happy to use it. But otherwise, I think we just have to
> trust chairs to manage WG collaboration in whatever way is most
> effective for their WG's collaborators.
>>>>>>> The first step is to agree that an A/V recording is record
> enough.
>>>>>> It absolutely is not enough. Please see my previous message,
>>>>>> and the relevant rules in RFC 2418.
>>>>>>
>>>>>>   Brian
>>>>> You are missing my point. RFC or not, the IETF needs to evolve.
>>>>>
>>>>> --Tom
>>>>>
>>>>>
>>>>>
>>>>>>> Perhaps having meetbot/txt notes that at a min include
> actions/decisions like we do in the issue tracker we've used for
> NETMOD's Yang 1.1's issues.
>>>>>>> --Tom
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> This will inevitably be suboptimal for some part of the
> population. (For instance, I've never been able to find an interim
> meeting time that fits the schedules of all attendees.) But if they (we)
> always revert to the mailing list for decision making then I suspect our
> work can remain open and transparent.
>>>>>>>> Cheers,
>>>>>>>> -Benson
>>>>>>>>
>>>>>>>>
>>
>>
>>
> .
>