Communications, mailing lists, gitter, etc...

[Fernando Perez]

Hi all,

sorry for the cross-post, but this is precisely about project-wide communication.  Probably best to keep the thread on the Jupyter list.

As the project has grown, we've tried to adapt our communications channels both to serve the community and to manage our limited resources.  Time for email is scarce (I know I'm not the only one perennially behind), and for certain problems real-time conversation is extremely valuable.  

So we've added gitter to our mix of tools, and in some cases our gitter rooms are very useful.  But we're also finding a problem: it's proving to be very hard to follow the "big picture" of the project if you're not directly participating in those conversations. Even for *me*, since these days I unfortunately rarely have that kind of time, many parts of the project have become quite opaque, and reading gitter logs is not the same as reading an email archive.  While it's perfectly viable to read a long and complex email thread to catch up on a  discussion after the fact, doing so with a real-time chat log is, in practice, nearly impossible.

So, we'd like to fine-tune our communication practices, so that we hit a better balance of having a "slow record" over asynchronous email, while allowing for the more rapid-fire discussion that real-time channels like gitter allow.

The tools at our disposal are:

- Our mailing lists (jupyter & IPython-dev)

- Our gitter rooms: we don't want to kill them, we just need to adjust what we want to use them for, and probably reduce the number of rooms.  As the number of repos we have grows, having dozens of rooms is probably not manageable.

- Github: issues will continue being used by folks as a mechanism to effectively submit problem reports that, in practice, are often questions.

- StackOverflow: not to be underestimated, it's archival, searchable, etc.

I don't want to dictate policy here, so I'll propose a rough first draft, to allow for discussion, ideas and fine-tuning:

- We try to do a better job of communicating important ideas, questions, discussions, etc, on the project lists.  Let's encourage our users to do the same.  We also post key announcements more regularly here.  Everyone should really feel comfortable 

- We stop pointing people to gitter as the *first* help stop.  We should point them to the mailing list (and? OR?) StackOverflow instead.  Having a non-archival medium be the first point of help means a vast amount of duplicated and wasted time helping people.

- The Gitter real-time help room and repo rooms can remain active but we try to maintain a discipline of using them only for when folks need the real-time collaboration.  If key decisions are made here, let's try to have a discipline of periodically posting a quick summary, even if it's just a very short one, to the mailing list, pointing out what happened.  In the long run, it will help us all better keep in touch with what the project is doing.

What other ideas do people have, that can help us better communicate, both among project regulars and with the more occasional, broader community participants?

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

[Brian Granger]

> The tools at our disposal are:
>
> - Our mailing lists (jupyter & IPython-dev)
>
> - Our gitter rooms: we don't want to kill them, we just need to adjust what
> we want to use them for, and probably reduce the number of rooms. As the
> number of repos we have grows, having dozens of rooms is probably not
> manageable.
>
> - Github: issues will continue being used by folks as a mechanism to
> effectively submit problem reports that, in practice, are often questions.
>
> - StackOverflow: not to be underestimated, it's archival, searchable, etc.

One more tool we do have - live conversations (phone calls, skype, G+,
etc). While these tools are not public, I know we will continue to
use them - our acknowledging this will help us to integrate these into
the public channels better.

> - We try to do a better job of communicating important ideas, questions,
> discussions, etc, on the project lists. Let's encourage our users to do the
> same. We also post key announcements more regularly here. Everyone should
> really feel comfortable

I would add one point:

When private conversations happen the participants post a short
summary to the mailing lists or github. I think that remains one of
the biggest communication challenges we have. Being geographically
isolated from UC Berkeley, I know this first hand from both sides.
There are times that the entire UC Berkeley team assumes Jon and I
know about something when we don't. And I am sure there are times that
Jon and I assume the Berkeley folks know things that we do. I also
have many phone conversations that I don't summarize well to the rest
of the team. In summary, I am as guilty as anyone on our team of not
summarizing private conversations to the rest of the team and
community and I want to work really hard to change this.

>
> - We stop pointing people to gitter as the *first* help stop. We should
> point them to the mailing list (and? OR?) StackOverflow instead. Having a
> non-archival medium be the first point of help means a vast amount of
> duplicated and wasted time helping people.
>
> - The Gitter real-time help room and repo rooms can remain active but we try
> to maintain a discipline of using them only for when folks need the
> real-time collaboration. If key decisions are made here, let's try to have
> a discipline of periodically posting a quick summary, even if it's just a
> very short one, to the mailing list, pointing out what happened. In the
> long run, it will help us all better keep in touch with what the project is
> doing.
>
>
> What other ideas do people have, that can help us better communicate, both
> among project regulars and with the more occasional, broader community
> participants?

I would like to clarify which gitter channels we will use. Our current
set still feels a bit scattered. I would prefer to have one main
channel for each org and then only additional rooms for specific
projects that are very high traffic.

Would does everyone think?

Cheers,

Brian

>
> 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/CAHAreOpGXgRSj1vr8YzV9pdmpXCrZdE-tL%2BeVAV-Kr%2BVe7pkng%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 01:33, Fernando Perez <fpere...@gmail.com> wrote:
>
> The tools at our disposal are:
>
> - Our mailing lists (jupyter & IPython-dev)

> ...

According to our website we also push people toward:

- reddit/r/ipython
- the wiki.

> I don't want to dictate policy here, so I'll propose a rough first draft, to allow for discussion, ideas and fine-tuning:
>
>
> - We try to do a better job of communicating important ideas, questions, discussions, etc, on the project lists. Let's encourage our users to do the same. We also post key announcements more regularly here. Everyone should really feel comfortable

**please** please, try to distinguish one way communication from discussion on the ML.
Announcement are hard to refer to to and google and the ML. Announcement are made for the blog.
If you don’t expect that response are key to communication, use the blog,
you can start a thread **About** a blog post, but [Ann] on ML hurt communication.

>
> - We stop pointing people to gitter as the *first* help stop. We should point them to the mailing list (and? OR?) StackOverflow instead. Having a non-archival medium be the first point of help means a vast amount of duplicated and wasted time helping people.

Yes !!!! I would also appreciate decreasing the number of SO tags.

>
> - The Gitter real-time help room and repo rooms can remain active but we try to maintain a discipline of using them only for when folks need the real-time collaboration. If key decisions are made here, let's try to have a discipline of periodically posting a quick summary, even if it's just a very short one, to the mailing list, pointing out what happened. In the long run, it will help us all better keep in touch with what the project is doing.

Also Yes !

> On Jun 28, 2015, at 08:04, Brian Granger <elli...@gmail.com> wrote:
>
> I would add one point:
>
> When private conversations happen the participants post a short
> summary to the mailing lists or github. I think that remains one of
> the biggest communication challenges we have. Being geographically
> isolated from UC Berkeley, I know this first hand from both sides.
> There are times that the entire UC Berkeley team assumes Jon and I
> know about something when we don't. And I am sure there are times that
> Jon and I assume the Berkeley folks know things that we do. I also
> have many phone conversations that I don't summarize well to the rest
> of the team. In summary, I am as guilty as anyone on our team of not
> summarizing private conversations to the rest of the team and
> community and I want to work really hard to change this.

Yes, same with our dev meetings. Wee should take more notes.

> I would like to clarify which gitter channels we will use. Our current
> set still feels a bit scattered. I would prefer to have one main
> channel for each org and then only additional rooms for specific
> projects that are very high traffic.

We already said in hangout :

ipython/ipython
ipython/ipython/help

Per project if a project deemed it necessary. (like hub as lots of traffic)

+ local privates ones, like the one where we ping each other for lunch, but that’s not relevant is it ?

--
M

[John Schmitt]

The tone of this conversation is great, I admire it. And, excellent selection of tools.

#jupyter et al on freenode would be much preferred over gitter until they get a working two-way IRC bridge.  

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/C5C60801-9092-42A5-B1E4-A27F5ED11193%40gmail.com.

[Matthias Bussonnier]

Hi John,

> On Jun 28, 2015, at 15:06, John Schmitt <marma...@gmail.com> wrote:
>
> The tone of this conversation is great, I admire it. And, excellent selection of tools.
>
> #jupyter et al on freenode would be much preferred over gitter until they get a working two-way IRC bridge.

IPython use to be on IRC, I suppose it is still there, though it was most of the time deserted, and difficult
to access for a newcomer. The lack of even a semi-peristence was also really painful,
hence we moved to hipchat, a few years back, and now to gitter.

I doubt we will move back there, but if there is a way to have an IRC bridge, I guess
that would be nice.

Thanks,
--
Matthias

[Brian Granger]

I know there are still projects that rely heavily on IRC, but in my
mind IRC vs gitter/slack is to online chat like ftp vs Dropbox are to
file sharing. The old technologies had their place, but these days are
difficult to tolerate in our highly web+mobile driven world. However,
if a bridge is easy for a third party to setup and maintain, that
would be fine with me.

> https://groups.google.com/d/msgid/jupyter/CALHvOW4J-kvzpqPSZT0NtD5hdYpT0KtO5GOGhNFZjDMeoyNXxQ%40mail.gmail.com.

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

[Brian Granger]

> **please** please, try to distinguish one way communication from discussion on the ML.
> Announcement are hard to refer to to and google and the ML. Announcement are made for the blog.
> If you don’t expect that response are key to communication, use the blog,
> you can start a thread **About** a blog post, but [Ann] on ML hurt communication.

I view the blog as being reserved for highly curated and copy-edited
content. That content is very time consuming to write and I don't want
to discourage smaller one-way announcements by telling people that
they all need to be blog posts. Also the blog serves a much difference
audience - users - than a development focused mailing list. For
development purposes, I don't see a significant difference between
announcements and 2 ways communications. Here is another metric to use
in deciding what is blog post worthy - do we want to tweet about it.
Most things on the mailing list - even when 1 way - don't pass that
test.

Cheers,

Brian

[Matthias Bussonnier]

> On Jun 29, 2015, at 06:03, Brian Granger <elli...@gmail.com> wrote:
>
> I view the blog as being reserved for highly curated and copy-edited
> content.

I agree, though do you want to improve our communication or not ?
Do you think there is not enough content for one Post per week?

> That content is very time consuming to write and I don't want
> to discourage smaller one-way announcements by telling people that
> they all need to be blog posts.

The question is do you think spending 1h announcing things **correctly**,
is not worth the (potentially) infinite questions we will get after ?

> Also the blog serves a much difference
> audience - users - than a development focused mailing list.

Once again, this depends on the content of the dev meeting, and the things we want to put on the blog.

- Does the fact that we are going to SciPy matters ?
- Does the fact that we split the repo matters ?
- If we have any fundings matters ?

Theses are topics that will touch both user and dev, and that I see us putting on the blog.

The IPython user-ml and dev have been merge **because** the distinction user/dev is blurry.

> For
> development purposes, I don't see a significant difference between
> announcements and 2 ways communications. Here is another metric to use
> in deciding what is blog post worthy - do we want to tweet about it.
> Most things on the mailing list - even when 1 way - don't pass that
> test.

We are starting to write the notebook using phosphor, there is a hydrogen plugin for atom connecting to jupyter,
we are adding things to message spec, tartlets splits into tartlets and widgets tartlets are things I want to tweet about.

But what do actually subscriber on this ML thinks ?

--
M

[Nicolas Riesco]

On 29/06/15 09:11, Matthias Bussonnier wrote:
> But what do actually subscriber on this ML thinks ?

Here are my 2 cents:

I use this ML as the main source for Jupyter. I prefer the ML because:

* I also use ML to get info for other projects (i.e. this is a standard tool).

* I can choose **which** messages and **when** I read them.

* I may miss info from other sources (blog, lab meetings, gitter, ...) because it's not in my routine (including other sources in my routine is a significant investment that at this time I can't justify).

[Maximilian Albert]

I concur with all these points by Nicolas (from the point of view of a non-core-dev who is interested in the project). I do check the blog occasionally, but the ML is certainly the primary medium by which I try to keep up-to-date.

I have not followed the progress on gitter at all (primarily due to time constraints), so I'm not familiar with people's discussion style & workflow there and my next comment may not apply. However, for a project I'm currently involved in we use Slack for coordination and while it's an absolutely invaluable tool we noticed that even with our small team size it can be a huge time sink if the communication is not curated well because everyone felt they had to follow everyone else's discussion in case they may miss something important in the stream of messages. We ended up moving most of the discussions into private (or small-group) chats and now have an "updates" channel where we post the outcomes of our discussions, as well as brief intermediate status reports on our work, on a regular basis (once per day, or more frequently if needed). This is very effective to disperse information that affects other people but which may not be in a state ready for a ML announcement (and also takes much less time to write because it doesn't need to be formal).

Generally, my impression of this discussion is that it's a question of how to deal with the different scales in the hierarchy, from mundane day-to-day development / discussions with fellow core devs all the way up to the big, important decisions and announcements. It feels a bit as if people are trying to find the "perfect" medium for each level of discussion/announcement, but IMHO the most important thing is that there is toolchain which *allows* for easy and effective communication on each of these levels. I guess the hierarchy of tools could be:

   Gitter (or equivalent)  <  "Update" channel on Gitter  <  ML  <  Blog

Discussions should take place at the smallest level appropriate (and in groups as small as possible to minimise the traffic for everyone who doesn't need to be involved). Once the discussion/insights reach a certain level of maturity they can percolate up the chain, and any interested outsider (or fellow dev) can choose the level of granularity at which to follow the progress. I also think it should be perfectly fine to cross-post on these channels, e.g. copy & paste a "gitter update" announcement to the mailing list, even if it's not very polished. (However, the blog is probably a different matter since it should be more curated as Brian pointed out.) But the important thing is that communication flows from bottom to top so that it's clear at which level to tune in, depending on how involved one wants to be.

Hmm, thinking about it, it seems that the biggest challenge is to define such a hierarchy - or rather, a "Directed Acyclic Graph of Communcation Tools". ;-) Especially when other tools like Github issues and StackOverflow questions come into play. However, the latter appear to live somewhere in the space of personal/small-group communications towards the bottom of the chain, so maybe it's fine to keep them there and only draw other people into the discussion (or post updates in an appropriate channel) if more input is required and/or insights should be disseminated more widely.

On that note, how do IPython/Jupyter devs currently deal with Github issues and user questions on Gitter/StackOverflow? Does everyone read and comment on all of them? If that's the case, could it be appropriate to dedicate 1-2 persons to the role of curating these channels (maybe on a weekly rotation), and these people would ping the appropriate developer if their input is needed? This may free up time for the other devs so that they can focus on their work and don't need to watch all communication channels all the time.

Anyway, just my 3 cents (this turned into a much longer brainstorm than I had anticipated). Again, none of this may be appropriate to how the Jupyter team works, so please ignore anything I said if it doesn't apply. Just thought I'd give my impression from the point of view of an interested outsider.

Best wishes,

Max

[Wes Turner]

That makes sense. Links to docs, sources, issues?

Someone could get all of these IPython/Jupyter link patterns together? https://westurner.org/wiki/ideas#open-source-mailing-list-extractor (and then make vague references to documentation and issues #3 with no links)?

These are all valued channels with different searchability; and linking with URIs.

>
> Cheers,
>
> Brian
>
> >
> > 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/CAHAreOpGXgRSj1vr8YzV9pdmpXCrZdE-tL%2BeVAV-Kr%2BVe7pkng%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

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

[Fernando Perez]

On Mon, Jun 29, 2015 at 1:11 AM, Matthias Bussonnier <bussonnie...@gmail.com> wrote:

I agree, though do you want to improve our communication or not ?

I'd like to invite you to consider perhaps a different way of tackling this question: I think it should go without saying that we all want to improve our communications.  Posing a question in this fashion is effectively questioning our good faith in the project...

The issue, instead, is that while we are trying to improve our communications, we're doing so within very limited constraints.  So we're trying to find a good balance of time, resources and effectiveness.

Regarding the blog, I'm absolutely sure that we do produce enough interesting work for more than one great post per week.  But I'm not sure that right now we have the time and energy to *write* that post.

And I do know that we may at least be able to write a less-polished, but still-useful ML post that summarizes the state of things.  I know that, in the past, I've made a lot of long-ish posts on our MLs that over the years have become referenced many times, and in a better world would actually be blog posts.  But I did them only as ML posts, simply due to lack of time... For example, the one about the early days of the notebook was long and detailed enough that eventually I managed to *rewrite* it as a blog post:

http://blog.fperez.org/2012/01/ipython-notebook-historical.html

but that almost never happens simply b/c I don't have the time.

So, as Min tactfully and kindly said above, I'd like to reiterate a request for a bit of patience: we're all trying to do our best, and we're going into this with our best effort under tight constraints.

Cheers,

[Fernando Perez]

On Mon, Jun 29, 2015 at 3:40 AM, Maximilian Albert <maximili...@gmail.com> wrote:

   Gitter (or equivalent)  <  "Update" channel on Gitter  <  ML  <  Blog

Max, thanks for this very thoughtful reply!

I think, in the interest of trying to reduce a bit our gitter activity and given that our ML load right now isn't too large, we may go for now with the notion of putting these updates just on the ML, but we can always revisit this idea of an "updates channel" later on if needed.

Cheers,

[Fernando Perez]

OK, let me try to wrap up this discussion so we can move forward.  I know Matthias has, rightfully, complained about the fact that sometimes we start long discussions that fizzle out without a concrete set of actionable decisions.  That is very much my fault, so let me try to remedy that ;)

- When conversations happen over "fast" channels, or even more importantly, private ones (phone, skype, etc), once a decision is made, please take the time to report back to the project by posting a quick summary on the Jupyter ML (or if it's really very IPython-specific, on the IPython-dev one).   

Let's try to all develop a discipline of doing this: it doesn't need to take too much time, these don't need to be highly polished and curated, just "hey, we figured X out, we solved Y, we're doing Z, here are the relevant links".

It will do us a *lot* of good in the long run in terms of building back a lot of common connective tissue regarding a shared understanding of the project our decisions, etc.

- On help: let's demote our ipython/help gitter room by *delisting it* completely from the website.  The room can continue to exist in case we want to explicitly use it at some point in time to invite a specific user for real-time help, but it shouldn't be the first place we point people for help.

Instead, let's use StackOverflow as our main help venue for newcomers.  It will help reduce the email burden on the core team, it has a non-overlapping community that also helps and answers questions there so we get good support from others, and it's easy to remove the IPython/Jupyter tags for non-appropriate questions (easier than telling someone their question should go elsewhere by email).

- On Gitter:  let's only have the following main rooms listed/findable from the website:

1. ipython/ipython: the equivalent of ipython-dev ML on gitter, it's the main public "project room" for IPython.

2. jupyter/jupyter: equivalent of jupyter ML on gitter, main public project room for Jupyter.

As for other repo rooms and channels we have, they can be used by the individuals who are working on those topics as needed at their discretion, but 

a) they know who they are, we assume they go there from github or from the main rooms

b) they will be mindful of pulling back to the ML with summaries of anything important that happens.

- The blog: we'll obviously do our best to improve our blogging frequency.   But we'll combine that with lightweight, informal-but-informative posts to the ML that at least provide "signposts" of activity that can serve our community.

Thanks everyone for this discussion! And, I do apologize for having been somewhat absent in the last few months in more regular communications...  Trying to do better...

Did I miss anything?

Cheers,

f

[Thomas Kluyver]

On 29 June 2015 at 03:40, Maximilian Albert <maximili...@gmail.com> wrote:

On that note, how do IPython/Jupyter devs currently deal with Github issues and user questions on Gitter/StackOverflow? Does everyone read and comment on all of them? If that's the case, could it be appropriate to dedicate 1-2 persons to the role of curating these channels (maybe on a weekly rotation), and these people would ping the appropriate developer if their input is needed? This may free up time for the other devs so that they can focus on their work and don't need to watch all communication channels all the time.

There are certain topics where we'll ping a particular developer to answer things - if I see a question about IPython.parallel, I'll bring it to Min's attention. But we don't do this systematically for every question, in part because for most of them it's not always clear who can answer it best. Or we're embarrassed about the fact that 75% of the time Min can answer it best. ;-)

On Github, most of the core developers see most of the issues (now, I think we've mostly unsubscribed from a couple of repos each, so it's no longer all of them). Matthias and I check Stackoverflow for questions fairly regularly, and the community is also quite active in helping there (thanks, everyone who lends a hand with that!). Gitter is the least reliable medium for questions - messages can easily be buried by newer messages, and we often don't bother responding to messages more than a couple of hours old, because we don't know if the asker is still in the room.

Thanks,

Thomas

[Scott Sanderson]

+1 for posting short write-ups of Gitter conversations.  I wrote up and example of what I think would be helpful both as a user and as a sometimes developer here: https://groups.google.com/forum/#!topic/jupyter/COhsW7rZgLc.  

The basic format of the post is:

1. Here's the problem I have.
2. Here's my current best solution
3. Here's what's good/bad about the current solution.

Having a clear problem and solution statement is useful users who come along later trying to solve the same problem.  Having a review of the strengths and weaknesses of the solution helps developers better understand what the current strong/weak points are in the existing APIs.

Hope this is helpful,

- Scott

[Matthias Bussonnier]

Bunch of responses, Apology for delay. 

In general, thanks for everyone for saying how the see/use ML/blog, it is helpful. 

On Jun 29, 2015, at 03:40, Maximilian Albert <maximili...@gmail.com> wrote:

On that note, how do IPython/Jupyter devs currently deal with Github issues and user questions on Gitter/StackOverflow? Does everyone read and comment on all of them? If that's the case, could it be appropriate to dedicate 1-2 persons to the role of curating these channels (maybe on a weekly rotation), and these people would ping the appropriate developer if their input is needed? This may free up time for the other devs so that they can focus on their work and don't need to watch all communication channels all the time.

I’m subscribed to all IPython-* related tags on SO (except parallel), so Thomas is I thing [edit] Yes seeing later response[/edit]

Assigning people on a per week basis is not viable, as we all have our expertise (except Min that know all), 

and pinging on SO is painful. It would be nice to have a technical, not forcibly developer to do that. 

One of the “problem” is if you respond too late, another wrong answer might be put up there first.

Also SO might not be fit for actually debugging/discusstion. But you can redirect people to GitHub, which I did a few time. 

I’m amazed on how people often don’t realize we are the same people. 

I actually had a ”Thank you Bro’ “ on SO, and a long thanks on GitHub from the same user/same question.

There is also an awful lot of question tagged IPython on So that are unrelated to IPython. 

On Jun 29, 2015, at 15:16, Fernando Perez <fpere...@gmail.com> wrote:

On Mon, Jun 29, 2015 at 1:11 AM, Matthias Bussonnier <bussonnie...@gmail.com> wrote:

I agree, though do you want to improve our communication or not ?

I'd like to invite you to consider perhaps a different way of tackling this question: I think it should go without saying that we all want to improve our communications.  Posing a question in this fashion is effectively questioning our good faith in the project...

Sorry it is not the meaning I want to convey, I’m probably lacking nuances on how to express that in English. 

Apologize if it was read os offensive. 

On Jun 29, 2015, at 20:18, Fernando Perez <fpere...@gmail.com> wrote:

[...]

Instead, let's use StackOverflow as our main help venue for newcomers.  It will help reduce the email burden on the core team, it has a non-overlapping community that also helps and answers questions there so we get good support from others, and it's easy to remove the IPython/Jupyter tags for non-appropriate questions (easier than telling someone their question should go elsewhere by email).

Just one point that we encourage people from ML to also participate, and we want to remind that being part of the

core team does not only mean contributing code. Someone we see often enough responding to questions or helping

with constructive input and feedback would gladly be integrated into the core team. 

Finally if someone wrote a recap or something that you think is worth posting on blog (IPython weekly ?) 

feel free to contact us. I would love to see (Maybe not weekly, but monthly) 

I in particular appreciate [1] (french), which is a permanently open collaborative edititing of “whats new in linux kernel X.yz”, 

which is turned into a Blog post on Kernel release.  

On Jun 29, 2015, at 20:23, Thomas Kluyver <tak...@gmail.com> wrote:

On 29 June 2015 at 03:40, Maximilian Albert <maximili...@gmail.com> wrote:

On that note, how do IPython/Jupyter devs currently deal with Github issues and user questions on Gitter/StackOverflow? Does everyone read and comment on all of them? If that's the case, could it be appropriate to dedicate 1-2 persons to the role of curating these channels (maybe on a weekly rotation), and these people would ping the appropriate developer if their input is needed? This may free up time for the other devs so that they can focus on their work and don't need to watch all communication channels all the time.

There are certain topics where we'll ping a particular developer to answer things - if I see a question about IPython.parallel, I'll bring it to Min's attention. But we don't do this systematically for every question, in part because for most of them it's not always clear who can answer it best. Or we're embarrassed about the fact that 75% of the time Min can answer it best. ;-)

On Github, most of the core developers see most of the issues (now, I think we've mostly unsubscribed from a couple of repos each, so it's no longer all of them). Matthias and I check Stackoverflow for questions fairly regularly, and the community is also quite active in helping there (thanks, everyone who lends a hand with that!). Gitter is the least reliable medium for questions - messages can easily be buried by newer messages, and we often don't bother responding to messages more than a couple of hours old, because we don't know if the asker is still in the room.

I also try to check twitter for IPython and Jupyter hashtag and plain search (Ignoring people asking question on 3 mediums at a time though), 

and respond/correct point people to resources. Though 140c is not a lot. 

-- 

M

[1]: https://linuxfr.org/news/sortie-du-noyau-linux-3-18

[Fernando Perez]

On Mon, Jun 29, 2015 at 10:18 PM, Steve Holden <st...@holdenweb.com> wrote:

Those with long memories may remember the monthly "python-dev summaries".

While these posts were interesting and useful, they inevitably became a burden for their individual authors as mailing volume grew.

From a purely personal point of view I'd rather take what you say on good faith and try to find some way of reporting progress that doesn't distract developers form their primary goal of, rem, developing.

Thanks for the cautionary tale from hard-won experience, Steve.

Indeed, we dont' want to turn this into a burden for anyone...

I'm thinking simply of something where, if a discussion went on for hours and reached an important conclusion, the acting parties take only a few minutes to make a quick recap and post a light summary of it, no more, to the list to keep the rest of us in the loop.

I think it's not much to ask, and it's important so that we don't lose that common weave of community knowledge of what's happening across the project.  But it's indeed critical that we don't set a bar so high that it becomes burdensome.

I know far too well how on these kinds of things, the perfect is the enemy of the good, so we're going to keep the bar low: basic info, links that provide context to be useful and that help us weave the fabric of knowledge, and that keep the burden as minimal as absolutely possible.

[Matthias Bussonnier]

Hi all, 

This morning meeting was great, much more efficient than usual. 

the recap is on ipython.hackpad.com. 

We’ll curate it a bit and post it on the ML. 

We’ll also post the video at some point. 

You can of course jump on the hackpad now and help curate a bit, fix typos and links, 

ask precisions of what’s unclear. 

Thanks. 

-- 

M

On Jun 30, 2015, at 12:45, Steve Holden <st...@holdenweb.com> wrote:

On Jun 30, 2015, at 7:40 PM, Fernando Perez <fpere...@gmail.com> wrote:

I'm thinking simply of something where, if a discussion went on for hours and reached an important conclusion, the acting parties take only a few minutes to make a quick recap and post a light summary of it, no more, to the list to keep the rest of us in the loop.

That sounds like a really sensible use of time. Best immediately after the meeting, as otherwise the un-performed task can be a burden. It would probably only mean people scheduling 1:15 for the meeting instead of 1:00, just to make sure commitments and important decisions were recorded.

I think it's not much to ask, and it's important so that we don't lose that common weave of community knowledge of what's happening across the project.  But it's indeed critical that we don't set a bar so high that it becomes burdensome.

I think we are in violent agreement :)

I know far too well how on these kinds of things, the perfect is the enemy of the good, so we're going to keep the bar low: basic info, links that provide context to be useful and that help us weave the fabric of knowledge, and that keep the burden as minimal as absolutely possible.

Right. Quit apart from anything else,

a) Many hands make light work, and

b) Nobody wants to join a project with a reputation for becoming a millstone around people's necks :-)

Cheers,

f

Always great to hear from you.

S

-- 

Steve Holden st...@holdenweb.com / +1 571 484 6266 / +44 208 289 6308 / @holdenweb

[Fernando Perez]

On Tue, Jun 30, 2015 at 8:27 AM, Matthias Bussonnier <bussonnie...@gmail.com> wrote:

Assigning people on a per week basis is not viable

I meant assigning to take notes.  At this point I hardly know any of the codebase, but I did my best to keep up with the note taking, and I actually found it quite informative and learned a lot.  Hopefully that shows by proof of existence that it is indeed viable, and that perhaps others can follow in the coming weeks...

As long as we all pitch in together to provide notes, and especially if we "prime" the hackpad in advance with a bit of what we've done prior to the meeting, the note-taking can be very light duty and we'll have some very useful information for the whole project with minimal effort on any one individual's back.

Cheers,

[Luiz Irber]

Gitter has an IRC bridge: irc.gitter.im for more info.

--
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/77A08D66-6936-4A88-B269-9F2C2D5D4F58%40gmail.com.

[Matthias Bussonnier]

On Jun 28, 2015, at 08:22, Luiz Irber <luiz....@gmail.com> wrote:

Gitter has an IRC bridge: irc.gitter.im for more info.

Thanks for the tip. It still need some setup to work though...

-- 

M

[Brian Granger]

I have opened a PR to remove the ipython/help room from the sidebar of the page.

https://github.com/ipython/ipython-website/pull/92

Here is the jupyter/jupyter room to use as the main gitter channel for
all jupyter things:

https://gitter.im/jupyter/jupyter

Cheers,

Brian

> --
> 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/E154EDCD-7A22-4A80-B820-4F811D968BC4%40gmail.com.

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

[Brian Granger]

gitter channels can now be deleted:

https://github.com/gitterHQ/gitter/issues/218

To help consolidate around the rooms Fernando has decided that we will
use, I proposed we delete the following rooms:

ipython - a private room we don't use
jupyter - a private room we don't use
ipython/help - we have already decided to stop using it. I can't think
of any situations where our main channels can't be used.
jupyter/nbgrader - low traffic, we can use the main jupyter/jupyter channel

Also, Kyle, do you think we can delete ipython/docker-notebook and
move those discussions to jupyter/jupyter?

[Kyle Kelley]

> do you think we can delete ipython/docker-notebook and move those discussions to jupyter/jupyter

Yes please.

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

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

--

Kyle Kelley (@rgbkrk; lambdaops.com, developer.rackspace.com)

[Thomas Kluyver]

On 1 July 2015 at 10:43, Brian Granger <elli...@gmail.com> wrote:

gitter channels can now be deleted:

Excellent. Though from the screenshot they provide, deleting a room also deletes all its history, so we shouldn't create and delete rooms too frequently. I'm fine with doing it now, though - the history is not especially useful in any case.

 

ipython/help - we have already decided to stop using it. I can't think
of any situations where our main channels can't be used.

I think I'd leave one 'help' channel in existence, but not advertised, so that if we need to debug a problem with people in real time, we can send them there, rather than to a room where there might be development discussion going on or to a private conversation where others can't jump in and help. But I don't feel strongly about this.

Thomas

[Fernando Perez]

On Wed, Jul 1, 2015 at 10:49 AM, Thomas Kluyver <tak...@gmail.com> wrote:

I think I'd leave one 'help' channel in existence, but not advertised, so that if we need to debug a problem with people in real time, we can send them there, rather than to a room where there might be development discussion going on or to a private conversation where others can't jump in and help. But I don't feel strongly about this.

Yes, I think we said we'd leave the help room unadvertised, but not destroyed. More as a physical room that can be used as needed to bring someone over for a one-on-one debugging session that requires manual support.

So I suggest not destroying that one, but just not pointing anyone there from any visible point on the websites. It's just a resource we can use when required, but only when a *human* is ready to make use of it.

Otherwise, big +1 to the room cleanup, happy to see it!

[Brian Granger]

Sounds good, I will delete ipython and jupyter, but leave
ipython/help. I also deleted the docker-notebook one at Kyle's
request.

> --
> 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/CAHAreOo%2B6%3DzOQwLXiXB4QWrnzZ8vSDCCr9njLRHo7kRpE8cEXg%40mail.gmail.com.

[Brian Granger]

Just thinking - now that gitter rooms can be deleted, I think it might
make sense to regard all of our gitter channels in the same way we do
notebooks on tmpnb - they are transient and non-persistent, so always
make sure valuable information is recorded elsewhere. This will also
allow us to evolve the gitter channels quickly and easily as the
project evolves. I am not really suggesting any concrete changes at
this point, just a shift in how we think about gitter.

[Fernando Perez]

Good point, though I'd add a twist to that: we should look into some mechanism to auto-log their data on the side. Perhaps we can simply commit their logs to a repo somewhere in a semi-automated fashion...

There's data of historical value in there that I would really not like to lose.  We actually have people at Berkeley doing scholarship on the history and sociology of science of these communities, and they treat these as primary data of real value.  They have taught me to be much more mindful of its value.

Cheers

f

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

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

--

[Jessica B. Hamrick]

Hi all,

Yep, sounds good to me, and I'm happy to use the jupyter/jupyter room for nbgrader discussions.

Cheers,

Jess

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

[Brian Granger]

Yep, I think there is definitely value to the data, even if we treat
it as transient for communication purposes.

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

[Brian Granger]

OK great, thanks!

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

[Brian Granger]

Oh, just found another low traffic channel that could be replaced by
jupyter/jupyter: jupyter/design.

What do people think of deleting jupyter/design?

[Fernando Perez]

ok with me...

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

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

[Matthias Bussonnier]

> On Jul 1, 2015, at 10:59, Brian Granger <elli...@gmail.com> wrote:
>
> Sounds good, I will delete ipython and jupyter, but leave
> ipython/help. I also deleted the docker-notebook one at Kyle's
> request.
>

Couldn’t you have just Kicked everyone out ?
Now the history is gone...
--
M

> To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/CAH4pYpRTLLNUqn%3DZVrdu7%2BLJqLgsciPM%3D_aSaEWd-KZ-QOx%3DSg%40mail.gmail.com.

[Matthias Bussonnier]

> On Jul 1, 2015, at 10:43, Brian Granger <elli...@gmail.com> wrote:
>
> gitter channels can now be deleted:
>
> https://github.com/gitterHQ/gitter/issues/218
>
> To help consolidate around the rooms Fernando has decided that we will
> use, I proposed we delete the following rooms:
>
> ipython - a private room we don't use

And sorry but the IPython private room was used.
I’m a bit sad that things happened so fast that you almost don’t have time to respond.

Anyway, not too important.

--
M

[Brian Granger]

I thought we decided to use juypter/steering instead of the private
ipython and jupyter rooms? I agree with the previous sentiment that it
is a good idea to have as few private rooms as possible.

> --
> 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/D6DF503D-B4D0-4D5F-8BCF-F5697E75BE27%40gmail.com.

[Matthias Bussonnier]

> On Jul 1, 2015, at 12:54, Brian Granger <elli...@gmail.com> wrote:
>
> I thought we decided to use juypter/steering instead of the private
> ipython and jupyter rooms? I agree with the previous sentiment that it
> is a good idea to have as few private rooms as possible.

My Bad then,

though:

1) I can’t seem to access, nor see jupyter_steering anymore.
2) j/steering is much more restrictive than /jupyter as it should be mostly for steering council.
3) it is invitation only, while /jupyter or /ipython is immediately all members of the org. Who will take care of managing ?
4) Why move to steering if it was almost unused, while people where actually using another room ?

--
M

> To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/CAH4pYpQVWV6zJn276S37NR8-imcOnbrR_pzFk%3DTxsx4kB7sX7g%40mail.gmail.com.

[Matthias Bussonnier]

Also a reminder.

> On Jul 1, 2015, at 12:54, Brian Granger <elli...@gmail.com> wrote:
>

> I thought we decided to use juypter/steering instead of the private
> ipython and jupyter rooms? I agree with the previous sentiment that it
> is a good idea to have as few private rooms as possible.

>>> import this

...
Now is better than never.
Although never is often better than *right* now.
...


--
M

[Brian Granger]

> My Bad then,
>
> though:
>
> 1) I can’t seem to access, nor see jupyter_steering anymore.

Hmm, that is weird, I just looked and you were not on that channel. I
just added you back.

> 2) j/steering is much more restrictive than /jupyter as it should be mostly for steering council.
> 3) it is invitation only, while /jupyter or /ipython is immediately all members of the org. Who will take care of managing ?
> 4) Why move to steering if it was almost unused, while people where actually using another room ?

It was my understanding that that movement away from the private
ipython and jupyter channels is that we were starting to have
conversations there that really should have been public - we were
using them be defacto, rather than because they were private. By
closing those down, it sends a strong message that we want as many
communications as possible to be public - and when they can't, they
should rise to the level of being steering council scoped. That isn't
to say we won't ever have other private communications, but that we
want the default to be public.

The invititations for the jupyter/steering channel would be managed by
the current members of the steering council as more people join the
council.

Cheers,

Brian

> To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/A1862D4E-8118-4FC9-80D2-838954EA7B55%40gmail.com.

[Damián Avila]

People, can we make a summary of the channel available right now?? I feel that with the long thread is still confuse. 

I will attempt a summary proposal, please correct me if I am wrong...

Main ones:

* ipython/ipython

* jupyter/jupyter

Additionally, if someone needs to go further with the help without bothering the main ones:

* ipython/ipython/help: are we sure, we want it named "help"? that confuse people looking for "help", making more difficult to lower activity there...

maybe a hard-switch/delete is better in this case, to clean the space... I mean, I think the space is valuable for one-to-many-devs help (if it is needed), but the name is a problem from my point of view...  

Specific devs discussions:

* jupyter/jupyterhub

* jupyter/notebook

* jupyter/nbviewer

* at discretion if enough people develop in one specific part enough to be a separate space...

Finally:

* jupyter/steering

Am I missing something?

Cheers.

To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/CAH4pYpTZT50MPnpGa9gQ20AGhm-jaq%2BSXfsdh7v%2BocPGOcGJ8A%40mail.gmail.com.

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

--

Damián Avila

[Thomas Kluyver]

On 5 July 2015 at 14:53, Damián Avila <damia...@gmail.com> wrote:

Am I missing something?

I don't think so. Except for ipython/danger_zone ;-)

[Damián Avila]

>Except for ipython/danger_zone ;-)

My bad, how I lost that one!! Je...

--

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/CAOvn4qh8qJ-bWpgqM_ZD6wUu%3DnOAHRS6LjdHW3DP1D9b%3DcJEqA%40mail.gmail.com.

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

--

Damián Avila