search

2i2c-org / infrastructure

Infrastructure for configuring and deploying our community JupyterHubs.
https://infrastructure.2i2c.org
BSD 3-Clause "New" or "Revised" License
105 stars 64 forks source link

Define terminology for our hub service and shared responsibility model #1473

Open choldgraf opened 2 years ago

choldgraf commented 2 years ago

Context

In some recent iterations we have explored new terminology to describe our service and the staffing model that we use to run it. We want to strike a balance between two kinds of service delivery:

The first approach is what we largely began with, but this seemed to create an impression of "software as a service", and downplayed the transparent and collaborative nature of how 2i2c wants to run its services. The second approach leans more heavily into the non-profit and mission-aligned nature of 2i2c, but "collaboration" is a vague and over-loaded term.

We are ultimately aiming for a grey area: while there are some aspects of this that are a traditional "managed service" (the Kubernetes and base JupyterHub infrastructure). There are other aspects of the service that are not "fully managed" and more collaborative (like guiding communities in using the infrastructure). We need to find a way to strike a balance between the two.

For two examples of our current service collaboration model, see:

Proposal

We should define a consistent set of terminology to use when describing this model that strikes the right balance between these two things. We can then apply this terminology throughout our documentation and service descriptions, and use this to guide our shared responsibility model.

Updates and actions

No response

yuvipanda commented 2 years ago

Thanks a lot for opening this up, @choldgraf!

I agree the grey area is what we're going for, and it is important to recognize that. However, I think 'collaborative' is too grey, and also to me connotes the RTC work that happens in JupyterLab. It also feels like the adjective is refering to the kind of hub that is produced rather than the process by which it is managed.

Perhaps 'Collaboratively managed hub'? That points the adjective to the fact that the management is what is collaborative, not the hub itself.

Separately, I've been trying to draft a 'Right to participate' document (similar to our right to replicate) that will help lay out what kinda collaboration we mean. Vague outline (without a lot of answers) at https://hackmd.io/zH1PE6maTkmbfKyU4AQe-Q.

colliand commented 2 years ago

James Halgren of Alabama Water Institute referred to 2i2c as a provider of "infrastructure as code" when we discussed the shared responsibility model. I agree with Yuvi that "collaborative hub service" has a namespace collision with RTC.

I wondered how different stakeholders will respond to this terminology. Champions of 2i2c's service will likely understand the shared responsibility model while people in procurement may not. Emphasizing "collaboration" in the product name may lead procurement people to ask why are we paying for a service from them when the work is performed by the champion? Does the "managed hub service" language leave procurement satisfied while maintaining the collaborative engagement with the champions?

jmunroe commented 2 years ago

Rather than thinking of "Managed Hub Service" vs "Collaborative Hub Service" as an either/or offering with some overlap, is it cleaner to talk about the "managed hub service" being a proper subset of the overall value that 2i2c is providing? I agree that 2i2c mission orientation means that being "only" a software-as-a-service provider is not really describing the full value that 2i2c brings to its partnerships.

Could we pitch it as a partnership with 2i2c bring a series of "features", some that are core and some that are optional? For example, I think there is always a underlying managed hub for which 2i2c is providing the engineering so that is core feature. But our level of end-user (L1) support could be extended if that was part of the overall scope of the partnership. Some communities may want additional support and training (and for 2i2c to handle that) and other communities may want to develop their own resources and procedures for providing that end-user support.

And I agree with Yuvi and Jim that the word "colloborative" will likely cause confusion with "real-time colloboration" to most communities and users. This is already a key feature in Google Colab and is an upcoming feature for JupyterLab. Are their any synonyms that we could claim instead for what we are envision when 2i2c says "colloborative":