In recent months, a few new binderhub deployments have been deployed. I was involved in deploying binder.pangeo.io and there is also a relatively new binderhub running at GESIS. In a gitter chat earlier today there was some conversation about distributing the binderhub development team beyond those directly involved in running mybinder.org. @willingc asked me to post about this here so that’s what this topic is for - how to think about binderhub development now that mybinder has siblings.
In my view, it seems like it would be useful to recruit a few stakeholders beyond the mybinder team to help make development decisions for binderhub.
I think this can be partially-addressed with a more explicit governance structure. We could imaging having a group that has commit rights / makes decisions about / etc the BinderHub tech, and we make sure that this group isn’t only people from one project, institution, etc. I’d love to signal to the community that we want this to be an open project and not “just” something for Jupyter.
@choldgraf - can you describe the current governance structure for binderhub? Do you think there are specific considerations for the mybinder.org team that could use alternative view points? I’m specifically thinking of things like security and authentication - these seem to be in scope for binderhub but not mybinder.org.
one goal of structuring the governance model to include other organizations is precisely to reflect the fact that BinderHub should not only be developed for the purposes of running mybinder.org. I think we all agree that this is the goal anyway, but this could be an opportunity to make this explicit
Binder was the first public BinderHub after https://mybinder.org They have been the driving force behind PRs to implement and document authentication for BinderHub as well.
As an insider to mybinder.org and BinderHub I’d be interested to hear what we could do differently to encourage more people to contribute to BinderHub or what should we stop doing that we are currently doing that is turning people off? Ideally from someone who isn’t involved currently or would get involved more if we changed our ways.
Thanks @choldgraf and @betatim. All good points. I wanted to make sure I say I’ve found everyone in this space quite welcoming and accommodating. I personally had no problem entering, making some changes, and using this stack. Hopefully this is clear but I didn’t post this with any specific qualms but rather as an observation that the team lacks some order of diversity in terms of deployments and developers.
Great question. I’ll spitball a bit.
Better document the technical differences between binderhub and mybinder.org-deploy. I think the latter has a bunch of useful infrastructure associated with it that isn’t in binderhub yet. I’m thinking of things like instrumentation, continuous deployment, etc but there are probably more
Write a roadmap. I know this is a current hot topic but I think it will be useful for this project.
Move substantive conversation from gitter to github. I also understand the move to discourse is part of this effort but the more we can archive the conversations had between developers, the easier it is for new contributors to know what is going on.
Better document the technical differences between binderhub and mybinder.org-deploy
I think there’s a lot of prototyping that happens in mybinder.org-deploy that should get pushed upstream. We should definitely do periodic checks for what gets pushed from our deployment to the base installation. In particular, mounting /etc/jupyter for custom config is generically useful, and should be pushed up to zero-to-jupyterhub assuming it turns out to work as well as I hope.
They have been the driving force behind PRs to implement and document authentication for BinderHub as well.