I think I need to properly try to figure out what barriers I keep coming across. (I like the Hubhero idea but need to think about how that would work for advocacy… Which means I need to clarify what issues / obstacles are…)
The issues are all muddled atm (please bear in mind that my focus is primarily how we can use Jupyter notebooks for creating and distributing teaching materials to distance education students).
- individual academics don’t see the benefit, don’t have the time/machine/skills to install a local jupyter setup; they don’t like to be seen to fail in private so they want to have a private space to practice in;
- what’s the best way to demo a notebook setup? On the one hand, there’s just a basic run through of core features (how md works; how you can execute code, etc). I’ve seen taster events where folk very quickly go reactionary and negative (md is too hard (need a WYSIWYG editor), there is no spell check etc etc; and yes, bickering does start at that level; repeatedly…). One workaround for that is to demo a customised environment that does have those features via extensions, but the problem with that approach is that if someone does try their own setup, it isn’t customised in that way and they get frustrated. There is also the risk that if you do demo a customised environment it is seen as too complicated / feature rich / confusing / bewildering.
That’s trying to advocate to users. Trying to get demo servers internally is another thing:
- no budget code;
- no business case: very few others are asking for a server because very few others are trying to use notebooks; chicken-and-egg; no-one is asking for this, therefore waste of internal resource putting up such a service; I had hoped that using Azure Notebooks may help build a case but that’s not had much success so far.
The fact that Jupyter is a live project also causes issues. Folk get twitchy that because it gets updates: it takes us two years to produce a course that then runs for five so change is dangerous… Folk see the fact that the application does get updates as the fact that proves it’s unstable, at least on our timescales, or too undeveloped (counter to that, course I’m on adopted IPython notebooks, as was, at a time when they were still a bit unstable; but we were convinced the project had legs and knew there was two years of development likely before we’d have to go live with it to students given our course production timescales).
The fact that I can just launch a server on my own Digital Ocean box also proves it’s not a proper piece of production software. Real software requires lots of folk in IT do do lots of things. (If I take the route that IT are helping me deploy via Azure/Kubernetes, then it’s obviously too complicated, or too expensive having to be commercially hosted, or too risky because it’s a community project with only a couple of core developers, not properly supported commercial software etc etc).
This has got me thinking… Our course has a “How to Fail This Course” Guide (“step 1: spend all day playing Fortnite and ignore the course altogether; alternatively, set aside two evenings a week and half a day at a week to concentrate on your studies” etc). Maybe one way to think about advocacy development is a set of flippant reasons why it doesn’t make sense to use Jupyter stuff, then provide counters to those.