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.

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

August 2017 Team Meeting Agenda Topics #36

Closed
ellisonbg opened this issue Aug 28, 2017 · 27 comments
Closed

August 2017 Team Meeting Agenda Topics #36

ellisonbg opened this issue Aug 28, 2017 · 27 comments

Comments

@ellisonbg
Copy link
Contributor

ellisonbg commented Aug 28, 2017

To help us quickly collect topics for our August 2017 team meeting, please enter comments and upvote existing comments. We are short on time (only two days), so this will help us to surface the most pressing discussion topics.

https://paper.dropbox.com/doc/August-2017-Team-Meeting-Agenda-NvwrkTa47sUQJbRjDwfzN

@Carreau
Copy link
Member

Carreau commented Aug 28, 2017

I think we should make a JupyterCon debrief while still fresh in our heads.

(feel free to edit add subitems)

  • lightning talks,
  • closing statement
  • Diversity in programming language
  • attendee feedback, can we access it?
  • More visible Tshirt "Ask me anything about Jupyter"
  • Predefined tracks

Update: Topic discussed ✅

@rgbkrk
Copy link
Member

rgbkrk commented Aug 28, 2017

Notebook HTML and JavaScript mimetypes

  • Acknowledging the legacy "API"
  • What belongs
  • Can frontends iframe it
  • ...

@choldgraf
Copy link
Contributor

Use-cases/ways to highlight tools in the Jupyter ecosystem. Ideas to build documentation and demos. (in particular for the newer tools like JupyterHub and JupyterLab)

@damianavila
Copy link
Member

Roadmap updates/upgrades (and with better definition/accuracy) so everyone could know about our next steps and can plan accordingly.

@ellisonbg
Copy link
Contributor Author

What to do with our roadmap:

https://github.com/jupyter/roadmap

@bollwyvl
Copy link

UI, Metadata, and Tools for Internationalization/Localization of Notebooks

building on the existing core JEP

  • what can be internationalized?
    • markdown cells
    • code cells (e.g. chart labels, etc.)
    • metadata fields (title, etc)
  • what does it get me?
    • metadata/SEO flagging
    • output formats (multiple ipynb, single html, multiple html)
  • low-friction ways to propose/review/iterate/accept new translations (non-developers)

@rgbkrk
Copy link
Member

rgbkrk commented Aug 28, 2017

Spark UI

Infrastructure related pieces:

@bollwyvl
Copy link

UI, Metadata and Tools for Richer Layouts

continuing this JEP, this discussion, RISE, nbpresent

  • what to make?
    • posters
    • slides
    • dashboards
    • multi-page documents, a la bookbook, multirise, etc.
    • apps
  • what to consume?
    • any mime you can render!
    • multiple notebooks, etc.
  • what else?
    • layers
    • archival output (i.e. DOM-based PDF, e.g. chrome-headless
    • themes

@rgbkrk
Copy link
Member

rgbkrk commented Aug 28, 2017

Resource Info Request

This started out as a little discussion in jupyter/jupyter#264 at the last meetings. Now to follow up!


When working in a jupyter environment, it would be helpful to see current resource usage

  • CPU(s)
  • Memory of the system
  • Memory of the current kernel

Beyond that, people need information from libraries. Taking Spark as an example, they want to know several fields:

  • Spark UI (string - URL)
  • Memory on executors
  • State of executors (?)
  • Spark Version (string)
  • Hadoop Version (string)
  • Shared cluster mgr resources (containers, vcore-hours, memory-hours, ...)

@minrk
Copy link
Member

minrk commented Aug 28, 2017

display-data cell type: jupyter/notebook#1123

@ellisonbg
Copy link
Contributor Author

Jupyter Markdown syntax:

At last team meeting we discussed doing some research to understand the precise markdown syntax that the classic notebook supports. We have started this work by creating notebooks with the CommonMark test suite. We currently don't pass much of it :(

How should we proceed?

@ivanov
Copy link
Member

ivanov commented Aug 28, 2017

Kernel testing (validation, infrastructure, etc)

@ellisonbg
Copy link
Contributor Author

Where do we want to be in 3 years? Vision, strategy, big picture.

@choldgraf
Copy link
Contributor

re: @ellisonbg 's comment, specifically the topic of striking a balance between the enterprise/larger business community, and the more "open-sourcey", small-business, or academic community

@rgbkrk
Copy link
Member

rgbkrk commented Aug 28, 2017

Maintainer roundup

  • Archiving (new hidden feature on GitHub), rather than jupyter-attic
  • Current workflows

(Feel free to edit the above if you think of other subtopics)

@willingc
Copy link
Member

Follow up from the Education BOF at JupyterCon. Should we create a repo with initial invites to the attendees from the BOF to share issues (q&a) and content questions re: teaching. Perhaps initially make it private (so that there can be more discussion and deeper questions). Follow up from discussion with Lorena and Jess.

@willingc
Copy link
Member

Adding a Code of Conduct doc to each repo since GitHub is now tracking Community Insights (which new contributors look at). The doc could be simply a link to the document on the governance repo. I believe Libraries.io also tracks which projects have a CoC in the repo.

@mpacer
Copy link
Member

mpacer commented Aug 28, 2017

Misunderstood purpose of this issue, comments about juptyer_markdown below, ignore it otherwise.


At last team meeting we discussed doing some research to understand the precise markdown syntax that the classic notebook supports. We have started this work by creating notebooks with the CommonMark test suite. We currently don't pass much of it :(

How should we proceed?

Worked with @pxhanus at the sprints to get set up with a development environment (w/ virtual envs & c.) so that we can move forward on the jupyter_markdown issues.

Discussion points:

  • automated test results analyses
    • Some tests may not pass, but may also be less important than others.
    • clustering based on features (e.g., headers) will tell us which parts need the most work.
  • Github flavored markdown or commonmark (or both?)
  • Timeframe for getting results.
  • Aim: Knowledge or coverage? Both?
    • Do we need to just know what current state before introducing support for new features? Or do we need to fix our coverage first?
  • Is this a barrier to new features (e.g., citations)? If so, is knowledge or coverage the barrier to new features?

@rgbkrk
Copy link
Member

rgbkrk commented Aug 28, 2017

VDOM Mimetype

@DTAIEB
Copy link

DTAIEB commented Aug 28, 2017

Dashboards: design and publish to web

@Carreau
Copy link
Member

Carreau commented Aug 28, 2017

Dev ops / maintnance / deprecate repo that are not maintained etc...

Cf Kyle's "Archiving" as well.

screen shot 2017-08-28 at 13 08 36

@Carreau
Copy link
Member

Carreau commented Aug 28, 2017

Communication in general, keeping blog and other communication channels, weekly summary up to date.

@Carreau
Copy link
Member

Carreau commented Aug 28, 2017

Jupyter Orange M&M's, and other swag.

chompy bottle openers

@mpacer
Copy link
Member

mpacer commented Aug 28, 2017

package for multi-notebook publishing

(Highly configurable, in analogy to nbconvert)

basically something that would make it easier to write bookbook, multi_rise, &c..

@mpacer
Copy link
Member

mpacer commented Aug 28, 2017

Mathjax and DOM safe equation rendering

@mpacer
Copy link
Member

mpacer commented Aug 28, 2017

Reproducible publications & connections to publishers and conferences, proceedings, &c.

@damianavila
Copy link
Member

Closing this one, there is no reason to keep it open now, IMHO.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests