Proposal to move dashboard deployment repos to attic #22
Conversation
parente
requested review from
ellisonbg,
fperez,
jhamrick,
ivanov,
minrk,
jasongrout,
takluyver,
Carreau,
rgbkrk,
damianavila,
blink1073,
SylvainCorlay,
willingc and
jdfreder
| * 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 |
There was a problem hiding this comment.
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').
There was a problem hiding this comment.
I plan to move them to attic first. Then we can see how archive works on them.
|
|
||
| #### 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). |
There was a problem hiding this comment.
I'm not sure if the issue list indicates the limited user success rather than lack of development. Likewise the complexity isn't larger than that of jupyterhub.
There was a problem hiding this comment.
Yes. I will clarify: "...given the current complexity of running the full project stack due to lack of resources invested in making it simpler."
| 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. |
There was a problem hiding this comment.
A+, specs are the right way forward
|
|
||
| #### 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. |
There was a problem hiding this comment.
Do you also propose to move the layout extension to attic?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
But then this isn't an argument for the dashboards server failing to integrate with other projects. Or am I missing something?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I think this PR is a reasonable request.Thanks @parente for proposing this one.
|
While I understand why moving the project to attic is the best course of action, let me just say that dashboards-server proved extremely useful. The only important reason I see behind archiving it is the absence of developers. Either way thanks a lot to @parente and the rest of the team for developing this prototype. |
I think we should use same threshold that we use in the governance repo:
That would be 8 positives votes and we currently have those votes (7 + @parente), so I would be inclined to merge this one today unless someone wants to add something else. |
|
+1
…On Mon, Sep 11, 2017 at 8:26 AM, Damian Avila ***@***.***> wrote:
I'm taking that to mean we need at least a majority or two-thirds vote
here, and so I'm adding all members of the SC as reviewers.
I think we should use same threshold that we use in the governance repo:
A minimum of 80% of the Steering Council must vote and at least 2/3 of the
votes must be positive to carry out the proposed action
That would be 8 positives votes and we currently have those votes (7 +
@parente <https://github.com/parente>), so I would be inclined to merge
this one today unless someone wants to add something else.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#22 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABr0Bs5hlAS7iQa_kJDpsqRSL-hJCEHks5shVEzgaJpZM4PLUL5>
.
--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger@calpoly.edu and ellisonbg@gmail.com
|
|
Thanks all for the feedback. References for cross repo notification: jupyterlab/jupyterlab#1640, jupyter/dashboards_server#319. |
|
Late to the party, but +1 :) |
This PR proposes moving the dashboard projects remaining in jupyter-incubator to jupyter-attic, states the reasons why, summarizes what we learned from the projects, and notes some possibilities for next steps.
Comments and suggested edits are welcome from all parties.
The new subprojects governance doc says "a recommendation will be made by the consensus of the Steering Council (SC)". I'm taking that to mean we need at least a majority or two-thirds vote here, and so I'm adding all members of the SC as reviewers.