Jupyterhub: Weekly team meetings

[choldgraf]

Hey all, we should make sure to figure out a team plan for synchronization! There have been discussions here and there on gitter, email, etc, but perhaps it's worth trying to formalize a bit. The following items are general points as I've understood them, but totally open to changing them, they're just a starting point.

Below is the current proposal from which we're working. Feel free to add your thoughts below and I'll continue to update the top-level comment!

--

Weekly

• A short written report on goings-on of the JupyterHub / Binder world. This would be written as a hackmd, and would include:
  
  
  
  1. An autogenerated report on GitHub new issue / commit activity. (stats-focused to give an idea of the heartbeat of the project)
  
  
  2. A section where team members can update with items they'd like to share with the team, including things like partnerships made / important conversations / design considerations / etc (should link to github issues as much as possible)
  
  
• A one-hour gitter office hour that we advertise to the public, but where we can also say hello to one another too!

_this hackmd would be committed to a github repo each week._

requirements: all on the core jhub team should give their own updates ~50% of weeks. Office hours should be a "try to keep an eye on the gitter channel but don't kill yourself to do it" kinda thing

Monthly

• a one-hour video conference (recorded for those that can not be in attendance). Emphasis on:
  
  
  
  • reviewing issues that have been tagged as enhancement
  
  
  • discussion on any major change to the code that would affect the whole team (e.g., automation)
  
  
  • discussing next-steps on the more high-level components of the project (e.g. how to follow up with collaborators/projects, communication w/ public, etc)
  
  
  • for anything requiring longer-term discussion, this should be broken off into GitHub issues
  
  

_we should keep a list of topics to discuss throughout the month (farmed from the weekly syncs) and have an idea of the topics to discuss before this meeting happens_

requirements: everybody should try to make each monthly meeting, though meetings will be recorded.

--

Curious as to thoughts from the team! @willingc @minrk @yuvipanda @Carreau @betatim @fperez @ellisonbg @mpacer (please cc any others who I am not remembering!)

[ellisonbg]

I think this is a good idea for the JupyterHub team and would participate
as much as my schedule would allow. A few misc thoughts about these types
of meetings:

• We have weekly video meetings for JupyterLab/notebook and they are really
  important for building up the team and providing a high bandwidth comm
  channel to discuss strategy, roadmap and more technical things that are
  difficult on github, gitter, etc. While these meetings are open and
  recorded, their primary purpose is for the core team itself to function
  well.
• I hypothesize that there is a phase transition in the communication
  patterns that are possible around 8ish participants. Below 8ish
  participants, these meetings work really well without much formal structure
• conversations and decision making feels pretty natural and easy. As the
  number goes much above 8ish, formal structure is needed. This is why we run
  our project wide Tuesday meetings in a very different manner than the
  Friday JupyterLab/notebook ones. I think the JupyterHub team is small
  enough that it would immediately see the benefits of these types of
  meetings, with almost no structure.
• My encouragement is to not hesitate to dive into significant topics, both
  technical and strategic - there are times at the JupyterLab/notebook
  meetings that we stop recording after an hour, but keep talking for as many
  as 2 more hours!
• If you want to record, we now have the zoom Jupyter channel at Cal Poly
  that we are using for the Tues/Fri meetings.

On Thu, Nov 16, 2017 at 8:51 AM, Chris Holdgraf [e-mail]
wrote:

Hey all, we should make sure to figure out a team plan for
synchronization! There have been discussions here and there on gitter,
email, etc, but perhaps it's worth trying to formalize a bit. The following
items are general points as I've understood them, but totally open to
changing them, they're just a starting point.
General plan

A short meeting for the team to discuss current state of the project and
what they're working on, having trouble with, etc. (my preference is that
this be kept strictly short, and be more of a "team update" kind of thing
than a "long discussion" kind of thing. For longer conversations etc, we
could break out into separate conversations later or open a github issue)
How often?

Weekly or bi-weekly.
Who involved?

Anybody in the JupyterHub ecosystem (e.g. jupyterhub, k8s jupyterhub,
binder)
Format

A google hangout-like chat.
Other ideas

Some had suggested an asynchronous sync-up rather than an in-person video
chat. I'd be friendly to this, though think there's still value in
occasionally having an in-person chat as well (maybe just not each week).

Personally, I think this is a good idea to make sure that we're all on the
same page, though I am open to suggestions for ways to do this
asynchronously etc. I think many of you have more experience than I when it
comes to working with largely-remote teams, so I'll defer to your thoughts.

Curious as to thoughts from the team! @willingc
https://github.com/willingc @minrk https://github.com/minrk @yuvipanda
https://github.com/yuvipanda @Carreau https://github.com/carreau
@betatim https://github.com/betatim @fperez https://github.com/fperez
@ellisonbg https://github.com/ellisonbg @mpacer
https://github.com/mpacer (please cc any others who I am not
remembering!)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jupyterhub/jupyterhub/issues/1543, or mute the thread
https://github.com/notifications/unsubscribe-auth/AABr0KBTszJvj1ErY2qacanwvyVYnpg7ks5s3GgqgaJpZM4QgzHN
.

--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[email protected] and [email protected]

[jzf2101]

Please include me!

[betatim]

I suggested trying to keep as much as possible async. I find video meetings much more high bandwidth and less effort to communicate things than writing. However they are much more exclusive than GitHub issues + gitter. There are people who want the meeting to be during working hours (because it is their job), there are people who want the to be outside working hours (because it is a hobby), and when "working hours" is depends on what timezone you are in.

A one hour meeting requires a time slot in your agenda (much) bigger than 60minutes: to allow you to arrive on time, have a buffer in case you over run slightly, and time to prepare/finish off notes.

For a small team that can meet you get a high bw comms channel and as a result a project that can move quickly. However you are limiting yourself to a small team. An alternative is a slower pace but larger number of team members. The integrated pace might be comparable or higher.

If you decide that attendance is not mandatory or people start discussions (again) on issues that result from the meeting, you might wonder why you had the meeting in the first place. Or you decide that decisions will be made, and anyone who didn't make it to the meeting lost their chance to vote.

I don't know which option is better, but wanted to raise some of these points to hear what people think. In my experience the energy required to create a meeting is much lower than that required to cancel one.

[choldgraf]

@betatim I think you make a lot of good points, though I am unsure what alternative you are proposing! A weekly issue where we write in our updates?

[willingc]

Hi all,

@betatim raises some good points. Here's what I would like to see:

• a weekly autogenerated report on GitHub new issue activity
• a once a week on-line office hour on gitter
• a standing monthly meeting (1 hour max - recorded for those that can not be in attendance) where the emphasis is on reviewing issues that have been tagged as enhancement and discussion on any automation stuff that would be timesavers for the entire team.
• monthly standing meeting should be mostly an interactive discussion not a status update (since status update are fairly low value use of folks' time for an in person meeting)

[choldgraf]

I think that's a nice balance between in-person and async. Agree w/ monthly meetings being interactive if we're keeping them to once a month.

Have you used a similar issue activity auto-generated report approach before? Sounds cool, just trying to figure out if we'd need to write our own code for this or if something already exists.

[ellisonbg]

I think it is important to have clear goals for such a meeting. Some of the
ones I am hearing are:

1) Update people about recent and ongoing activity in the jupyterhub org
(status updates)
2) Enable core developers to have team building opportunities
3) Enable the extended development community to interact with the core
developers
4) Enable core developers to have high bandwidth, interactive discussions
about important strategic and technical matters

In my mind, the videos meetings are best at 2) and 4). I love Carol's idea
of autogenerating update reports - I think that is a much better way of
handling status updates than a video meeting.

I also think having weekly meetings may not be needed. From the team
building perspective, I think 1/month is a bit too sparse. Maybe every
other week? I don't have a good sense of how much technical discuss there
is to be had.

One other minor comment - in the JupyterLab meeting, we do short status
updates, but mostly because it serves to "get us talking" and leads to the
more significant discussions. I don't think status updates are the only way
to get folks talking, but something to get folks talking is helpful. We
often find that it takes us 30m before we all remember the things we
actually need to talk about...

Cheers,

Brian

On Fri, Nov 17, 2017 at 9:34 AM, Chris Holdgraf [e-mail]
wrote:

I think that's a nice balance between in-person and async. Agree w/
monthly meetings being interactive if we're keeping them to once a month.

Have you used a similar issue activity auto-generated report approach
before? Sounds cool, just trying to figure out if we'd need to write our
own code for this or if something already exists.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jupyterhub/jupyterhub/issues/1543#issuecomment-345310761,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABr0KEyng3iTqN4TwqLG2ZrV023sWxbks5s3cOggaJpZM4QgzHN
.

--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[email protected] and [email protected]

[Carreau]

I suggested trying to keep as much as possible async. I find video meetings much more high bandwidth and less effort to communicate things than writing. However they are much more exclusive than GitHub issues + gitter. There are people who want the meeting to be during working hours (because it is their job), there are people who want the to be outside working hours (because it is a hobby), and when "working hours" is depends on what timezone you are in.

Yes please. I've shared a proposal for change of meeting format for the weekly Jupyter Meeting, but did not get feedback from @ellisonbg and Fernando. I was proposing switching to mostly written.

A TLDR of my proposal was:

Shared document that should be filled-in by let say monday-9am-PST. That would be formatted, sent to the mailing list on Monday 10am PST. That gives a single thing to read per week. And then on Tuesday 9am PST, if there are still questions, then do a high-bandwidth meeting with those interested.

I'm afraid of @willingc auto generated recap as it can have lot of noise (typo fix, questions, cleanup...) Though I think it is a good _complement_.

One thing I would really like to be careful of is to not have end up in a format that exclude our community non-intentionally. Anything real-time, or with multiple questions/answer like a thread risk to have this effect.

[willingc]

I'm afraid of @willingc auto generated recap as it can have lot of noise (typo fix, questions, cleanup...) Though I think it is a good complement.

Just an FYI, the generated report would be metrics not a meeting recap.

[minrk]

I like @willingc's proposal of separating the "keep people appraised of what's going on" task (weekly async communication) from the high-bandwidth, high-cost synchronous meetings. I think monthly is a good interval for that.

A generated summary of what's going on as a starting point, with personal notes added as appropriate, especially to cover activities not on GitHub (X met with folks at Y, etc.) seems a good start.

[choldgraf]

OK, so synthesizing a bit of above, what about the following?

---

Weekly

• A short written report on goings-on of the JupyterHub / Binder world. This would be written as a hackmd, and would include:
  
  
  
  1. An autogenerated report on GitHub new issue / commit activity. (stats-focused to give an idea of the heartbeat of the project)
  
  
  2. A section where team members can update with items they'd like to share with the team, including things like partnerships made / important conversations / design considerations / etc (should link to github issues as much as possible)
  
  
• A one-hour gitter office hour that we advertise to the public, but where we can also say hello to one another too!

_this hackmd would be committed to a github repo each week._

requirements: all on the core jhub team should give their own updates ~50% of weeks. Office hours should be a "try to keep an eye on the gitter channel but don't kill yourself to do it" kinda thing

Monthly

• a one-hour video conference (recorded for those that can not be in attendance). Emphasis on:
  
  
  
  • reviewing issues that have been tagged as enhancement
  
  
  • discussion on any major change to the code that would affect the whole team (e.g., automation)
  
  
  • discussing next-steps on the more high-level components of the project (e.g. how to follow up with collaborators/projects, communication w/ public, etc)
  
  
  • for anything requiring longer-term discussion, this should be broken off into GitHub issues
  
  

_we should keep a list of topics to discuss throughout the month (farmed from the weekly syncs) and have an idea of the topics to discuss before this meeting happens_

requirements: everybody should try to make each monthly meeting, though meetings will be recorded.

--

I can update top-level comment with this structure if we want to continue iterating from this starting point.

[jzf2101]

we might want an associated blog post to go with the monthly meeting

[choldgraf]

That's a good idea - maybe instead of a small blog post for each weekly sync, we can compile them into some kind of monthly post

[betatim]

I like it @willingc! Especially the "office hour" idea! This is maybe not so much something for coordinating but gives everyone a place to go and ask questions, work on things, get quick-ish replies, meet others, etc.

[choldgraf]

Just heard about GitHub team discussions...who wants to play around with this w/ me? :-)

https://github.com/blog/2471-introducing-team-discussions

[willingc]

Can we please use anything other than google docs and check the markdown in a github repo?

[choldgraf]

Sure - gdocs was just the first thing that came to mind. We could do hackmd and then copy/paste that into the repo?

[willingc]

Yes, please hackmd would be fine. Also we can use the repo to generate a simple site. I'm -0 on a blog post initially. Highest priority is to improve team communications/dynamics and project management with outward communication a lower priority.

[choldgraf]

I updated my comment to reflect the hackmd, and to downplay the blog post aspect and instead focus on recording the hackmd content in the github repo. I think those are good points!

[ellisonbg]

More important than a blog post is that any decisions are encoded into
relevant GitHub issues. Because these meetings already have a very high
cost (in time) I would minimize the extra things involved in them. If
someone has cycles to write a blog post, I think that is fine, but
shouldn't hold up the meeting or be done instead of opening/updating
regular Github issues.

On Mon, Nov 20, 2017 at 3:49 PM, Chris Holdgraf [e-mail]
wrote:

I updated my comment to reflect the hackmd, and to downplay the blog post
aspect and instead focus on recording the hackmd content in the github
repo. I think those are good points!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jupyterhub/jupyterhub/issues/1543#issuecomment-345857794,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABr0M7B3lD8mgr3l88BgTKXGwxi4Jsmks5s4gIFgaJpZM4QgzHN
.

--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[email protected] and [email protected]

[ellisonbg]

Another thing that has worked in the past is to pick a label, such as
"Needs Discussion" to use for issues/PRs that need the high bandwidth
discussion at these monthly meetings. It is sort of a lightweight way of
agenda setting as the month goes by.

On Mon, Nov 20, 2017 at 3:55 PM, Brian Granger [e-mail] wrote:

More important than a blog post is that any decisions are encoded into
relevant GitHub issues. Because these meetings already have a very high
cost (in time) I would minimize the extra things involved in them. If
someone has cycles to write a blog post, I think that is fine, but
shouldn't hold up the meeting or be done instead of opening/updating
regular Github issues.

On Mon, Nov 20, 2017 at 3:49 PM, Chris Holdgraf [e-mail]
wrote:

I updated my comment to reflect the hackmd, and to downplay the blog post
aspect and instead focus on recording the hackmd content in the github
repo. I think those are good points!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jupyterhub/jupyterhub/issues/1543#issuecomment-345857794,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABr0M7B3lD8mgr3l88BgTKXGwxi4Jsmks5s4gIFgaJpZM4QgzHN
.

--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[email protected] and [email protected]

--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[email protected] and [email protected]

[willingc]

Hi all,

@betatim and I have been working on a weekly document and archived here as a template.

The document aims to capture the following in an organized and consistent manner. It will work best if bullets are brief (i.e. action verb and short description - see example). If it needs a long written explanation, it would be better as an issue and linked to the weekly document:

• Dates: starting and closing since it spans a week (recommend Saturday start and Friday close)
• autogenerated reports of GitHub activity (Section I - initially the weekly report from the Tuesday team meeting; later expanded for project metrics)
• news and informational items that it would be valuable for the entire team to be aware of (Section II)
• discussion items and questions (Section III)
• decisions needed (i.e. roadblocks) (Section IV)
• team next actions (Section V)
• Thanks, fun stuff, and anything else (Section VI)

It is perfectly cool to leave sections blank on any given week. The overarching goals are:

• better team communication, recognition, and trust
• continuous process improvement
• minimal disruption and in person meeting time
• push out information to entire team (Sections I, II, and VI)
• raise questions and ideas for incremental changes/improvements (Sections III, IV, V)

Many of the same concepts that work for incident reports at mybinder.org-deploy would also apply here (blameless, working toward future improvements).

[betatim]

I started putting some things in because: no time better then the present to get started. Not sure if I am doing it right, but won't figure that out until I start doing it.

[willingc]

Update from Jupyter/IPython weekly meeting (see for active links):

The JupyterHub and Binder Team has created a template for weekly virtual meetings for continuous team improvement. Here’s an archive of the report from last week’s first virtual meeting. Link to this week’s virtual meeting. Carol will be moving this to a new repo within the jupyterhub org after she gets some time to do so. Original GitHub issue.

Next actions:

• [ ] Fill out this week's virtual team meeting covering (11/27 to 12/4)
• [ ] Create a team-continuous-improvement repo in JupyterHub org

[choldgraf]

Hey all - resurfacing after holidays. This looks great and big thanks to @willingc and @betatim for putting together the team doc.

I'll fill in new activity soon! Just to be clear, we aren't planning on attaching names to any of the items in the list? It doesn't seem like the items in there currently are doing so. Just making sure I understand correctly!

[willingc]

@choldgraf I would say that the names are fine, but not necessary, if they come after the particular action or bullet item say in parens (Tim, Chris). The huge exception to this would be "thank you"s.

[willingc]

This is going to evolve over time as well. Continuous improvement is the goal in all the things. :sunny:

[choldgraf]

I opened up a repo here: https://github.com/jupyterhub/team-improvement

wanna use that for team syncs / weekly update docs / etc?

[willingc]

I want to rename the repo to team-compass.

[choldgraf]

hey all - I'm closing this now since github.com/jupyterhub/team-compass exists and we're now having weekly syncs and monthly video chats!