(Posting for myself, not for the SC, and even though I mention what I think other SC members think, they may in fact not think what I think they think.)
Oh boy. Let me tell you, this was not a simple ranking, it was a complex multi-faceted puzzle. It was a long process involving many different aspects. It was probably the hardest thing we’ve ever done on the SC. I think we discussed this ten or more hours over several months now, including an hour or two in person at PyCon US. I’m pretty sure that’s more than any single PEP, problem or discussion topic ever.
I think you can categorize the problem into two parts, what is the Core sprint for, and how do you select the set of people who are invited. We didn’t create a formal rubric of either and we didn’t capture everything in our notes, but here’s some of the things we discussed as the purpose of the Core sprint (in no particular order):
- Getting things done: dedicated in-person time to work on existing projects, making significant progress.
- Working together: giving people who work on similar areas but are normally not in the same timezone/area the chance to work closely together
- Design/workflow/feature discussion: practical discussions about things that require (or can use) close attention and input from many people.
- Experimentation and exploration: creating room for new ideas from interactions that otherwise wouldn’t (or are less likely) to happen.
- Onboarding and knowledge sharing: getting people started on new (to them, or in general) areas of the implementation and the language, like the JIT or free-threading, or expanding the group of maintainers of modules or areas that are struggling with maintainer load.
- Mentoring: getting mentors and mentees in the same place, exposing the mentees to more of the Core team, supporting mentees in making connections.
- Social cohesion and interaction: allowing people to get to know each other, improving online communication and cooperation.
- Rewarding contributions: create an enjoyable experience as a small reward for people’s time and effort throughout their involvement with Python.
I think all of us agree most of these things play a significant part, and there’s not a single goal to the Core sprint. We probably have a differently prioritized mix, though. (I said in no particular order, but in fact I think the last one, rewarding contributions, did come last for all of the SC members. I believe we all think it’s probably a factor in how people perceive the Core sprint, but we don’t think it should be a major factor in our decisions.)
As for assembling the list, we tried a few different strict criteria (only people who could attend all 5 days, committers, Core team members, OpenAI hosts, etc) but none of that gave us a small enough list, and we weren’t happy excluding mentees. Instead, we assembled the list using a few basic criteria, expanding them as we filled up the list:
- Mentees should also be far enough along to make the most out of the sprint, not people who are just getting started.
- Mentees should be supported by at least one mentor at the sprint. (We’ve had people have bad experiences in the past when their mentor was too busy with other things to support them.)
- We should prioritize mentee/mentor pairs/groups.
- Nobody should be working on their own.
- We should prioritize (small) groups of people actively working together on projects.
- We should prioritize active contributors (not just commits, but reviews, discussions, mentorship)
- We should create a list that’s as diverse as possible, along all axes.
Things we didn’t do: tie people to specific projects or into specific groups (people can work on more than one thing at once of course), measure their relative productivity or contributions or involvement in any way, measure their relative “diversity”.
Let me be clear, every one of the 57 people on the list are worthy of coming to the Core sprint. It’s really easy to argue for every single one – and I know that because that’s what we have done, even for the people who can’t make it all 5 days.
There’s some other things we thought of and about:
- Asking OpenAI for a bigger venue. We did, they couldn’t give us one. (We’ll be asking more pointed questions of potential hosts in the future.)
- Passing on OpenAI’s offer to host and finding a new one. It’s very short days to get that done for this year, and we had no other offers.
- Cancelling the Core sprint this year. That feels spiteful at this point.
- Adding a second venue. This wouldn’t be that hard (I’m sure I can ask Meta for a 20 person meeting room for a few days) but would that really be effective? How would the logistics work?
- Ensuring online participation. We’ve tried some of this in the past, during Core sprints and online sprints, and it’s very hard to get significant external participants when you have a large group in the room already. Again, the logistics are hard.
- Maybe 40 is actually a better size, all the hard decisions notwithstanding, than the 60-ish we’ve had for the last couple of years. We’ve heard more than one complaint that past sprints were too big for comfort, and it certainly makes it much harder to find venues for the sprint and the social events that are usually organized.
- Leaving less of the Sprint organization to the hosts. The way it originated and evolved, way back when, means that the Core team and the SC wasn’t actually that involved in the actual decisions for most of the Core sprints. Each host gave its own interpretation to it, as well. That isn’t bad, but maybe it’s time for clearer up-front expectations, like venue size, host involvement, structure of the week, social events, etc.
Regarding transparency and openness, I’m personally not comfortable just throwing everything in the open here. We don’t know if people signed up to have their submissions scrutinized by the entire internet, or even the entire core team. As Savannah mentioned, we don’t want to open anyone up to harassment, guilt-tripping or even well-meant are-you-valueable-enough evaluations. And our deliberations, not just on this topic but in general, include quite a lot of information that was given to us in confidence. We definitely don’t want to be in a situation where people feel uncomfortable bringing issues to our attention because of how they’re then immediately public knowledge. There is quite a lot of discretion involved. Any topic, any decision, that would influence people’s personal or professional lives has to be taken with care and responsibility. I’m happy to explain how we made decisions, and I agree we should be as transparent as possible, but we can’t just do all our deliberations in the open when it involves individuals.
I’m not saying we did everything right with this sprint organization, or even just the attendee selection, but we did do our utmost to make it a fair, balanced list that prioritizes a productive Core sprint for as many people as possible even if that made the decisions much harder for us. That’s also why we took the selection away from Brandt, who would otherwise have had the dubious pleasure of deciding these things. Suggestions on how to improve the process, or volunteers to help organize next year’s sprint, are more than welcome.
and the Steering Council for making hard and uncomfortable decisions.
I devoted three years of service to the SC. Each current SC member is a good steward of CPython. I respect each of them, and my comments are in the spirit of improving things for the future.