tags: binder, meeting, notes
# JupyterHub and BinderHub Team Meeting - December
Date: 20 December 2018 at 6pm Zurich time
#### Videoconference link: https://calpoly.zoom.us/my/jupyter
[Link to prior meeting's virtual meeting report](https://hackmd.io/5b2v59OATb-ADY2bo2YTPA)
## Welcome to the Team Meeting
If you are joining the team video meeting, sign in below so we know who was here. Roll call:
* name / institution / GitHub handle
* Tim / Wild Tree Tech / @betatim
* Min / Simula / @minrk
* Erik / Sandvik CODE / @consideRatio
* Zach / Cal Poly / @Zsailer
* Carol / Project Jupyter / @willingc
* James / UW-Madison / @jrbourbeau
* Joe / NCAR / @jhamman
* Brian / Cal Poly / @ellisonbg
* Kacper / Whole Tale / @xarthisius
* Yuvi / Berkeley? / @yuvipanda
* Lindsey / Berkeley / @lheagy
* Craig / Whole Tale / @craig-willis
* Jessica / @jzf2101
* Murali / Capital One/
* Chris H / BIDS / @choldgraf
* name / affiliation / github
## Should Binder seek out a next partner to grow adoption?
(silent writing exercise while people arrive)
If you think yes, who should we start reaching out to?
* if there is interest we can create an agenda point around this at next months meeting
* a conference to which a large fraction of submissions is "code", use mybinder.org as part of the submission
* teaching programme? Help teachers build classes or education that is otherwise hard to do because people don't have access to computing
* Erik connected to students in Gothenburg University, will have a talk about Jupyter in February for them, 20-60 people. My brother is an "Docent" there and utilizes Jupyter somewhat already.
* (Zach) At University of Oregon, a few professors use Binder repos to teach chemistry/biochemistry concepts using interactive widgets ([example](https://github.com/harmsm/biochem-jupyter-notebooks)). Advertising this use case at universities might generate some traffic.
* (Yuvi) Working on getting a grant from Space Telescope Institute to pay for my time at Berkeley, involving unspecified Binder work
* Conferences that use binder's underlying tech (eg Kubernetes or dev ops people)
## Agenda items
Let's collect all potential agenda items here. We will then sort them at the start of the meeting. If there are similar items try and group them already.
* What should we do with github issues that are support requests? (e.g., https://github.com/jupyterhub/zero-to-jupyterhub-k8s/issues/1006) [CH]
* people have questions about technical issues that can be out-of-scope of the project directly
* currently the issues remain open forever
* What should we do with them?
* GitHub for bug reports and feature requests only
* questions and how-do-i-do... are directed to discourse/Stack Overflow
* have a bot that replies for us directing people at discourse
* **TODO**: Open an issue to discuss providing either 1. instructions in the issue
template for what kinds of issues should go here, 2. a bot that jumps in on new
issues and posts a friendly message about what kinds of issues are appropriate.
general agreement that discourse is a good place for more general tech support
so we can start people there.
* Any news about the OVH deployment?
* OVH: cloud deployment in Europe
* Google has agreed to pay our cloud bill by giving us a lump sum to spend
* what then?
* repo2docker extensibility. how can we make it possible for users to define
"patterns" that they can share with others without forking repo2docker.
e.g., for NeurIPS we set up a CUDA-based cluster and it'd be great to make it
easy for people to "enable CUDA" without requiring a Dockerfile. Another example
are more complex but common setups like Latex etc.
* We can already do this with traitlets, if there is an easy driving
use case we can do a sprint to make it happen (Yuvi)
* can a repo request a extension to repo2docker be enabled/used?
* Q: What if we used entrypoints as a potential extension mechanism? A: Yuvi thinks
this would be a good option.
* combination of entrypoints and traitlets sound like a good avenue to explore
* **TODO**: Find a use-case to motivate extensibility on repo2docker and put together
a prototype to test out different approaches.
* rocker related question: does repo2docker want to support running images outside of BinderHub?
* probably yes
* RStudio not through the route of Jupyter is more familiar to RStudio users
* already possible, however needs more exposure/documentation so people know how to do this
* **TODO**: let's find some use-cases that we can use to get a good idea what are requirements and trade-offs
* **TODO**: Write up the current design / structure of the proxying that we use for RStudio
support. Maybe a little blog post + feed that into the docs afterward.
* mybinder.org at NeurIPS2018
* success! Thanks to Jess for getting us there. Thanks to everyone who helped make it happen!
* MILA is very interested @jzf2101 and Felix-Antoine will follow up since I think they may be interested in putting up a Binderhub or JHub
* report from the demo day:
* generally people seemed interested and encouraging
* some groups now want to setup their own bhub and jhub
* surprisingly large number of industry people attendingngngngngng
* blog post: https://hackmd.io/ZEVbmiWHQiOuRUQzRmjnNg#
* publish date: XXX
* Tim would like to discuss how we can make these kinds of events less stressfull
* when we use the Jupyter and/or Binder name we have a big reputation to keep up with and are representing everyone who puts their name and effort to that name.
* having to finish things last minute leads to mistakes and burnout
* for example "any custom deployment has to be demo'ed in 'ready to go setup' five days prior to the event"??
* TODO: create team-compass issue to talk about this and have a more organised discussion at the next team meeting
* binder.pangeo.io at AGU2018 (Joe)
* Just sharing slides: https://doi.org/10.6084/m9.figshare.7492661.v1
* And 4hr tutorial: https://github.com/pangeo-data/pangeo-tutorial-agu-2018
* Zach has been exploring implementations
* Chris brought up question of looking at design requirements and protocol again
* What is the best way for that to move forward
* Zach has some time allocation to work on this in Dec
* Zach has been working on a document to describe usage cases and design requirements
* Maybe look at https://github.com/nteract/bookstore for some ideas. It's early stage but may solve some of your issues.
* Could we use nbviewer to create a gallery of reproducible papers w/ Binder?
* what should we discuss here?
* Outreachy 🎉 !!!
* traefik-proxy project going great! It already works with jupyterhub in local testing. https://github.com/jupyterhub/traefik-proxy
* jupyterhub-nativeauthenticator project going good. Outreachy intern Leticia is moving continents this week, so off for this and next weeks
* TODO: We should invite them to this meeting!
* TODO: we should help them speak at (non-jupyter-specific) conferences about their work
* releasing z2jh 0.8 https://github.com/jupyterhub/zero-to-jupyterhub-k8s/issues/1054
* should be only docs and testing (and related fixes) remaining before the release
* releasing jupyterhub 1.0
* need to finish auth expiry https://github.com/jupyterhub/jupyterhub/pull/2342
* probably pushing oauth scopes to 2.0
* repo2docker roadmap, only items that need to be discussed
* repo2docker.version issue (Craig/Kacper)
* FYI: Erik is thinking about pushing for a national JH for Swedens educational system. Step 1: get universities starting to use a Z2JH.
* I am seeing/hearing interest in JHub variants that are backed by a kernel service and have a persistent UI (not neccesarily containerized). We may want to brainstorm on JHub architecture changes needed for that (Brian).
* Moore Foundation roadmap / wishlist document
* Meeting with Chris from Moore foundation about new Binder grant
* Asked to write up a document with ideas on what we might do, so we can go from there
* https://docs.google.com/document/d/1cyliT2G1e1j81fQEKZUQ2IKb1g_J91g9zF0QowN0hcA/edit#heading=h.gg6hz2kdjmoc is the document, so please add your crazy & non-crazy ideas
* Extended binderhub user API for resource requests and federation (Joe)
* need (want) a way to specify binder cpu/memory requirements and/or other resources (gpu)
* need a way to specify where binders will run (GCP, AWS, etc.), so we're thinking about how to federate resources
* planning work on this for early-2019
* related but differnt: limit resources by user launching the binder instead of the creator of the binder
* Erik had a idea, that wasn't good: we can always let them define whatever, and then restrict it using kubernetes mutating webhooks or something like this... Thinking further, it may be better... yes... to do it before it goes that far into the deployment...
* TODO: create a use-case and flesh it out to find out where this should be at home
* read the previous discussion on the original Binder repo: https://github.com/jupyter/enhancement-proposals/pull/5
Things people should know about
* Outreachy interns have started (Welcome interns!)
* repo2docker 0.7.0 is out!
* repo2docker blog post is out!