Experimenting with a modified dev meeting format?

[Fernando Perez]

Hi all,

from looking at how our most recent dev meetings have been going, it appears that we're probably reaching a size of team where having meetings that are so long, and where we try to have detailed, back-and-forth discussions for making technical decisions, is just not working well anymore...

While the idea of a public "all hands" dev  meeting is one we're very happy to have, and want to continue (and other projects seem to have followed in our step), it seemed to work better when the group needing to really discuss things in detail was a fair bit smaller.

In recent meetings, we're having folks tune out quite a bit, and we're probably not making very effective use of the time of others...

So here's a proposal for a modified format:

- We turn our Tuesday 10am PST meeting into instead a "short reports" meeting, where each person provides a quick update of the topics/problems they've been working on, and presents any questions they may have, help they may need from others on the team, etc.

- From this, we identify which sub-groups may later on break into other channels (our regular mailing list, issues on github, quick discussions on gitter, etc), to actually make decisions.

Basically, once  a meeting has more than ~4-6 people, it doesn't really make sense to have it really be a detailed, long technical discussion, since most people will likely tune out.  So only those people really involved should participate.

This way, the regular 'all hands' meeting will be a more useful way for everyone to remain informed of what we're all doing on the project, how things are going, etc.

Then, there's the *separate* question of the technology for the meeting.  Lately, using Google+ has been driving us crazy, creating crashes for many of us, dropping connections, etc... We'd like to experiment with other options and see what works.

For now, we're going to try BlueJeans, it's something we have at Berkeley, and which allows both web browser and plain old phone client access, it may be a little better than G+.  We'll see how it goes.

Thoughts?

Cheers

f

--

Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail

[MinRK]

I think turning Tuesdays into check-ins/reports is a good idea. Having just one or two topics for actual in-depth meetings with smaller groups should definitely be more effective.

-MinRK

--
You received this message because you are subscribed to the Google Groups "Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+u...@googlegroups.com.
To post to this group, send email to jup...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/CAHAreOoFNhXpv9o_JrLUpUGuum60JUSW1JH8pQ873M0QEW%2BbMA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Brian Granger]

> - We turn our Tuesday 10am PST meeting into instead a "short reports"
> meeting, where each person provides a quick update of the topics/problems
> they've been working on, and presents any questions they may have, help
> they may need from others on the team, etc.

I like this idea. It would be great to encourage everyone involved in
the project to participate in this on a regular basis - even those who
are not "core developers." For example, having my students participate
would help integrate them into the larger project.

I think we should limit the person time though - maybe 7 minutes?

>
> - From this, we identify which sub-groups may later on break into other
> channels (our regular mailing list, issues on github, quick discussions on
> gitter, etc), to actually make decisions.

We will probably have to think and talk further about the best way of
gathering the right sets of people at the right times and propagating
the information out, but this is a good next step.

> Then, there's the *separate* question of the technology for the meeting.
> Lately, using Google+ has been driving us crazy, creating crashes for many
> of us, dropping connections, etc... We'd like to experiment with other
> options and see what works.
>
> For now, we're going to try BlueJeans, it's something we have at Berkeley,
> and which allows both web browser and plain old phone client access, it may
> be a little better than G+. We'll see how it goes.

I think it will be great to give this a shot. One of the ongoing
issues we have is with multiple people using the same mic. Even at
BIDS where you have a fantastic mic - it often leads to awful echoes
and audio problems.

Cheers,

Brian

>
> Thoughts?
>
> Cheers
>
> f
>
> --
> Fernando Perez (@fperez_org; http://fperez.org)
> fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
> fernando.perez-at-berkeley: contact me here for any direct mail
>

> --
> You received this message because you are subscribed to the Google Groups
> "Project Jupyter" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jupyter+u...@googlegroups.com.
> To post to this group, send email to jup...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jupyter/CAHAreOoFNhXpv9o_JrLUpUGuum60JUSW1JH8pQ873M0QEW%2BbMA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

--
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgra...@calpoly.edu and elli...@gmail.com

[Matthias Bussonnier]

> On Jun 28, 2015, at 07:28, Brian Granger <elli...@gmail.com> wrote:
>
> I like this idea. It would be great to encourage everyone involved in
> the project to participate in this on a regular basis - even those who
> are not "core developers." For example, having my students participate
> would help integrate them into the larger project.
>
> I think we should limit the person time though - maybe 7 minutes?

I proposed 10 min 3 weeks ago.

I would also really appreciate to not have 3 words like: “Tag”. An entry on
the hackpad should be self explanatory (unless link to an issues which is self explanatory).
Like if the person who wrote that is not here we can decide without them.

Have 1 person responsible for taking notes, and turn the hangout into a written small report,
that we (eventually) post on the blog to keep reader in the loop.

That’s typically the kind of 1 way communication (this is what happened) that do not
require general feedback from ML, except on relevant issues.

>> - From this, we identify which sub-groups may later on break into other
>> channels (our regular mailing list, issues on github, quick discussions on
>> gitter, etc), to actually make decisions.
>
> We will probably have to think and talk further about the best way of
> gathering the right sets of people at the right times and propagating
> the information out, but this is a good next step.

You mean we still don’t know how to open an issue on GitHub ?

Seem pretty obvious, open an issue, people can subscribe or unsubscribe
on a per issue bassi and coordinate.

> I think it will be great to give this a shot. One of the ongoing
> issues we have is with multiple people using the same mic. Even at
> BIDS where you have a fantastic mic - it often leads to awful echoes
> and audio problems.

Even when you have your earplugs you also generate echo.
:-)

--
M

[Brian Granger]

>> I think we should limit the person time though - maybe 7 minutes?
>
> I proposed 10 min 3 weeks ago.

Yes and it was a good idea! The only problem is that 10 minutes is
incompatible with a meeting whole goal is to make a lot of technical
decisions. We found that out pretty quickly.

Upon thinking more, I am thinking that putting a 5 minute max person
might even be too high.

>
> I would also really appreciate to not have 3 words like: “Tag”. An entry on
> the hackpad should be self explanatory (unless link to an issues which is self explanatory).
> Like if the person who wrote that is not here we can decide without them.

But I think the main content of Fernando's proposal is that we won't
ever make decisions in the dev meetings.

>
> Have 1 person responsible for taking notes, and turn the hangout into a written small report,
> that we (eventually) post on the blog to keep reader in the loop.

I don't think the blog post is appropriate for most of this stuff -
and I don't think we have anyone that wants to take the time to turn
the summary in to a weekly blog post yet.

>> We will probably have to think and talk further about the best way of
>> gathering the right sets of people at the right times and propagating
>> the information out, but this is a good next step.
>
> You mean we still don’t know how to open an issue on GitHub ?

Of course not. But as the project grows, people will be working in a
more focused and specialized manner, unaware of what is going on in
the rest of the project. Even today, with ~15-20 repos, not all of us
are subscribed to all of them. We need ways of propagating information
from all that development activity on all of those repos in a way that
project leadership is able to guide the whole project in a coherent
manner. Also, remember, we are hiring a number of non-coders who will
need to participate in the project.

> Seem pretty obvious, open an issue, people can subscribe or unsubscribe
> on a per issue bassi and coordinate.

I don't think that is reasonable. We have to start having people
focusing and specializing and part of that is that more and more
people will be involved in the project, but not coding. We will soon
have people focused on design, fundraising, event planning,
budget/admin, hiring, managing staff, industry relations, etc. We have
a huge challenge in integrating these efforts into the code-centric
core of the project, but we have to.

> Even when you have your earplugs you also generate echo.
> :-)

Yes, that one was super weird - have never seen it before or since.

Cheers,

Brian

>
> --
> M

>
> --
> You received this message because you are subscribed to the Google Groups "Project Jupyter" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+u...@googlegroups.com.
> To post to this group, send email to jup...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/4D2EC1FC-C333-4DCF-B8DE-9D005FE934FE%40gmail.com.

[Brian Granger]

I propose we frame the reports in the form of the following 3 questions:

* What have I been working on?
* What do I plan on working on?
* What things are preventing me from making progress?

With these questions, the goals of the meeting would be:

* Keep everyone working as effectively as possible.
* Give everyone enough information about what others are working to
know what conversations they need to have.

Also, I am thinking about 5 minutes/person is probably about max. I
think that longer reports that have broad appeal (conferences,
collaboration meetings, long lines of technical work) should be made
on the main mailing lists.

Cheers,

Brian

[Wes Turner]

* https://wrdrd.com/docs/consulting/software-development#stand-up-meeting
* https://wrdrd.com/docs/consulting/software-development#digital-stand-up-meeting

  * etherpad-lite (operational transformation)

* https://wrdrd.com/docs/consulting/team-building#collaboration-engineering

_______________________________________________
IPython-dev mailing list
IPyth...@scipy.org
http://mail.scipy.org/mailman/listinfo/ipython-dev

[Matthias Bussonnier]

Hi Wes, 

On Jun 29, 2015, at 09:00, Wes Turner <wes.t...@gmail.com> wrote:

* https://wrdrd.com/docs/consulting/software-development#stand-up-meeting
* https://wrdrd.com/docs/consulting/software-development#digital-stand-up-meeting

  * etherpad-lite (operational transformation)

* https://wrdrd.com/docs/consulting/team-building#collaboration-engineering

Thanks for the links, can you, when you post link make a small recap ? 

It would avoid for those of us reading this offline to at least know what this

is about, and also what the pint you are trying to make, as often people can

interprete articles differently. 

Keep in mind that if you take 2 minutes to do that, and that people reading that

only win 10 sec, but there is 100 of them, that still make a global win on 16 minutes

for the project. 

Cf this small post of Nick Coghlan[1] explaining that 222 years of

collective human existence pass each seconds. 

Tip: try to put all your links after your signature, if the mail do not make sense, 

then it probably won’t have enough impact. Also URL often disapear, so it make

reading this in 1 year difficult.

Thanks a lot, 

-- 

M

[1] http://www.curiousefficiency.org/posts/2014/09/seven-billion-seconds-per-second.html

[Wes Turner]

On Jun 29, 2015 3:01 AM, "Matthias Bussonnier" <bussonnie...@gmail.com> wrote:
>
> Hi Wes, 
>
>
>> On Jun 29, 2015, at 09:00, Wes Turner <wes.t...@gmail.com> wrote:
>>
>> * https://wrdrd.com/docs/consulting/software-development#stand-up-meeting
>> * https://wrdrd.com/docs/consulting/software-development#digital-stand-up-meeting
>>
>>   * etherpad-lite (operational transformation)
>>
>> * https://wrdrd.com/docs/consulting/team-building#collaboration-engineering
>
>
> Thanks for the links, can you, when you post link make a small recap ? 

Like minutes that persist from a digital stand up meeting?

I could cc snippets of a source RST block?

> It would avoid for those of us reading this offline to at least know what this
> is about, and also what the pint you are trying to make, as often people can
> interprete articles differently. 

Really, I noticed the discussion regarding three questions and stand-up meetings, and had just updated that section of the linked knowledge base of concept URIs (as well as https://wrdrd.com/docs/consulting/education-technology#jupyter-and-learning #jupyter-and-reproducibility)

If I might interject, etherpad-lite is really the simplest possible way to write markdown for e.g. a github wiki as a team.

>
> Keep in mind that if you take 2 minutes to do that, and that people reading that
> only win 10 sec, but there is 100 of them, that still make a global win on 16 minutes
> for the project. 
>
> Cf this small post of Nick Coghlan[1] explaining that 222 years of
> collective human existence pass each seconds. 
>
> Tip: try to put all your links after your signature, if the mail do not make sense, 
> then it probably won’t have enough impact. Also URL often disapear, so it make
> reading this in 1 year difficult.
>
> Thanks a lot, 
> -- 
> M
>
> [1] http://www.curiousefficiency.org/posts/2014/09/seven-billion-seconds-per-second.html
>
>
>

[Nicholas Bollweg]

Status reports in lighting talk format as slide notebooks! Mmm, dog food.

[Fernando Perez]

On Sat, Jun 27, 2015 at 8:07 PM, MinRK <benja...@gmail.com> wrote:

I think turning Tuesdays into check-ins/reports is a good idea. Having just one or two topics for actual in-depth meetings with smaller groups should definitely be more effective.

OK, here's a wrap-up and my suggested path forward, so we can call this thread done, unless someone objects strenuously to something.  As usual, we will fine-tune over time as we learn from experience...

-  Let's go with a max of 5 minutes per person on reporting of activity.

- When reporting, you should try make sure what you say answers the following questions for the others:

* What have I been working on?
* What do I plan on working on?
* What things are preventing me from making progress?

This will ensure that everyone leaves knowing what everyone is up to, and that we can effectively help each other, identify where resources are needed, bottlenecks, etc.

- We try to take notes as usual collectively on Hackpad, BUT, we designate a person each week who has an explicit responsibility that week to spend a bit of time after the meeting making sure the notes make sense and posting them to the Jupyter list. Hopefully that won't take more than a few minutes, if the collective note-taking was sufficient.

This will give us a static record on the list of each week's meeting, which is better than just having a doc on hackpad.

I volunteer to be the note-poster for tomorrow.

- Let's keep the total meeting time to 1h, hard limit.  Tomorrow, we're going to use a trick to enforce that: our nice videoconferencing room at BIDS is booked at 11am every other Tuesday, so we'll get kicked out anyways.  We could obviously use another one, but instead we'll use the room with the better audio equipment and be forced to stay on schedule :)

Did I miss anything?

Cheers,

f

[MinRK]

Sounds like a good plan. See you all tomorrow.

-MinRK

 

Cheers,

f

--
You received this message because you are subscribed to the Google Groups "Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+u...@googlegroups.com.
To post to this group, send email to jup...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/CAHAreOpdZ4tryfYk0PKktwJ2iTbhyMttYoGD9JU3c8A4CdM5mA%40mail.gmail.com.

[Brian Granger]

Sounds good, I have also posted a summary of these changed at the top
of the meeting hackpad. See you tomorrow!

Cheers,

Brian

> https://groups.google.com/d/msgid/jupyter/CAHNn8BV61o_M8ziSOQnfOJz0Am6Pux14Yk6TVumCBK28LsaMVw%40mail.gmail.com.

>
> For more options, visit https://groups.google.com/d/optout.

[Matthias Bussonnier]

Last minutes change of plan (Probably) new furniture beeing installed in video-room.
So no BlueJeans setup.
We will have to fallback on something else most likely.

--
M

> To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/CAH4pYpSLq5LqHgoX1ULsqw3EwB%3Dn%2BR0qiqYKE%2BrHb2R2JEQSLg%40mail.gmail.com.

[Brian Granger]

We are using bluejeans from another room - seems to be working fine


On Tue, Jun 30, 2015 at 9:21 AM, Jason Grout <ja...@jasongrout.org> wrote:
> We could set up an audio conference call if needed. Let us know if we need
> to.
>
> Jason

>> _______________________________________________
>> IPython-dev mailing list
>> IPyth...@scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
> _______________________________________________
> IPython-dev mailing list
> IPyth...@scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>

[Brian Granger]

I know with SciPy we probably won't have a dev meeting next week, but
before the next one, we should test a bunch of different audio
configurations.

[Brian Granger]

Jason - I will be down a few minutes before noon.

Cheers,

Brian

[Damián Avila]

I could not attend because I was going to the airport, but looking into the notes and the video, I think this was a successful experience.

I agree there is still audio issues, more remarkably when the microphone is shared in the room. Otherwise, it is a *substantial* improvement over the gh experience. Eager to join the next one.

Cheers.

To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/CAH4pYpQM8u1a9dcddLUESjbRAiR8E5FMTbnZj139hWsGr8tT6A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Damián Avila

[Fernando Perez]

On Sun, Jul 5, 2015 at 8:00 PM, Damián Avila <damia...@gmail.com> wrote:

I could not attend because I was going to the airport, but looking into the notes and the video, I think this was a successful experience.

I agree there is still audio issues, more remarkably when the microphone is shared in the room. Otherwise, it is a *substantial* improvement over the gh experience. Eager to join the next one.

We want to note that the shared room microphone was an rare, pure Murphy's law incident: I had booked the room and when we tried to go in, there was construction going on.  We will normally have a room for shared microphone use that has an excellent speakerphone with zero echo (we've used it successfully in many other meetings at BIDS).

Otherwise, individuals can use single-person headsets that are fine.

But more importantly, the new meeting format seems to have been a very nice and successful change.

Reminder: no meeting tomorrow, most of the team is in-person at SciPy'15.

Cheers,

f