Subject: [Manycouches] DOGFOOD Virtual BoF

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Apr 2019 08:38:49 -0400

At IETF we had a bar BoF which hopefully quite a few people on this mailing list attended.   At the BoF we had a round table discussion about what peoples ideas were for getting the IETF into a new mode of operation that makes better use of the technology we’ve developed, rather than requiring in-person meetings as a driver for getting work done.

At the BoF we agreed to have a virtual BoF online in about a month.   It’s about two weeks before the deadline for that, so I wanted to have a quick discussion about what to do at this BoF before announcing it.  Because this is not an IETF working group, the usual notification requirements don’t technically apply, but on a practical level I think two weeks notice is just as necessary for a virtual BoF as for a virtual interim, so I’m going to ask the secretariat to announce it the same way.

I would like to try out some of the stuff that Wes talked about in his presentation at HotRFC: rather than just doing a normal BoF, I’d like to see if we can use existing tools to achieve some of what Wes described.   We will still want to do some online video discussion, but I’d also like to try using a Wiki and an interim-only mailing list as the primary communication method, and do the BoF over two days to give us time to participate in the way Wes described.   This may fail miserably or may go well—we can only find out by trying.

If we go ahead with this, one of the things I will ask is that you add to the Wiki your recollection of what you said in the bar BoF.   I at least didn’t take notes, and I don’t think Wes did either, but I think there was a lot of useful stuff exchanged there.

Does anybody object to this approach?   If I don’t hear loud objections, I’ll set up a wiki and ask people to work on it; I’d like it if we could do that work before the interim so that at the interim we can talk about it and form some ideas for experimentation.

Thanks!

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Apr 2019 09:06:32 -0400

Ted Lemon <[email-masked]> wrote:
    > Does anybody object to this approach?  If I don’t hear loud objections,
    > I’ll set up a wiki and ask people to work on it; I’d like it if we
    > could do that work before the interim so that at the interim we can
    > talk about it and form some ideas for experimentation.

Does this include a daily summary?  Was that part of the process?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Apr 2019 09:09:52 -0400

> Does this include a daily summary?  Was that part of the process?

It could be.   That raises the question of whether “daily” is the right frequency, though.   Possibly it should be more like work-daily, since if we account for time zones, there are arguably three work days per calendar day and in a virtual interim of the type Wes described, all of those hours would potentially be active.   So having a person who volunteers to do the summary for each of the three time intervals would probably be good.

Alternatively, we could do a running summary in the wiki.   More work, but probably more effective.

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 16 Apr 2019 22:27:34 -0700

Ted Lemon <[email-masked]> writes:

Thanks Ted for poking us (and sorry for the delay on my end).  I've been
giving this a lot of thought since our couch/comfy-chairs discussion at
IETF104.

> I would like to try out some of the stuff that Wes talked about in his presentation at
> HotRFC: rather than just doing a normal BoF, I’d like to see if we can use existing
> tools to achieve some of what Wes described.   We will still want to do some online
> video discussion, but I’d also like to try using a Wiki and an interim-only mailing
> list as the primary communication method, and do the BoF over two days to give us time
> to participate in the way Wes described.   This may fail miserably or may go well—we
> can only find out by trying.

I think that sounds like a good approach to try.  We have to experiment
somehow, so lets try it!

My thoughts last week actually turned toward: we should hold an interim
every month-ish, for a limited time (I was thinking 24hrs, but your 48
does make more sense to get at least 1 RTT per person).

But I'd also like to ask people to think about what they want to do for
that 48hrs and make each one different.  Let's collect experiment
results, essentially, and try new things every time and see what works
and what doesn't.  So, the first one is already laid out: your wiki idea
is an intriguing one, so I'm all for it!
-- 
Wes Hardaker
USC/ISI

---

From: "Mukom Akong T." <[email-masked]>
Date: Wed, 17 Apr 2019 19:11:32 +0400

On Wed, 10 Apr 2019 at 16:39, Ted Lemon <[email-masked]> wrote:

>  At the BoF we had a round table discussion about what peoples ideas were
> for getting the IETF into a new mode of operation that makes better use of
> the technology we’ve developed,
>

I think we ought to question even the tools and not assume that the current
tools as we have now are the best ones for the new approach we want to try.
If there's some more effective tool out there, let's find it and try it.
It's better to settle on current tools with the secure knowledge that we've
tried the alternatives.

>
> I would like to try out some of the stuff that Wes talked about in his
> presentation at HotRFC: rather than just doing a normal BoF, I’d like to
> see if we can use existing tools to achieve some of what Wes described.
> We will still want to do some online video discussion, but I’d also like to
> try using a Wiki and an interim-only mailing list as the primary
> communication method, and do the BoF over two days to give us time to
> participate in the way Wes described.   This may fail miserably or may go
> well—we can only find out by trying.
>

Agree about moving into action. Could we start by having an online page
somewhere which states what we're trying to accomplish and gives context?
An email chain might not be the best way to do this. It could be

- wiki
- dropbox paper
- google doc
- etc etc

I'd suggest it be structured in the form of an experiment in a form like

Objective: Run a BoF completely with no travel
├ Key Result #1: 100% of BOF planning and execution done completely online
├ Key Result #2: 50% of those who sign up for the BoF stick through till
the end
├ Key Result #3: 75% of those who stick to the end agree to sign up for a
second BoF

The numbers we can play with.

>
> If we go ahead with this, one of the things I will ask is that you add to
> the Wiki your recollection of what you said in the bar BoF.   I at least
> didn’t take notes, and I don’t think Wes did either, but I think there was
> a lot of useful stuff exchanged there.
>

I sure will

> I’ll set up a wiki and ask people to work on it; I’d like it if we could do
> that work *before* the interim so that at the interim we can talk about
> it and form some ideas for experimentation.
>
> Thanks!
>
> _______________________________________________
> Manycouches mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manycouches
>

-- 

Mukom Akong T.

LinkedIn:Mukom <https://www.linkedin.com/in/mukom>  |  twitter:
@perfexcellent

------------------------------------------------------------------------------------------------------------------------------------------
“When you work, you are the FLUTE through whose lungs the whispering of the
hours turns to MUSIC" - Kahlil Gibran
-------------------------------------------------------------------------------------------------------------------------------------------

---

From: Keith Moore <[email-masked]>
Date: Wed, 17 Apr 2019 12:40:55 -0400

I think we have to start somewhere, so starting with some base case - 
say just email - makes more sense than trying every tool right off the bat.

Or _maybe_ email and some sort of shared editor that can keep track of 
what's been concluded. but even then we need to have some discipline for 
what to put where.   Also, if we use multiple tools without some kind of 
integration between them I don't think we'll find that collection of 
tools very useful.   Sometimes even when sticking to one tool - say 
slack - I find that the information that emerges from the discussion is 
so scattered that it's nearly unusable.

I also am loathe to use third-party tools that track my activity, and 
would not want to see IETF adopt such tools.  So, for instance, google 
anything is (IMO) not appropriate.

We should decide what kind of tools we need rather than insisting on 
shoehorning our activity into existing tools.   And I'm not aware of an 
existing tool that would do the job well.

On 4/17/19 11:11 AM, Mukom Akong T. wrote:
> I think we ought to question even the tools and not assume that the 
> current tools as we have now are the best ones for the new approach we 
> want to try.
> If there's some more effective tool out there, let's find it and try 
> it. It's better to settle on current tools with the secure knowledge 
> that we've tried the alternatives.
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 17 Apr 2019 15:34:36 -0400

> Or _maybe_ email and some sort of shared editor that can keep track of what's
    > been concluded. but even then we need to have some discipline for what to put
    > where.   Also, if we use multiple tools without some kind of
    > integration

It sounds like we want a wiki technology that uses git as a backend.
The repo can be cloned, and the history can be a signed commit/tag giving a
clear statement as to what has been concluded.

There are quite few options, including what github offers via host jekyll:
  https://www.google.com/search?q=wiki+with+git+backend
  https://duckduckgo.com/?q=wiki+with+git+backend&t=h_&ia=web

    > I also am loathe to use third-party tools that track my activity, and would
    > not want to see IETF adopt such tools.  So, for instance, google anything is
    > (IMO) not appropriate.

I understand your view.
This view has become a barrier to entry for many.  I wish that weren't so.

---

From: Keith Moore <[email-masked]>
Date: Wed, 17 Apr 2019 16:42:13 -0400

> This view has become a barrier to entry for many.  I wish that weren't so.

I wish more people respected others' privacy.

And BTW, I also wouldn't consider using any service owned by Microsoft.

---

From: "Mukom Akong T." <[email-masked]>
Date: Thu, 18 Apr 2019 06:40:26 +0400

> say just email - makes more sense than trying every tool right off the bat.

trying "every other tool" for say X months is starting somewhere and will
enable us to pick the most effective tool with the confidence of experience.

>
> shared editor that can keep track of
> what's been concluded.

this looks like a good requirement.

> but even then we need to have some discipline for
> tools very useful.

tech integration between multiple tools is a good requirement at a future
state. in the beginning and for a small number of people, that discipline
can be provided with a imple process that we all agree to follow.

>    Sometimes even when sticking to one tool - say

i use slack extensively at work, we define clearly what needs to
conversations that happen in slack

- if it's a key decision, someone gets an action item to make an entry into
the team's "Decision Log"  (a wiki page)
- if it's a set of tasks that need to be done, someone gets an action item
to create those as tasks in a project management system (JIRA) with a due
date and assignee

most "tool problems" are really just a lack of discipline in following a
pre-agreed upon process.

> anything is (IMO) not appropriate.

that's fair and we can use that as a requirement for evaluating different
tools: "does not track user activity"

> existing tool that would do the job well.

thank you. this is the thinking behind my suggestion. if we are trying to
do something different, it _may_ not be possible to use existing tools,
thinking and processes.

-- 

Mukom Akong T.

---

From: "Mukom Akong T." <[email-masked]>
Date: Thu, 18 Apr 2019 06:45:58 +0400

One of the issues that Ted raised that got me to come to the BoF is the
fact that not enough new people are coming into the IETF.

Also bear in mind that while I respect everyone's desire for privacy and
thus not use tools from Google or Microsoft or Facebook, those tools might
be the only options available right now affordable to lots and lots and
lots of engineers.

If we want to open up the work we do, we will have to find an answer to
that.

-- 

Mukom Akong T.

---

From: Keith Moore <[email-masked]>
Date: Wed, 17 Apr 2019 22:55:44 -0400

On 4/17/19 10:45 PM, Mukom Akong T. wrote:

> One of the issues that Ted raised that got me to come to the BoF is 
> the fact that not enough new people are coming into the IETF.
>
> Also bear in mind that while I respect everyone's desire for privacy 
> and thus not use tools from Google or Microsoft or Facebook, those 
> tools might be the only options available right now affordable to lots 
> and lots and lots of engineers.
>
> If we want to open up the work we do, we will have to find an answer 
> to that.

I still remember the days when we were able to effectively collaborate 
using just email, so I guess I think it's probably still possible.   
That said, there are some things that email can't do well.

Also, IETF has its own tools for several things already, so I'm not sure 
why it should be out-of-scope to add another tool or two.   There are 
advantages and disadvantages to that (e.g. I hate that people pretty 
much have to learn a special dialect of XML to write internet-drafts), 
but it should be within the realm of consideration.

Keith

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 18 Apr 2019 11:34:27 +0200

> this looks like a good requirement.

compared to IMHO the tooling issues in other areas, i think etherpad is
doing pretty well. The main problem IMHO is the logistics discipline to
set up manually some wiki page for some effort in which to collect all
relevant URLs for the effort at hand so that not every participant needs
to bookmark everything and newcomers don't have to beg to figure out how
an efforts toling is structured.

> can be provided with a imple process that we all agree to follow.

See above. One single URL for an effort to remember, rest of logistics
should follow from there. IMHO that means root URL is on a wiki.

> conversations that happen in slack

Never used slack. Would love to see someone giving a summary of best
practices and what it achieves and what not.

> most "tool problems" are really just a lack of discipline in following a

consumer instead of contributor mentality ;-)
Who can take minutes at a wg meeting.... ;-))

> tools: "does not track user activity"

How much is an effort willing to pay for or contribute to tools whose
business model is not tracking or advertisement ?

Lets start with creating awareness of the tools business model and judge
later. The interest in not being tracked would IMHO also differ widely
based on what a particular effort is. 

> do something different, it _may_ not be possible to use existing tools,

Its always good to have convincing justification to do something new.

Nobody can of course be stopped to reinvent the weel unnecessarily, but
if there are any spare resources for creating something new, it would be
great if those resources could be steered to where the biggest gaps are,
and not just where the most fun in unnecessary repetitious work is.

[
  can we please spend 10x the work for the web-page to re-skin it...
  every 3..4 years..
  and taking the web-page repeatedly down in the process...
  and make it actually worse afterwards...
  except in the eyes of whoever seems to judge how much money our
  company is worth...
]
sorry, couldn't resist. ;-))

Cheers
    Toerless