Tweaks to Sprint Monday + Community Hangout

[jbenet]

Hello IPFSers!

The IPFS Project is growing, and so is the number of people hanging out at the sprint meeting. At last week's hangout, we sadly left many people out.

I had three goals for the Spring Hangout:

a) Give quick synchronized updates on progress. It helps build team rapport.
b) Make space for real-time high-throughput discussion of open questions.
c) Have some regular face-to-face interaction. It's good for humans and communities :)

(a) and (b) are getting hard with so many people, touching so many different areas. At the same time, we've observed that it's actually most useful to sync about things via discussion on irc / github or dedicated topic hangout. And (c) is hard to do when you leave people out :(

Also, we've been discussing sprint things before breaking out into groups to have more detailed discussions. Usually the important sprint items appear at those discussions, and then the sprint list is finalized at the end of the day.

So, thinking of moving to this (let's try this for this week):

On monday, we have three parts:

• Part 1: restrospective: go over last sprint and dicuss what got done, etc. kick off etherpad (async on irc).
• Part 2: per-topic sync discussions / hangouts (sync/async) (more below)
• Part 3: by evening, finalize sprint list (turn etherpad into an issue)

PLUS! A Weekly Community Hangout \o/ - more below.

Topic Discussions

We've naturally fallen into discussing certain topics at high throughput realtime, like node-ipfs, bitswap, and so on.

I figured it would be good to make space during monday for non-overlapping discussions on various topics. Happy to add more here, but so far the things that jump out at me are:

• go-ipfs
• node-ipfs
• testing + ci
• protocol specs
• apps on IPFS
• bitswap (ml)
• data structures
• infrastructure

Weekly Community Hangout

This is more to talk about quick community news, high level direction for the projects, status updates, show off cool hacks, have people meet each other, introduce new people, and in general just hang out.

This is like a short Meetup, or "an all-hands" (or TGIF for those familiar). I would love to experiment with different things, like hanging out in various virtual worlds, VR, video, and so on (more on this later). The time for this will be tricky, because it is towards the end of the week.

Many distributed companies get away with Friday @00:00Z (that's Thu-Fri, and Thursday at 5pm PDT). This leaves people's Friday night plans intact :) though it is 00:00 or 02:00 in Germany -- then again, everyone's around till very late anyway!

I do see a lot of people around on other days (Sun/Mon) too. So open to different times. The goal is to find a good time that works for everyone and is fun, not a problem to join.

Other Distributed Tools

• https://sqwiggle.com/ - could work well for the Async sprint meeting, and to just have a channel. Not public :(
• https://idonethis.com/ - could work well instead of sprint checkins + to keep everyone appraised of what's up without having to sift through the irc channel.
• http://www.worldtimebuddy.com/ - easy TZ conversion

[jbenet]

times for today

• 21:00Z (14:00 PDT) node-ipfs - https://plus.google.com/hangouts/_/gyafa4mpgz7g6jntijoxshfe3ma
• 21:30Z (14:30 PDT) infrastructure - https://plus.google.com/hangouts/_/gq3ieylu6bufzbnovemvb2rraia
• 22:00Z (15:00 PDT) go-ipfs - https://plus.google.com/hangouts/_/g4hc3dnpdvwsklyfd2sxhkwbgqa
• 22:30Z (15:30 PDT) testing + ci - https://plus.google.com/hangouts/_/gwn656w2cihn7lekdarfzhaquea
• 23:00Z (16:00 PDT) protocol specs
• 23:30Z (16:30 PDT) apps on IPFS
• 00:30Z (17:30 PDT) bitswap (ml)
• 01:00Z (18:00 PDT) data structures

[whyrusleeping]

times are in UTC?

[jbenet]

@whyrusleeping yeah

[jbenet]

http://www.worldtimebuddy.com/ ftw

[wking]

On Mon, Jun 08, 2015 at 12:34:41PM -0700, Juan Batiz-Benet wrote:

• 22:30 apps on IPFS

This seems broad and fuzzy. I guess we just see how it goes, but we
may want to split this into app classes (separate pub/sub session?
Package-manager session? etc.) in the future.

Mon, Jun 08, 2015 at 12:36:48PM -0700, Juan Batiz-Benet:

http://www.worldtimebuddy.com/ ftw

Also ‘date’ from GNU Coreutils:

$ date --date '22:30 UTC'
Mon Jun 8 15:30:00 PDT 2015
$ TZ=Europe/Berlin date --date '22:30 UTC'
Tue Jun 9 00:30:00 CEST 2015

[jbenet]

This worked well so doing it again this week.

[jbenet]

I think this has been working very well (please give feedback!!)

We haven't yet done a "Community Hangout", we should plan one for next week. Maybe using Zoom.us or maybe in another system.

[daviddias]

I like the focused discussions format a lot, please keep doing it.

I would love for us to have timetable ready at least 24 hours before, so people can put on their schedule and be available, avoiding having to spend a lot of time pinging people in IRC, which leads to delays.

[jbenet]

@diasdavid

I would love for us to have timetable ready at least 24 hours before, so people can put on their schedule and be available, avoiding having to spend a lot of time pinging people in IRC, which leads to delays.

very much agreed. do you mean the time table for "discussions"? they've been ~roughly the same for the last couple weeks. i added them to https://github.com/ipfs/pm#sprint-discussion-schedule -- or do you mean something else?

maybe you mean the individual checkin over irc? i'd go with allocating 5min to everyone (so we could make a timetable) but that may waste more time as people wont always be exact... also good for people to listen to what others are up to/getting done, etc? not sure. it could work well.

[daviddias]

@jbenet true that the discussions have been roughly at the same time, but there was still some 30 to 60 min delays for some of them and that makes things harder for the people in Europe, as it gets later and later. Nevertheless, you just solved it with the addition to a specific base schedule :) Thank you.

As for IRC "pings", I just meant that before having it officially scheduled, someone had to "ping" to check who was around, which in part caused the delays.

[jbenet]

Yep all agreed. I'm very much in favor of wasting zero time :)

[ghost]

A few things which I'd like us to do, or resume doing:

• setting sprint goals: helps to prioritize tasks, and to focus on them over the course of the sprint. If sync concludes well (in, say, 20 minutes), we can briefly set the goals for the sprint. Example: this week we'll work towards achieving X and Y, because event Z is ahead, and X+Y+Z is important because of [...].
• new and improved sprintbot, which knows weekends, makes the sync role call, announces the hangouts, and is aware of the sprint participants.
• having the new etherpad ready before the hangouts.
• taking brief notes of what was discussed in the hangouts. the notes don't have to be detailed at all, just a quick list of topics. at the beginning of each hangout, we'd agree who takes notes in the sprint etherpad.

[jbenet]

@lgierth yes i completely agree. If someone can take over:

• can someone take over managing the etherpad + sprint issues from me? i have too many random things to get done and this is really important.
• can someone take over "making sure someone takes hangout notes on the etherpad"?
• @whyrusleeping or @lgierth can you make the necessary changes to sprintbot?

[whyrusleeping]

I can modify sprintbot, and can also potentially make him generate a 'blank' etherpad on mondays

[ghost]

• can someone take over managing the etherpad + sprint issues from me? i have too many random things to get done and this is really important.
• can someone take over "making sure someone takes hangout notes on the etherpad"?

I'll take care of it -- I'm not sure I'll make all the hangouts but I'll keep bugging people

[jbenet]

thanks @lgierth

[RichardLitt]

So, I recently read this article on remote working, and I had some takeaways:

Events

Having coordinated, real-life meet ups every now and then would be hella cool.

Video preparedness

I (and by extension, most other people) don't know before showing up which video conferences will be done that day. That shouldn't be happening; we should post the day before which ones are going to exist, or not. I think this should be the sync masters job, unfortunately - or it could be the job of a chosen participant for each of the videos.

Long Running Notes

Further, there's no real continuity between the different video meetups. There should be a running log of things talked about in those video chats. The easiest way to do that is to have a single document for taking notes. From the article: "All recurring meetings have a single Google Doc with a running head for “pending” items, and dated notes, in reverse chronological order (newest items at the top)." Everyone in a meeting should be responsible for taking notes. Everyone shouldn't take individual notes- they should take notes, together. If you were there, you should have added to the shared notes, because that's what they are for - communication is the most important part of coding, and other people who may want to help can't if they don't know and aren't present. What I think we can change here is to have a single document that is persistent for each meeting, and have updates clear to that. The 'Add your notes' thing we are doing doesn't work. "Here's the Hangout link, and here is the notes link (same as always)" should work better.

Preparing sprint updates before the sync

I think everyone should have their notes prepared before the sync. Otherwise, we kill a lot of time asking who is able to go first, not saying X should go first, and there's a lot of asking if someone is ready yet. It should be assumed that you are, or not.

Being on IRC during the sync

People are not actually on IRC during the sync, far too often. I've often seen someone post their updates, waited a minute, asked if someone else can go, and then people jump in saying they need to catch up and read the previous persons notes, when they had plenty of time. This slows the entire sync down, and leads to people who have already communicated wandering off and reading random wikipedia articles. The only way I can see around this is to ask everyone, absolutely everyone, to only have one tab open during the sync: the IRC tab. This means preparing your checklist before, too.

[ghost]

There should be a running log of things talked about in those video chats.

Very much agreed, this is important! I've been trying to keep logs of the infrastructure hangouts in etherpads, and have been adding the link to the respective sprint etherpad.

Here's the Hangout link, and here is the notes link (same as always)" should work better.

Maybe this should be "here's the meeting link", which is the notes etherpad and also contains the link to the hangout at the top.

Being on IRC during the sync

Agreed, the syncs should be a lot shorter. In addition to the explicit start (a la "alright who wants to go first"), they should also have an explicit ending.

[RichardLitt]

Ought we to close this? I think we have a good system at the moment. We've replaced the sprint bot with me, but I think it works better to have a human do it.

Things that are in this thread that would be good that we don't do:

• Weekly Community hangout, to talk about random stuff
• Have sprint goals that are for the entire team, and not just for each segment (go-ipfs for why, js-ipfs for diasdavid, and so on).