The Jupyter Foundation has a pot of money and it aims to use that funding quickly to support the Jupyter Project. But what should it use the funding for? There are many things to do, and not enough time or money to try everything. This is a brief brainstorm and reflection on the things that I think could be most impactful.
What are our goals?¶
The Foundation’s core goal is to support the Jupyter Community. I think this means starting with the community of maintainers, contributors, and leaders that carry out the day-to-day work the helps Jupyter be impactful and improve.
That group of people has made one thing very clear: Jupyter lacks enough capacity. There is too much to do, and not enough time (paid or volunteered) to do it. This becomes a self-perpetuating cycle because it takes capacity to grow capacity, and if you’ve got none of it, you can’t grow something with nothing.
So I think the Jupyter Foundation’s goal should be finding leveraged opportunities to grow capacity. That means finding ways to invest 1x of resources to get 10x of capacity within the project, ideally in a way that can be sustained over time (and potentially live longer than this funding cycle).
I also think that the Foundation should prioritize acting quickly and learning rather than trying to get it perfect the first time around. It’s more important that we deliver tangible value to the community and begin to iterate. So with that in mind, here are a few ideas for where I think we can grow capacity.
Investing in the lifecycle of contributor growth¶
The simplest answer to “grow capacity” is “grow the number of contributors and maintainers”. But this is easier said than done. Sure we could pay for a person to “maintain a tool” or “develop a new feature”, but this doesn’t feel like a leveraged opportunity for capacity building. It gives us a 1x output for 1x input.
I think we can find that leverage opportunity by looking at the process of new contributors, and the critical points where the often hit friction or confusion that causes them to drop off. If we can use resources to improve this lifecycle, we should be able to grow the overall developer capacity of a project by giving others the skills and information to contribute. What is needed is some structure and resources to help them on their journey. Here’s what I’ve come up with:
- Aligning
- Guiding
- Receiving
- Recognizing
- Learning
I’ll explore each below.
Aligning: Getting everybody on the same page about what the project wants to do¶
The biggest challenge I often see is projects that don’t spend the time agreeing on what they want to do in the first place, and making it easy for others to discover their goals and intent. As a result, people make contributions, and realize that they must first convince a project that it’s a good idea to try in the first place, rather than focus on getting the contribution improved and merged.
How could the Foundation support this? Aligning a team on their goals (long or near-term) is not easy and requires a different skillset that we often see in open source projects. Sometimes it can be accomplished with facilitated sessions like a meeting or an asynchronous discussion. I wonder if the Foundation could cover the cost of meeting facilitation or asynchronous triage and prioritization so that projects can agree (for a time) on the things they want to accomplish. If this were made publicly available, others could identify the problems that they want to solve too, and focus on solving them.
Guiding: Helping others learn how to navigate a project and contribute¶
Once a project makes it easy to learn what it wants to accomplish, another big barrier is making it clear how others are invited to contribute. This often begins with a lack of clear documentation. For example, it’s difficult to find the place where team alignment was encoded for asynchronous reference, or the time and location of team meetings isn’t made publicly available. Beyond this, projects often have under-developed user and developer documentation, so that it’s not easy for newcomers to learn how they could participate.
How could the Foundation support this? Improving documentation is often under-appreciated work that requires a surprisingly unique skillset. You need to be able to understand enough about the product aims, the technical stack, and the community itself to communicate these ideas for a broad audience. Could the Foundation pay for technical content writers that have experience working with Open Source projects in order to improve the developer and user documentation of projects?
Receiving: Doing the work to refine and accept a contribution¶
If a newcomer has decided to solve a problem and learned how to make a contribution from project documentation, they often make a pull request that contains their contribution. Assuming that the community already knows it wants to solve the problem, the conversation can focus on improving the contribution and mentoring the contributor in order to understand what an acceptable contribution looks like.
This requires deeper expertise in the skills needed to manage the project, and an authoritative voice that can act as a quality assurance role to ensure that the contribution is successful. It often requires a lot of back-and-forth with the contributor. Crucially, this back and forth needs to happen very quickly or the contribution loses momentum, which wastes everybody’s time and leaves everyone feeling demoralized.
How could the Foundation support this? Perhaps the Foundation could buy-out the time of core maintainers to dedicate to reviewing and mentoring incoming pull requests. Even better, they could use this time to facilitate the “documentation -> contribution -> review” process with some hands-on training or working sessions. For example, the JupyterHub project has been prototyping “Collaboration Cafes” as co-working sessions around the project, inspired by The Turing Way. Perhaps we could pay for capacity for somebody to plan and facilitate these sessions across the project.
Recognizing: Making it clear when somebody has contributed¶
If a contribution gets merged, it’s a huge win for the community and for the person. It needs to be celebrated and communicated to the outside world. This validates the person’s hard work and makes them feel valued. It also creates a public heartbeat for the community that signals to others their contribution is welcome in this way. When contributors do open source work that is related to their career, this can be a useful way to demonstrate their expertise and competence. It feels pretty cool to be able to say you have contributed a significant new feature to the Jupyter Project.
How could the Foundation support this? The Foundation could use funds to hire technical communicators or contribution managers that help them identify and communicate the contributions of others. This could create a reliable stream of feel-good information celebrating the progress the project has made. It’s also a useful way to give regular updates of new functionalities to users.
Learning: Continuously improving as a team¶
Finally, a key part of the entire cycle above is the need to continuously learn and improve as a team. We often don’t think of open source projects as “teams” - everybody tends to work at different times, places, and with their own agendas. However I’d argue that they are as much as team as any other organization, and they have a much harder team coordination challenge to overcome. A key way that any team can get better is by a commitment to continuous learning together. Doing so will pay huge benefits for the individuals and the group as a whole.
How could the Foundation support this? Facilitating learning for a team requires both skill and trust, and I think the best way to accomplish this would be to either pay for time from expert facilitators in retrospectives (or other kinds of agile practices for improvement) or to pay for training to help maintainers manage these kinds of processes themselves.
Things that are missing from the above¶
This has focused on the “contributor and development lifecycle”, but there are many other things projects need help with that don’t quite fit here. For example:
- Responding to questions and new issues from users in GitHub or community forums
- Providing core maintenance on projects like fixing bugs and upgrading dependencies
- Developing infrastructure and tooling for the developers in a project (like streamlining the CI/CD configurations or improving the documentation infrastructure)
- Conducting fundraising for a project so that it has resources to tackle more ambitious challenges
I’m not sure how these things fit in with the broader goals of the Jupyter Foundation, but I wanted to list them here so I don’t forget them! I’ll try to refine this post as new ideas pop up.