Give @krinsman maintainer access to nbviewer

[parente]

@krinsman has been helping out tremendously in this repo for the past year. (Have a look at the recent PRs, commits, and issue triage activity for evidence). I'd like to grant them maintainer rights in this git project to continue to help out with nbviewer up-keep, if @krinsman is interested. I think we can keep a discussion about granting permissions to deploy the public nbviewer site separate for the time being.

I'm not aware of a process for granting admin permissions in one-off Jupyter repos like this one, so I'm opening an issue here for community visibility and @-ing major past contributors for input: @minrk, @Carreau, @rgbkrk , @ellisonbg, @bollwyvl. If there's a different, preferred mechanism, please let me know. Otherwise, if @krinsman is on-board but there's no response from others by February 17, 2020, I'll assume silence is consent and grant the permissions.

[Carreau]

If @parente vouches for you, then I have no objections. Welcome to the team.

[krinsman]

Oh wow thank you both so much! Yes, I would love to continue to help out with this if possible!

Also it's good to know that if I accidentally merged something which caused a feature regression it wouldn't automatically get deployed to the website. I think the pressure of that would prevent me from wanting to merge any commits, especially since this would be the first time I have been a maintainer of a project as large as this. I really, really, really would not want to accidentally mess up the website for its thousands or millions of users, even if only temporarily.

[parente]

Also it's good to know that if I accidentally merged something which caused a feature regression it wouldn't automatically get deployed to the website.

Deployment to nbviewer.jupyter.org is currently a wholly separate, human-in-the-loop step. There's no need to worry about immediate breakage. The tradeoff is that we need to worry about breaks detected much later on when we do deploy. There have been a few, and they have been minor (i.e., the deploy fails upfront or only one container instance is impacted not all instances).

There have been proposals about improving the deployment story of nbviewer (e.g., a helmchart for kubernetes) but I'm not aware of any work kicking off on that front yet.

[krinsman]

Phew, that makes sense. Yes I suppose a kubernetes helmchart could work, since that's what the classes at UC Berkeley use fairly successfully for real-time deployments. But of course I'm still learning how to merge to that repository correctly too, so I am glad it isn't an issue here.

[Carreau]

Also it's good to know that if I accidentally merged something which caused a feature regression it wouldn't automatically get deployed to the website. I think the pressure of that would prevent me from wanting to merge any commits, especially since this would be the first time I have been a maintainer of a project as large as this. I really, really, really would not want to accidentally mess up the website for its thousands or millions of users, even if only temporarily.

Haha, don't worry we all did it; and if you want to automate deployment and have a staging then production or a A/B – Blue/Green progressive deployment it's also a good project !

[minrk]

Yes, absolutely! Happy to have @krinsman with all the wonderful contributions.

[minrk]

I would love to move the nbviewer deploy over to a more automated more in-public process like we have for mybinder.org. That's a lot easier to maintain and add helpers for than our private nbviewer-deploy process.

[parente]

I think we're agreed this is a good idea. I've switched your role to "maintainer", @krinsman. you should be able to review, merge, edit, etc. pull requests now among other things. Please shout if you find you're missing some capability.

Thank you again for all you've been doing!