Thanks Josh, really appreciate this. It’s something that’s been on my mind for a while, and I’d like to share my thoughts.
I’ll provide some context, and then where I propose we go.
To be clear, I am not attempting to force this idea on the Project, but I think proposing something might help us get going.
Reaffirm/Review the Code of Conduct
I think the first thing we need to do is to reaffirm the code of conduct.
Is it fit for purpose? How do we plan to enforce it?
One of the main issues that comes up time and time again is safety. We have lost more contributors due to safety issues than anything else - we must do better.
Our current structure is that of a do-ocracy: efforts are led by virtue of an individual spending the time and effort doing something, working on whatever they value most.
I believe this approach to organising ourselves has a large part to play in the current situation. I can’t speak for others, but in my experience:
- I don’t feel that I have permission to make changes
- I don’t feel that there is a process to get that permission
- Being led by individual efforts, I feel that there is no collective direction, so larger scale changes are hard if not impossible to orchestrate.
The do-ocracy means that everything is on everyone as an individual, there’s no collective, and that’s tough.
I think we need to admit that the do-ocracy doesn’t work.
Part of the reason I don’t feel I have permission is that I don’t have a sense of ownership - in the do-ocracy, I take ownership of the thing I’m doing if I’m adding something new, but what if it’s something that someone else wrote? I can’t take ownership of that, so I have to ask permission somehow - what if I don’t fully understand it and break it? How do I obtain a sense of ownership?
I get the feeling from the other threads that there is an issue surrounding membership:
- Am I a developer? A contributor? A user?
- Who are the developers?
- Who can join?
- How do I join?
- Is there even such a thing as joining?
I think any way forward needs to address these questions.
After, and only after, we have affirmed a code of conduct and related procedures, I think we can move forward.
The core proposal is that we create teams who are responsible for certain areas of the codebase.
One of SuperCollider’s strengths as a project (which is often viewed as a weakness) is that it has so many areas to contribute to. Are you interested in cross-platform gui applications? Are you interested in DSP? Are you interested in programming language design? Are you interested in writing great docs that help clearly communicate complex ideas? We’ve got them all, and I think that’s really exciting - there are so many ways to contribute!
The structure needs to model the project itself, so the teams I’d like to propose are:
- Responsible for keeping our spaces safe
- Responsible for the cross-platform GUI application:
- Responsible for the language and interpreter:
- Responsible for the core SC class library
- Responsible for the audio server and plugins:
- Responsible for the build system (CMake) and CI
- Responsible for our documentation and tutorials
There are naturally areas of overlap between the teams - the idea isn’t to lock people in certain teams, but to communicate ownership, one person can be a member of multiple teams, for example.
When it comes to code review, we can set GitHub to require approval from anyone in the corresponding team - “approved on behalf of the
sc-docs team by James S.” - this will help us gain confidence, and take the pressure off individuals.
I think the key thing to take away is that there’s nothing new in terms of the teams - all of these things have always needed doing, and they’re all equally important - I’ve just written it down.
Collective Decision Making and Ownership
The teams are about giving shared ownership.
The Project grants the team the power to make the decisions it thinks are in the best interest of the Project - no one individual is responsible, so no one person has to carry the weight.
We already have regular meetings, but I think we can structure these differently if we have teams.
If we wanted to keep 90 minute meetings, then I’d suggest something like:
- 60 minutes: teams in breakout rooms - team decides what’s most important for them and divides the work among the team
- 30 minutes: all together - teams present what they’re planning to work on, asking for input/help from others
- How to join a team - attend one of the meetings, join the breakout session
- Who can join - absolutely anyone
- What if I can’t code - come along anyway, your contributions are valuable to those discussions, and there are so many other ways to contribute to the Project that are equally valuable! But if you’d like to learn, see Mentorship below!
I’d like to propose that we adopt a mentorship approach, where anyone who would like to join a team can pair up with an existing member (or members) to help them learn and find their feet.
We have a lot of human knowledge dotted around the Project, it would be good to share it!
As an example of this, I believe the reason that the interpreter, and therefore the language, doesn’t get much attention is because very few understand how it works - I know I don’t feel comfortable making changes to that part of the codebase, pairing up with someone for a bit would really help build my confidence!
Or the pattern system - any time I see a PR for changes to patterns, I don’t understand enough to approve it.
But we also see a lot of people who would like to contribute code but don’t feel they have the programming skills - I’d be more than happy to pair up with anyone who wanted to learn some C++, for example.
The big issue with this proposal
There is a flaw with this proposal - it’s going to take a number of people to fill out those teams!
And I think that’s ok - if anything, that’s the goal!
We might start off with a small number, with some individuals in lots of teams, and that’s ok - the idea is that we have something we can grow, provided it’s safe. It must be safe.
A note on funding
You’ll hopefully notice that I haven’t discussed funding, or creating an official body, etc.
This is on purpose - I do not think we need these things.
To be absolutely clear: I will cease my contributions if money begins to play a part.
The Project will become about bounty hunting, and will bury itself in technical debt made by people who dip in and out to collect money - instead, we want to foster a community of developers who want to work together.
I am not in this for money. I’m in this to learn, to become a better programmer/colleague, to contribute to something larger than myself, and ultimately to make music.
- Make it safe
- Make teams that have responsibility for certain parts of the codebase
- Make joining those teams easy
- Make the teams choose their direction, with input from others
- Create opportunities to share knowledge
Shared ownership, shared responsibility, shared direction - shared goal.
- What do you think about the above?
- What teams would you be interested in creating?
- What teams would you be interested in joining?
For full disclosure, given my expertise and interests, I’d be interested in joining:
And I’d be really keen to mentor anyone that wanted to learn some C++, and be mentored by someone on the
sc-lang team to learn about the interpreter.
Sorry for the huge post, but this has all been in my head for a while.
Thanks for taking to time to read, and thanks for considering what I’ve written.