Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Proposal to move dashboard deployment repos to attic #22

Merged
merged 2 commits into from
Sep 11, 2017
Merged

Proposal to move dashboard deployment repos to attic #22

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
9e389bc
Proposal to move dashboard deployment repos to attic
parente Sep 3, 2017
8aefe9c
Clarify "user success" statement
parente Sep 4, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
63 changes: 63 additions & 0 deletions jupyter-dashboards-deployment-attic/jupyter-dashboards-deployment-attic.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,63 @@
# Proposal to Move the Jupyter Dashboards Deployment Projects from Incubator to Attic

## Problem

Jupyter users want to publish their work outside of their notebook authoring environment in a variety of formats. One such format is that of a standalone, interactive dashboard. We started the dashboards bundler and dashboards server projects to address this desire. The projects, collectively referred to as *dashboard deployment* hereafter, underwent significant development effort from late-2015 to mid-2016. Development has since stagnated.

## Proposal

We should clearly signal to the broader community that work on the dashboard deployment incubator projects has effectively ceased by moving the following repositories to the [jupyter-attic organization on GitHub](https://github.com/jupyter-attic):

* https://github.com/jupyter-incubator/dashboards_server
* https://github.com/jupyter-incubator/dashboards_bundlers
* https://github.com/jupyter-incubator/dashboards_setup
* https://github.com/jupyter-incubator/showcase
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I approved, however we could mark the projects as archived instead (note: individuals on the project would need to join https://maintainers.github.com). That makes them read-only (however, we could both move them and mark as "archived').

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I plan to move them to attic first. Then we can see how archive works on them.


We should use the remainder of this document to capture:

1. Why the projects should move to the attic according to our governance criteria
2. Lessons learned from the incubation effort
3. Ideas for what to do next with respect to Jupyter and dashboards

## Why the attic?

The [Jupyter Governance - New Subproject Process](https://github.com/jupyter/governance/blob/master/newsubprojects.md) lists eight criteria used to evaluate projects for incorporation into one of the official Jupyter organizations. The dashboard deployment projects have been failing to meet at least five of these criteria for some time.

#### Have an active developer community that offers a sustainable model for future development.

Members of the original development team have moved on from the project for a variety of reasons. While developers from the broader Jupyter community have opened a handful of pull requests (PRs) over the past year, there are no active maintainers who review PRs, respond to issues, upgrade components, maintain compatibility with other Jupyter projects, write documentation, fix failing tests, and so on.

#### Have an active user community.

There is [certainly user interest](https://github.com/jupyter-incubator/dashboards_server/issues/319) in a dashboard deployment solution for Jupyter notebooks. However, users who have tried the deployment projects [have met with limited success](https://github.com/jupyter-incubator/dashboards_server/issues) given the current complexity of [running the full project stack](https://github.com/jupyter/dashboards/wiki#get-started) due to lack of work on making it easier over the past year.

#### Demonstrate continued growth and development.

Development of new features has ceased. The original project roadmap ends at the current feature set and calls for work to continue on ["how dashboarding features materialize in JupyterLab."](https://github.com/jupyter/dashboards/wiki/Deployment-Roadmap#may-2016-update).

#### Integrate well with other official Subprojects.

The [dashboards layout extension](https://github.com/jupyter/dashboards) defines a [notebook metadata format](http://jupyter-dashboards-layout.readthedocs.io/en/latest/metadata.html) and uses it to persist information about on-screen notebook cell arrangements. The dashboard deployment projects depend on this metadata. No other Jupyter projects support it.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you also propose to move the layout extension to attic?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No. That project is out of the incubator, has a more well-defined scope, and is much more stable and amenable to maintenance. While its metadata format is not supported by any other Jupyter projects, it does serve as a point of reference for a common layout spec in the future.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But then this isn't an argument for the dashboards server failing to integrate with other projects. Or am I missing something?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant it more of an observation that the dashboard server does "integrate" with the dashboard layout project. The final sentence "No other Jupyter projects support it" was meant more as a clarifying editorial and I should put it in parentheses.

That said, you are right that the rest of the observations made in this section are evidence for putting the deployment projects in the attic, and perhaps I should cut this paragraph out.


Conversely, the dashboard deployment projects use ipywidgets and various JupyterLab components for interactivity and rendering. These two libraries have undergone major development over the past year as they've matured. The dashboard deployment projects have not kept pace, and currently rely on [back-level versions](https://github.com/jupyter-incubator/dashboards_server/blob/master/package.json#L48).

#### Have a well-defined scope.

The [dashboards incubator proposal](https://github.com/jupyter-incubator/proposals/blob/master/dashboards/proposal.md#scope) includes a section concerning project scope. The stated objective of "establish[ing] a baseline prototype that demonstrates how notebook authors can publish dashboards" is not, however, clearly documented outside the proposal nor refined in response to [evolving technical constraints](https://github.com/jupyter-incubator/dashboards_server/issues/302). Users are left guessing about the scope of "dashboard deployment" supported by the projects.

## What did we learn?

Briefly:

* The Jupyter community has a [variety of perspectives](https://github.com/jupyterlab/jupyterlab/issues/1640) on what a "dashboard" is, whether a dashboard is really the desired artifact for many use cases, how Jupyter users want to author dashboards, what "deploying" a dashboard means, and so on. Having a discussion and coming to some form of consensus on where to focus effort seems prudent.
* The ability to write any notebook and deploy it anywhere as an interactive web app is too large an undertaking. Constraints on what libraries are supported and how much of the deployment is automated are necessary to set user expectations, manage project scope, and leave room for third-parties to develop solutions atop common specs.
* We need to clearly note when projects in the incubator are experimental and we are not certain they will succeed.

## What might we do next?

The following list consolidates ideas proposed across various projects. The list is most certainly non-exhaustive.

* We should [continue the discussion about what the community wants to see in JupyterLab](https://github.com/jupyterlab/jupyterlab/issues/1640) with respect to dashboards and other notebook presentation formats.
* We could [collaborate on a Jupyter nbformat spec](https://github.com/jupyterlab/jupyterlab/issues/1640#issuecomment-291883316) about how notebook documents should persist layout information in hopes of spurring development of multiple tools that use it.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A+, specs are the right way forward

* We could create a [new user survey](https://github.com/jupyter/surveys) to gather information about how dashboard deployment, or, more broadly, notebook publication, fits into Jupyter-user workflows today and to solicit feedback on initial design choices.
* We could [change stance on security in the jupyter/dashboard project](https://github.com/jupyter/dashboards/issues/279), and let the layout extension create the semblance of deployed dashboards in Jupyter Notebook by modifying the notebook interface and automatically executing trusted notebooks when opened.