Jupyter Telemetry System

Jupyter Telemetry System

Opening this thread to collect and synchronize conversation around a Telemetry System for the Jupyter ecosystem. Feel free to edit this post with useful links/content.

See the future-looking Press Release here.
See the initial Design document here.
See a draft of the Jupyter Enhancement Proposal here.

This top post provides quick reference and links to places where Telemetry is being built. For detailed information about the Telemetry system, read the design document.

Projects this Telemetry System with affect:

  • JupyterHub
  • JupyterHub Services
  • Jupyter Server
  • Jupyter Server Extensions
  • Jupyter Lab
  • Jupyter Lab Extensions

Personas considered:

  • Administrators of Jupyter deployments
  • End users
  • Jupyter (server · lab · hub) extension developers

Active projects and discussion:

3 Likes

Thanks for opening this discussion Zach to get things started here!

1 Like

Thanks for starting this discussion Zach.

This may be a little off-topic, but could you give me some examples of what a Jupyter Server Extension would be or look like?

Also, I’m not overly familiar with JupyterHub’s architechture, is a JupyterHub Service similar in any way to a Jupyter X Extension? If not, are JupyterHub Extensions a thing?

1 Like

This may be a little off-topic, but could you give me some examples of what a Jupyter Server Extension would be or look like?

Sure. Jupyter Server Extensions just append new URL endpoints+handlers to the Jupyter Server.

Two examples of jupyter server extensions (there are many more) are:

  • JupyterLab
  • JupyterLab-git: “emitting” events from this extension requires jupyterlab-git to be made aware of the telemetry system.

Developers of server extensions may want to add their extension (i.e. emit events) to the telemetry system. They will have to add logic to emit events from their extension.

JupyterHub Service similar in any way to a Jupyter X Extension

Yep, JupyterHub Services are essentially JupyterHub “extensions”. I’m speculating here but I believe we call them services because JupyterHub doesn’t really behave like a single server that’s being extended. Rather, it’s behaves like a gatekeeper for a collection of separate services. Creating a JupyterHub Service is just adding another member to the collection.

Although, you’ll have to ask someone who’s been around longer than me to verify my spec

Pinging @davclark as he is probably interested in what is happening in this area.

1 Like

Sorry to be slow in responding, but thank you @betatim, and yes, I’m interested both in helping inform the process (which I’ve tried to do in this thread I started - but was far less focused).

Is it useful to copy my own ideas from there to this post here on the discourse, or is it more useful to post into the GitHub PR, etc.? I’ve been leaning towards keeping things in Discourse because I think it’s more accessible, but developer engagement seems higher on GitHub.

1 Like

It’s a fuzzy line… I’d like to keep broader community conversation here on this Discourse thread. (I agree, it’s more accessible). Participation on the Github thread should remain specific to reviewing the content of the PR.

1 Like

My thoughts there are that any broad discussion should be in the Discourse, but any discussion that’s directly related to an actionable change in a github issue or PR should be done on github. Basically if it’s a comment that doesn’t directly feed into a change in a repository, it should be on Discourse.

1 Like

OK - I made a 1-file PR against the design doc. Basically, I’m proposing to elaborate around the UI (and also an API) for consent, and I think that’d be a good place for me and my co-workers to start contributing.

It’d be nice to see example consent UI. As far as I can tell, none of the examples have a consent that would be appropriate for a university IRB… just configuration options. Or, is that enough? Would it be useful to screenshot and/or describe the configuration (~consent) of things like Wikipedia, firefox, popularity-contest, etc? e.g.:

FWIW - personally, I think the above is GREAT except that it’s kinda buried. I know where I’d stick something like this in Gigantum (we have a material-design style button that expands to show helpful stuff), and I think it’d make sense to put on a login page for JupyterHub, but where would it go in JupyterLab?

2 Likes

Thanks @davclark!

I think it’s worth researching other’s consent UIs. If you’d like to collect that information and post screen shots here, that would be helpful.

I think there are two UIs to explore:

  1. User opt-in / opt-out dialog for deployments where users dictate what information is being collected.
  2. Auditing / monitoring information for deployments that require auditing to comply with legal regulations. Users can’t turn-off this telemetry, but they are informed of what is being collected. This UI should translate the deployment’s telemetry settings into something end-users can understand easily.

Just back from Japan and sitting down at work for the first time in about 2 weeks :slight_smile:

There is a good list of options to explore that @yuvipanda put together in the telemetry repo. I’m happy to collect visual examples from that, and I’m going to work with @jenuxdesign on how to structure this information in the most useful way.

Regarding (2), I already asked @ellisonbg for examples in the PR, but I’ll re-ask here so that he and potentially others will see the question. I don’t have great examples for mandatory monitoring contexts and the way users are informed. So, if anyone does have good examples, please share them!