Closed choldgraf closed 3 years ago
I think it's a good idea. Things we could fund from this perspective:
We could also try another contributor-in-residence round, perhaps in the second year? Or even just fund a dedicated contributor-in-residence with an explicit mission statement that their project responsibilities are in contributor support and broadening participation. That's a lot of weight to put on someone, though.
From someone that has done both Outreachy and also was a Contributor in Residence, I believe that applying for a new CZI EOSS grant is a good idea.
I think Min's perspective on possible funding usage is great! From my personal experience of joining the JupyterHub team through the Outreachy program, I think extending the Outreachy funding from just paying for the internship to the point of offering the participant the option to join on a longer term basis, would be a good idea.
A bit of background, purely from my own perspective:
When I applied to the Outreachy internship, my motivation was to get closer to finding what I love to do. It wasn't just to keep myself occupied for three months, but more of a "I hope I'll enjoy the internship work and that I'm going to be doing it for as long as it makes me happy." This, and the fact that I was lucky to have had a bit of financial independence from having have worked before, helped me be patient and continue to work and be available in between funding opportunities. But that wouldn't have been possible two years prior to this.
To wrap everything, I believe we should consider using part of the funds (when/if we get them) to help Outreachy applicants become core developers and maintainers if there is desire from both parts.
Great points! Since this is a two-year proposal, including funding for a contributor in residence in year 2 that we hope will be filled by one (or more?) interns from the previous year might be a good idea so we can do something like your experience in a single funded plan.
@GeorgianaElena do you think it would be a disservice in this regard to e.g. run 4 outreachy internships knowing we only expect to be able to fund one for a follow-up position?
@GeorgianaElena do you think it would be a disservice in this regard to e.g. run 4 outreachy internships knowing we only expect to be able to fund one for a follow-up position?
I don't think so. Creating the possibility of even just one follow-up is a great and awesome thing to do :heart: . It's however something that's dependent of the Outreachy experience itself and we can't know for sure until it happens.
I was also thinking outreachy and I love the idea of a two step program! Just a thought, we could theoretically do more, since the funding maxes at 200k a year, which could be enough for two CIRs, and since we could apply for two grants if we wish (one for the eoss, and one for broadening participation)
From the Matplotlib side I am interested is proposing CIR(s) for the CZI supplemental grant that is across and mentored by multiple projects to work on smoothing the interactions / interface between the projects.
I really like the idea of combining the Outreachy internships and the "Contributor in Residence" program into a single pipeline. I think one thing we should do is improve the support for mentorship/management/wrangling, particularly if we'd take more Outreachy interns than before. Here's one proposal:
What if we defined a new role: A JupyterHub Community Advocate.
This is a role whose job is to support the community of users and developers in the JupyterHub world. They do these things:
This could either be a single person, or it could be a role that multiple people take on. It is more a set of "focus areas" around a particular topic. It could be a volunteer position, or could be funded.
Then as a start, we use this CZI round to both fund this role and a round of Outreachy interns in year 1, and a Contributor in Residence in year 2:
Year 1
Year 2
I think that this could either fit under the "Regular" EOSS call, or the "Broadening Participation" one.
That sounds like a really good structure. I'd probably say we list outreachy in both years, though, as something I hope we can plan to do continuously?
Good call 👍 If we earmark $80,000 for the advocate we could afford this (I think $80K would cover >= 50% of most people's salaries for a year).
So it sounds like there is general enthusiasm for the idea. We need to submit a Letter of Intent by the end of March. Shall we discuss this in the team meeting next week and see if people are on board?
A few questions that I think we should answer:
I wanted to pitch an idea for focusing one of the Outreachy positions around onboarding a non-Python person into the Binder/repo2docker ecosystem with a view to improving the user experience for non-Python users.
I got this piece of feedback from the workshop I ran a couple of weeks ago and it makes me sad that it's so difficult for R users to use Binder.
I felt it was better suited to python than R users. Had I known that Binder is not really optimised for R, I might not have attended. However, I did still find the session useful and the instructors were very helpful. I just think given how long R takes to load on mybinder it isn't practical to use in the session or really outside of it
I think this is a valid point since the Python story is a lot cleaner in Binder and this partially stems from the under-representation of R folks in the team.
You might ask how we could mentor such a student given that we have under-represented R knowledge in the team.
I imagined if we could find an R expert who was passionate about improving R in Binder but didn't know the guts of Binder/repo2docker to get started, then our mentorship could be along the lines of how those pieces fit together and best practices around contributing to "production-ready" code (or is at least deployed to a live service 😄).
Another route to consider could be a partnership with the Rocker or rOpenSci communities.
What do folks think?
@sgibson91 I think that this is a great idea - I'll modify the proposal in the top comment to incorporate a few focus areas for the Outreachy students, and we can pitch some ideas for the others in the proposal as well!
cc @cboettig or @karthik in case they have any ideas on this particular point.
@sgibson91 A couple of bits are broken for the moment (but easy for me to fix) but I created this package (https://github.com/karthik/holepunch) to make it easy for R users. The automatic badge generation is currently broken but that can be done manually for now.
Hey all - I updated the top comment with some EOSS application ideas, per our conversation in the last team meeting. I added a second EOSS grant idea that we touched on briefly, around coordinating activity between JupyterHub and other "cloud-native" applications in the ecosystem. Please let me know if I missed something! (cc @minrk @cooperrc @sgibson91 who I remember saying were interested in helping with this round, others please do join in if you're interested!)
Yes @karthik, thank you for that package and I do reference it in the R version of the Turing Way tutorial.
I guess what I'd like to do is bring tools like holepunch directly into Binder so that R users don't feel Othered for needing to do something different to get better performance.
I had a conversation with @echarles today, who suggested that another potential project could be around Authorization as it pertains to real-time collaboration. I don't know how much work this would be, so no idea if it's good for an Outreachy project, but perhaps we could carve out a sub-project that's fit for an Outreachy student?
@echarles lemme know if you have thoughts there!
Thank you so much @choldgraf for involving me as @trallard in this initiative and see how we can build bridge between the Jupyter communities.
As said at this week JupyterHub dev meeting (btw I don't find back the minutes on the archive) we (@ellisonbg @SylvainCorlay @dmonad and @Zsailer when he is back from his happy even and others) are discussing for the Jupyter Realtime Collaboration project on the Authentication (aka Identity) needs in a cross-components (Lab/Server/Hub) aspect. For now it is just discussion/experiments and we will post more piggy back on the jupyterhub repository with questions/suggestions. I also understand other funded initiatives are ongoing to tackle this important feature.
Once we will have the Authentication sorted in a cross-component aspect, I was wondering how Authorization to e.g. support permissions features for RTC like documented by @fperez on https://github.com/jupyterlab/rtc/issues/132 would look like (see also comments on https://github.com/jupyterlab/rtc/issues/28). I have followed the PRs/branches:
If you look at the verb/nouns used, Server says e.g. @authorized("read", resource="kernelspecs")
and Hub says e.g. @needs_scope('read:services')
- Hub has the notion of groups, Server does not...
JupyerLab has nothing for now, but would need e.g. "user is not allowed to install lab extensions", "user is allowed to collaborate on a notebook with user of the same group"....
BTW there is also the discussion opened by @yuvipanda on Mapping notebook user identities to cloud provider identities. The question can be expanded from identity only to authorization. And if you look at e.g. the AWS IAM model, we can get inspiration from that. IAM is the central place where you define access control for all the services. I guess we can get inspiration from that.
Hence my questions: does it make sense to have a way for Lab/Server/Hub to share/exchange on a understandable model/protocol for authorization? If yes, how can we start defining and implementing something for this? Would an Outreachy intern (skills timeframe...) be suited for that?
This issue has been mentioned on Jupyter Community Forum. There might be relevant details there:
https://discourse.jupyter.org/t/letters-of-intent-for-a-couple-czi-eoss-grants/8454/1
@costrouc didn't you have some thoughts on authentication/identity as well?
We are nearing the deadline for this proposal, and need to have a Letter of Intent ready by early next week. Can we reach agreement about applying for these proposals?
A few questions:
Please let me know if I am missing something important! I am happy to help write and prepare applications once we get to that point - just need to nail down the details of where the proposals would go / what they'd be for first.
+1 from me!
update: I put a little bit of writing into a (too long) summary of work for the "Community Developer" proposal. I'd love comments and feedback! Here's a draft
I believe that @minrk is working on a proposal for the other proposal we've discussed!
The proposals are due on March 30th!
Yes, I'm working on the 'jupyterhub integrations' proposal for Simula, drafting here.
@choldgraf LGTM!
Thanks all for your helpful comments in the doc! I'll take another pass later today 🌈. I had a quick idea - we have some budget remaining in the first year. What if we used that budget to pay for some OpenScapes training for the JupyterHub (or broader Jupyter) community? I think we could frame the OpenScapes training both as a way for the "Community Developer" to gain experience, but also to spread these ideas with others in the Jupyter community as well. Any gut-check reactions to that? (cc @sgibson91 or @trallard in case they have other suggestions for similar programs?)
Thanks for everybody's comments in the DEI proposal - I've taken a pass, tried to tighten up the wording, and addressed comments. I welcome any subsequent thoughts or ideas! (in particular, curious what folks think about the OpenScapes idea ☝️
@minrk - is there any assistance that folks can give you on the other proposal?
I personally like the idea of running OpenScapes training or something similar.
I added some more comments to the proposal - hope I am not making this tougher with the time crunch 😬
Well, I casually checked the CZI submission time, and realized that it was in approximately 8 minutes. So I frantically accepted everybody's edits and made a few tweaks here and there, and submitted the LOI at 4:59pm (about 23 seconds before the deadline). I'm now going to go collapse in a heap somewhere.
Thanks so much to everybody for helping provide your insight and suggestions (especially @trallard and @willingc for helping communicate the importance of pathways to leadership).
Closing this as we've submitted the LOI so will open another issue if we a invited to submit one
Background
We applied for a CZI EOSS grant in its first year of existence, and received one! It went towards paying @GeorgianaElena and part of @betatim for a year for the JupyterHub Contributor in Residence program. This grant ended in December of last year.
CZI just announced round 4 of this program, and now offers $50K-200K per year for 2 years.
In addition, as a previous EOSS recipient we have the ability to apply for an additional $50K-200K per year for 2 years to go towards broadening participation from underrepresented groups in open source.
Timeline
A Letter of Intent is due by March 30th. The application will then be due a few months after that.
Two proposal ideas
EOSS DEI focus grant
summary: Define a new role: A JupyterHub Community Developer. Also combine Outreachy internships and the "Contributor in Residence" program into a single pipeline, with more support for mentorship and community development.
EOSS regular grant
Two years of funding for project leadership, strategy, and execution around deploying JupyterHub in addition to other major applications for cloud-based data science. Basically, find ways to connect JupyterHub more seamlessly with other applications and infrastructure, and help design and build infrastructure + documentation that makes this easier for users. See this team compass issue for one example.