Notebook/Lab team structure (while we finalize the rest)

[Fernando Perez]

Hi all,

we've had discussions since the last dev meeting about organizing the project into more well-defined teams for each major area, since we're well past the point where "everyone does everything" can remotely work.

While we're still settling down on some details, I think on the Notebook/JupyterLab area, the most complex piece of development we have going on right now, we should socialize/finalize this sooner rather than later.  I *think* there was reasonable agreement from earlier discussions on the plan that having a joint lead structure with Brian, Jason and Matthias working together would be the best approach here. While Brian and Jason have been focused on Lab, Matthias has kept more of his attention on the "classic" Nb.  

This effort is large and carries the special challenge of finding what the right "sunset" path is for the classic Nb while Lab matures and becomes a complete, no-compromise replacement.  A team of three with overlapping expertise across the two codebases seems like a good solution.

In order to help that entire team settle into a good routine for planning and decision making, I think it's key that we come to agreement on this.  If anyone has further thoughts, by all mean pitch in (or we can discuss it at the JLab meeting tomorrow).

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]

On Fri, Oct 21, 2016 at 8:57 AM, Fernando Perez <fpere...@gmail.com> wrote:

Hi all,

we've had discussions since the last dev meeting about organizing the project into more well-defined teams for each major area, since we're well past the point where "everyone does everything" can remotely work.

While we're still settling down on some details, I think on the Notebook/JupyterLab area, the most complex piece of development we have going on right now, we should socialize/finalize this sooner rather than later.  I *think* there was reasonable agreement from earlier discussions on the plan that having a joint lead structure with Brian, Jason and Matthias working together would be the best approach here. While Brian and Jason have been focused on Lab, Matthias has kept more of his attention on the "classic" Nb.  

This effort is large and carries the special challenge of finding what the right "sunset" path is for the classic Nb while Lab matures and becomes a complete, no-compromise replacement.  A team of three with overlapping expertise across the two codebases seems like a good solution.

In order to help that entire team settle into a good routine for planning and decision making, I think it's key that we come to agreement on this.  If anyone has further thoughts, by all mean pitch in (or we can discuss it at the JLab meeting tomorrow).

This sounds like a good plan to me, and I'm happy with Brian, Jason and Matthias. The main question for me (at least in terms of where I spend my time) is the notebook server vs split-off jupyter-server project. I've been implementing some long-awaited new things in the notebook server (login tokens, activity tracking), but much further development in that repo is going to be a pain for the new server to keep in sync with. I would like to have a plan for how/when to stop development on the server-side of the notebook application, which is still providing the server-side component of JupyterLab. I would like to participate in that side of the conversation, and I imagine Sylvain would, as well.

-Min

 

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+unsubscribe@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/CAHAreOqvUKGhKxBYKCx04fyDGigJueK59tLx_zZugqbGXH_nQQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Jason Grout]

On Tue, Oct 25, 2016 at 8:03 AM MinRK <benja...@gmail.com> wrote:

This sounds like a good plan to me, and I'm happy with Brian, Jason and Matthias. The main question for me (at least in terms of where I spend my time) is the notebook server vs split-off jupyter-server project. I've been implementing some long-awaited new things in the notebook server (login tokens, activity tracking), but much further development in that repo is going to be a pain for the new server to keep in sync with. I would like to have a plan for how/when to stop development on the server-side of the notebook application, which is still providing the server-side component of JupyterLab. I would like to participate in that side of the conversation, and I imagine Sylvain would, as well.

Good question. Sylvain has worked quite a bit on this on https://github.com/jupyter/jupyter_server/pull/1. Sylvain, what is the status? I know you've been tackling the problem of the extension mechanism - should we push forward (i.e., have discussion/implementation) of the extension mechanism at the dev meeting in two weeks?

Thanks,

Jason

[Sylvain Corlay]

Hi Everyone,

I put the jupyter server on the back burner as I had major presentations at strata, the european commission and a couple of other things to prepare. Although I will put some cycles into this thing starting tomorrow.

One of the main motivation for the split was to be able to start from a clean state in terms of the mechanism that we will put in place wrt the extension mechanism.

I am fine rebasing my work on the top of the latest features of the notebook wrt token authentication etc. I agree that they are part of the general jupyter server side.

In fact, I am not too worried about work done on the notebook repo that would need to be repeated in the jupyter server repo. The reason is that most of the issues open in the notebook repo are related to the notebook  front ende. (The token authentication thing that was merged recently is a bit of an outlier). The resulting repository is actually very small, and should be, hopefully, simpler to maintain.

Sylvain