Move SuperCollider development into a council structure?

[dscheiba]

Status quo of SuperCollider development

SuperCollider is always in need of people who contribute - this can be done in various ways such as coding, reviewing, testing, reporting bugs, improve documentation and, last but not least, providing community work (see e.g. our open call for new moderators in this forum).
As SuperCollider is developed by the community I think it is important to have some transparency about the current state of development.

We already have some (good) documents on how to get started with development, but it it seems often unclear how a contribution can reach a final state where it gets included/actualized and not getting lost between impulse/implementation and actualization/merging.
I think this leads to a growing frustration within the (dev) community that certain changes take a very long time to adapt - and sometimes those very good ideas and impulses get lost in limbo, which I find very sad - and I’d like to change that.

Making implicit structure transparent

Having spent some time developing SuperCollider now, it seems to me that a major obstacle is the unclear situation of who can “approve” a change: who needs to be “convinced”, whose statement should be followed in case of contradicting comments from users within a discussion, who can I contact if I need more information, who can I ask for a review or feedback on an idea or contribution.

People who spend some time within the (dev) community will gain some implicit knowledge on who to contact for what - but I think it would be more welcoming if these implicit structures would be made transparent (e.g. I personally still don’t know who I can ask if I need to change something about our Windows build and would really like to have such a person instead of waiting for a person to come along by concidence).
I think this setup often leads to a deadlock situation where no one wants to pull the trigger b/c no one knows if there is someone else with more knowledge on the topic or if it might break something for another person (of course we never want to break anything, but development is not always that easy with changing CPU architectures, older code bases, OS and dependency updates, …).

But if we want to keep SuperCollider as a thriving project for years to come, we need people to step up and take responsibility in various ways.

Forming the councils

To break out of this cycle, I think it would be good to organize SuperCollider in a council-like structure: One or more people will be given the (temporary) authority by the community to make decisions for certain domains and to act as a contact person when a decision needs to be made within that domain.
They will therefore also have the backing of the community to make decisions for that area.

This will hopefully make the development effort more transparent and efficient, as it will be clear why a feature is stuck and how it can be resolved, as a person can be contacted about it.
It would also make transparent which parts of SuperCollider need help, as there may not be a person in charge of a certain part.

Acting as a member of such a council has no obligations in terms of hard time commitments, although it would be necessary to respond within a certain timeframe when requested (e.g. within 1 month, where the issue can then still be deferred/delegated to another person).

A first draft

Looking at recent git history, I would suggest the following structure as a first draft. I am deeply sorry if I have missed anyone - this is only a first sketch!
Please suggest people who you think would be suitable for a particular position - it is also perfectly fine to suggest yourself - this is a stepping up for the SC community!
Of course, please state if you don’t want to take a position (you can also DM me and I’ll remove your name from the list).

Last update: 2025-04-07 22:30 CEST

Community	Forum	scsynth moderators
	Website	capital-g (technical)
	GitHub	scsynth moderators
Code	scsynth	spacechild1 elgiano
	supernova	spacechild1
	Server plugins (no sc3-plugins)	josh scztt
	IDE / QtCollider	dyfer scztt james
	sclang	Jordan Henderson scztt
	class library	jamshark70 muellmusik telephon
	SCDoc	tedmoore
	CI/CD	dyfer capital-g
	Infrastructure & GH Organization	jrsurge dyfer
Platforms	Linux
	macOS	capital-g (Intel) josh (signing)
	Windows	spacechild1
Documentation	Tutorials	tedmoore girthrub
	Class documentation	tedmoore girthrub

It is clear that certain spots are blank which shouldn’t be blank - maybe this is an interesting insight for people who are not too involved in the development about the current status of the project.

Maybe such a setup would also allow us to get some people with a lot of seniority involved in the project (again), when asked what and how they would like to contribute again?!

Getting in contact

Having a list of people in charge is the first step - there still needs a way to contact those people.
Sometimes it is clear how to contact persons - accounts in this forum can be DM’d or mentioned, on GitHub accounts can be mentioned/pinged.

Yet I think it would still be beneficial to additionally have a small kind of private mailing list in order to coordinate and contact people if something important is happening (b/c I know from myself that I loose track of some GitHub notifications over time…).
E.g. I would have appreciated to coordinate this effort with some other devs, but I don’t know how to do this currently.

Until we find some good way I’d propose a private document where the mail addresses are stored and people from within councils can look into it and use these mail addresses.

Next steps

I know that many people may disagree with such a proposal and setup, and hopefully there will be some discussion about it.
But also post if you agree with this, because it would be really devastating if this thread had only one or zero replies.

As this is an issue that is very close to my heart, I will also raise it at the upcoming SuperCollider Symposium next week, as I think this is a crucial issue for the future of SuperCollider.

However, as the SC community is not limited to this symposium (but also not to this form), I thought it would be more beneficial to ask the community in advance, so that the community’s input can be discussed and taken into account during the symposium.

I’ll do my best to give a summary of the different perspectives posted here at the symposium, and I’ll update this thread after the symposium as well.

I hope we can maybe agree to such a structure of responsibilities within this month - the list itself would always be open to change but should be accessible publicly (e.g. sticky post in the dev forum?)

---

In the end: Please feel free to step up and contribute to this awesome project! This is a great community project and it needs people from within the community.

[jamshark70]

I think division of labor is essential: it’s daunting for any one person, or committee of 2 or 3, to take on leadership for every aspect, and if that’s where we leave it, then the PRs aren’t going to move forward.

Probably at least at first, there would need to be a small group of coordinators as well.

I don’t have a lot specific to add to the proposal, just that I hope this gains support, and traction, and action.

hjh

[jordan]

Great work!

I just have some queries about how this could/would be integrated into GitHub? We already have the tag system for prs, but only the approved can add them - perhaps more pr templates? Is it possible to say, automatically assign someone based on a tag? Could projects be used instead, this might make things seem like less of an obligation on an individual, and more of a collective responsibility belonging to that part of council - this also makes things more transparent?

[julian]

I like it! We could even add a little more detail when it comes to different subfields, especially in the larger areas? It may be good if people who have questions can reach out directly to a person who knows about an area (I often do this, but this knowledge is accumulated over a long time).

[semiquaver]

This is a great idea - excited to follow along and help where I can.

[Spacechild1]

Thanks for this important initiative! As @jamshark70 already said, division of labor is crucial for a project of this size. I am happy to take care of scsynth and Supernova issues! People can also ping me about Windows issues, since that is my main platform, as long as it’s not about CI.

[amindfv]

I’m going to provide a bit of a dissenting view, but I appreciate your work on trying to formulate a way to address dev issues.

As someone who can probably count myself as a former SC developer (but still a frequent user), I feel I might be able to provide insight into the types of people who could be contributing but aren’t. In my case, part of drifting away from development was ironically the periodic pushes to organize the developers and dev work. There have been a handful of attempts to come up with a great Official Structure, and that’s (again, imo) been a major distraction and impediment for actual dev work.

The tl;dr is: IMO, the biggest problem for SC development is limited dev hours, and formulating official committees, etc. is a siren call which periodically ends up eating up a lot of those hours, without solving users’ problems.

Committees can be anything on the spectrum between a powerful organizing force and a nightmare of paperwork and politics. Forming a committee isn’t, in itself, a solution to the problem of dev backlog.

Having spent some time developing SuperCollider now, it seems to me that a major obstacle is the unclear situation of who can “approve” a change: who needs to be “convinced”, whose statement should be followed in case of contradicting comments from users within a discussion, who can I contact if I need more information, who can I ask for a review or feedback on an idea or contribution.

“whose statement should be followed in case of contradicting comments from users within a discussion” is important: if the goals are inclusivity and transparency, I can’t see how having small official committees picking winners and losers here will help.

People who spend some time within the (dev) community will gain some implicit knowledge on who to contact for what - but I think it would be more welcoming if these implicit structures would be made transparent (e.g. I personally still don’t know who I can ask if I need to change something about our Windows build and would really like to have such a person instead of waiting for a person to come along by concidence).

This is a good concrete example. I think it illustrates a few opportunities and possible pitfalls.

First, division of committees: if (for the sake of argument) there’s a Windows Committee and a Build Systems Commitee, what if they disagree? Not all bugs and features fall cleanly into one category, and giving people Titles can cause friction too.

Second, and more directly related: I agree this is a problem: I’ve written some code, who can/needs to approve it?

I’d advocate for a solution which minimizes process and procedure. For example, there could be a list of people who are “willing reviewers.” If you want to merge a change, you should e.g. tag at least 2 of them on GitHub/Discourse/whatever. If they believe other reviewers would be better for the job, then they can tag others. There should be a responsibility to contact people who are interested, but no official fiefdoms of decision-making. If your problem is “I don’t know who to ask,” the solution is to give devs permission to ask one dev to help them find other devs. The world of SC devs is definitely small enough for this.

Lastly, committee structure seems like it might be a distraction from the core problem: if you don’t know of anybody who can verify changes to the Windows build, perhaps there are simply no SC devs who have the skill and free time to master the Windows build system? Having a committee structure will not, in and of itself, cause this “person to come along by coincidence,” as you say.

I think this setup often leads to a deadlock situation where no one wants to pull the trigger b/c no one knows if there is someone else with more knowledge on the topic or if it might break something for another person (of course we never want to break anything, but development is not always that easy with changing CPU architectures, older code bases, OS and dependency updates, …).

My spidey sense is going off, that having a small number of benevolent dictators being appointed to break through the difficult problem of “we don’t know if this will break something”… will result in more breakages and more user unhappiness. Like it or not, a lot of progress is slow because people have strong opinions on both sides of an issue. Not every change is an improvement. It’s important to separate stagnation from deliberation.

In the Haskell world a few years back, a huge change was made by committees of elite devs working on their own, in their own private mailing lists. The changes finally arrived to the end-users and there was a huge uproar. Committees working out of the public eye came up with changes that were non-controversial to them but were extremely controversial to the wider userbase. (If you’re interested, look up the foldable-traversable proposal). The lesson is: develop more in the open, not less.

To break out of this cycle, I think it would be good to organize SuperCollider in a council-like structure: One or more people will be given the (temporary) authority by the community to make decisions for certain domains and to act as a contact person when a decision needs to be made within that domain.
They will therefore also have the backing of the community to make decisions for that area.

I think this should be highlighted more clearly: in order to keep things moving, the proposal as I understand it is to have different departments, each with one or more benevolent dictators (I use this term non-pejoritavely) who can decide things unilaterally. There are pros and cons to this, but it shouldn’t be buried in the middle of a long document. It’s actually a pretty big departure from how things have worked in SC previously.

This will hopefully make the development effort more transparent and efficient, as it will be clear why a feature is stuck and how it can be resolved, as a person can be contacted about it.

Again, there are other ways to ensure “a person can be contacted” without giving that person complete decisionmaking power.

Acting as a member of such a council has no obligations in terms of hard time commitments, although it would be necessary to respond within a certain timeframe when requested (e.g. within 1 month, where the issue can then still be deferred/delegated to another person).

I agree giving specific timeframes could be an improvement. It makes no sense to wait indefinitely to merge a change simply because a person who is nonresponsive might, we fear, have an objection to the change.

Yet I think it would still be beneficial to additionally have a small kind of private mailing list in order to coordinate and contact people if something important is happening (b/c I know from myself that I loose track of some GitHub notifications over time…).

I’m confused about how the proposal intends to increase transparency and “welcoming”-ness by forming a private, “elite” mailing list. Not having a clear in-group with privileged information seems like a better way to have transparency.

If there are too many Github notifications, that seems like a better problem to address.

I’ll end with a story: one of the contributions I’m most proud of in SC was what might be termed “stagnation” to an outsider. There was a pull request on Github, years ago, for adding Windows support for something by replacing an existing dependency with something more cross-platform. It was given a “looks good to me” comment by a senior dev (if we had committees, they probably would have been the one-person Committee for this area of the codebase). It was ready to merge. I was much more junior (I would certainly not have been on the committee), but I got curious and did some digging into this new dependency. I saw that it had many security holes and issues of its own, and commented on the PR. To the credit of the senior SC devs, they took my thoughts seriously, someone else dug into the code and they ended up agreeing with me. The code didn’t get merged, and the original dev understandably said “fine, but I don’t have time to implement this feature again with a different dependency.” The code never got merged, and as far as I know Windows support was never added. But! We kept some very serious problems out of the codebase. The person who originally proposed the merge could easily say “SC is full of stagnation, I put hard work in and the it never got merged,” but that’s missing a lot of the story.

[jamshark70]

@amindfv

In my case, part of drifting away from development was ironically the periodic pushes to organize the developers and dev work. There have been a handful of attempts to come up with a great Official Structure, and that’s (again, imo) been a major distraction and impediment for actual dev work.

I’d say the details of the structure are less important than getting hands dirty and just doing stuff… the unglamorous stuff… working through the backlog.

I think it’s helpful here to have some sort of group push. I’m not going to do it by myself, but if I know there are 4-5 other people also chewing through some of the PR backlog, then it may be easier for me to find an hour or two here and there.

In that sense, I agree that over-engineering a council structure is probably not necessary – but I do think we need an “us” getting moving, not an “I.”

hjh

[muellmusik]

Hi all,

Generally speaking I support this idea. I also thank @amindfv for the useful counterpoint. One thing to draw from that is that we should keep the organisation and management of whatever structure lightweight as they’re right that not enough dev hours is an issue.

In terms of the general problem I would diagnose things slightly differently though: I think the current loose structure inhibits decision making, leads to stasis in many cases, and rather than enable quieter voices misrepresents community views by over amplifying a few highly engaged voices. (This is a normal problem with social media of course…) As such decisions often either don’t get made, or become an unreasonable load falling on the “lead developer” (when we’ve had one) or “community leaders” as it’s just unclear who should be deciding.

So I do wonder if a structure that empowers a broader range of decision makers might be helpful, and if an occasional wrong decision might not be a reasonable price to pay for that.

My 2 cents anyway…

[jamshark70]

@muellmusik

So I do wonder if a structure that empowers a broader range of decision makers might be helpful, and if an occasional wrong decision might not be a reasonable price to pay for that.

I think this is dead on. +100

hjh

[amindfv]

(Adding a few replies, but again, feel free to ignore. My 2 cents only.)

I think it’s helpful here to have some sort of group push. I’m not going to do it by myself, but if I know there are 4-5 other people also chewing through some of the PR backlog, then it may be easier for me to find an hour or two here and there.

Sure! And if the proposal were “hey, let’s form teams and attack some high-impact issues together!” I’d be cheering right along (and possibly considering rolling up my sleeves and helping).

However, taking a look at the Issues and PRs, my takeaway is not that the missing ingredient is lack of committees. With most open PRs more than a few weeks old, I see some variation of “I’ll finish this when I find the time.”

There are real bugs on the issue tracker that are going to be teenagers in a couple months, and that’s just the age of when they were imported from the previous bug tracker… Again, my 2 cents is that the focus has to be “hey, who wants to help improve plugins?” and building on-ramps for casual users to become devs, not building processes to decide “so-and-so is now the plugins Decisionmaker.”

So I do wonder if a structure that empowers a broader range of decision makers might be helpful, and if an occasional wrong decision might not be a reasonable price to pay for that.

To be clear: this is the point I’m trying to make too. If there’s a user-facing problem that’s held up by a few vocal personalities disagreeing on Github, I as a SC user would much prefer the instinct to be “hey, let’s ask the casual users what they prefer,” and not “let’s ask the benevolent dictator to pick a side.” (Again, not using the term pejoratively). That to me would be “empower[ing] a broader range of decisionmakers” in the best way. It might even inspire some casual users to peek behind the curtain and get involved in development?

an occasional wrong decision might not be a reasonable price to pay for that

Fair enough, although important to remember:

• Security: We have a (dare I say moral?) responsibility to not expose users to security vulnerabilities, and
• Quality, both of code and of design: Closing one issue now, but causing 3 (or 10) more issues to pop up in the future is still a net drain on the system

If everybody finds a committee structure to be motivating, please don’t let me slow you down! But I have the feeling we’ve been down this road a few times before, and there’s at least one dev (myself) who’s more inclined to sit on the sidelines.

[muellmusik]

Replying with my mod hat on:

@amindfv

and not “let’s ask the benevolent dictator to pick a side.” (Again, not using the term pejoratively).

If not for perjorative reasons, why use such a loaded term? Using it is definitely not conducive to an inclusive and constructive discussion. Please consider other wording.

[muellmusik]

I think there are two problems being raised here:

1. the difficulty of making decisions in a vague and decentralised governance system. (In some senses perhaps just no system at all.)
2. engaging people to be active as developers.

Though these may overlap, I don’t think they need to conflict. Indeed, seeing that decisions are being made and progress happening might do a lot to engage potential developers. People like to volunteer on projects where they feel their work will contribute meaningfully. We hear often that people got discouraged when things languished in indecision.

But having someone who is responsible for on ramping people and/or just keeping an eye on PRs to prod them might be good ideas. (Some of us have done this informally.)

Also I don’t think we’re talking about dictators – really I hope this is the last time that word appears in this thread! – but really people taking responsibility for areas, and for gathering together relevant views. Yes, they might make a decision, but that doesn’t mean it’s irrevocable or that those positions never change. In many cases it matters more that a decision is made rather than that it’s a or b. Catastrophic mistakes are rare and often the disagreements are on nuance.

Gathering views should include canvassing casual users as appropriate and where possible. But, I think we shouldn’t assume that would always improve decision making. Some things require technical expertise or knowledge of design goals and history. And many things don’t really matter to most users so long as the solution works.

There’s also the point that we do already do engage them in various ways. Often the usual folks are the ones who reply. It might be possible to engage more people, but that may also mean a significant additional workload.

[Spacechild1]

Just to give a practical example: I occasionally contribute to SC, give advice or review PRs. But to this day I’m not really sure who is actually “allowed” to review or merge PRs (including myself).

Our current policy is that every PR needs at least one approval, but the merge needs to be done by someone else (to get a second pairs of eyes). This means contributors need to find two people who are willing to take care of the PR. Thus it would be very helpful to have a list of people that can be contacted/assigned for various areas.

If I know that I (among others) am “in charge” of scsynth, it would give me more piece of mind to merge (approved) scsynth PRs.

To be clear: I am mostly talking about non-controversial changes like bug fixes or small features. If someone proposes a (non-trivial) feature or a breaking change, there absolutely has to be consensus among a larger group of people, possibly including regular SC users.

[Spacechild1]

Another thing: IMO outside/casual contributors should not have to be aware of the internal organizational structure; it is the job of core members to regularly go through PRs and assign other core members (or themselves) based on the PR labels. In other words, the list of possible reviewers should probably be a guide for the core members, not for the contributors (unless they are core members themselves).

[scztt]

I generally agree with the sentiments of this thread, and some of the counter arguments. I hope we can rally some around these topics. I would especially underline @amindfv’s point: the most fundamental problem historically has been a lack of developer time. This spirals into all kinds of side-issues (e.g. some things @muellmusik brings up): when there IS developer time, it’s often disproportionately on single contributors - when the person in question is already on the “inside” of the dev process, it can easily make for burnout / frustration feelings as time goes on, and create friction when other people feel like they aren’t included or can’t keep up with fast-moving efforts. When they are on the “outside”, it creates frustrating situations where PR’s sit forever and momentum is stalled, and often a contributors “window” where they have extra capacity is simply missed by a slow process.

I think organization and process can help make this all less frustrating and unfriendly, but it can’t solve the capacity problem: process means people that will put time towards reviewing, triaging issues, sitting on developer calls etc. This has SOMETIMES been the case historically, and sometimes not - a process discussion requires a critical mass of people actually working on that process, so in a way solving the capacity problem has to be primary? Maybe there is enough capacity / invested people now to make meaningful progress on this (without it being a total slog…) - if there’s not, this is more of a social problem of rallying support.

[scztt]

I have capacity in the next few months, I can volunteer to facilitate regular dev meetings and try to jump-start some process around this if it’s helpful. This would be with a intention to building momentum so that other people would also be able to take on this role.

If this is interesting, please let me know and I’d be happy to take on the work of scheduling something in the next week and getting the ball rolling.

[Spacechild1]

IMO the dev meetings have been very helpful in the past! Often it is much easier to coordinate/discuss things “in person” than in GitHub threads. One thing I found particularly productive was going through all open PRs together and trying to triage them. Would be good to do another round while the number of PRs is still a two-digit number

[amindfv]

@amindfv

and not “let’s ask the benevolent dictator to pick a side.” (Again, not using the term pejoratively).

If not for perjorative reasons, why use such a loaded term? Using it is definitely not conducive to an inclusive and constructive discussion. Please consider other wording.

I was using the term in what I believe is its generally accepted FOSS meaning. Wikipedia list 50 projects – including some of the biggest open-source projects in the world – using the term to refer to themselves non-pejoratively.

Looking over my shoulder, at risk of being told, authoritatively, things like I’m “definitely not [being] conducive to an inclusive and constructive discussion” when I’m trying to politely reply to a proposal in earnest is another reason I hesitate to return to SC development.

The original proposal:

One or more people will be given the (temporary) authority by the community to make decisions for certain domains

Wikipedia:

leaders […] who retain the final say in disputes or arguments within the community

From Homesteading the Noosphere:

The simplest non-trivial case is when a project has multiple co-maintainers working under a single `benevolent dictator’ who owns the project. Custom favors this mode for group projects; it has been shown to work on projects as large as the Linux kernel or Emacs, and solves the ``who decides’’ problem in a way that is not obviously worse than any of the alternatives.

My summary:

the proposal as I understand it is to have different departments, each with one or more benevolent dictators (I use this term non-pejoritavely) who can decide things unilaterally. There are pros and cons to this, but it shouldn’t be buried in the middle of a long document.

I think I’ve had my say (and don’t want to derail the discussion), but I don’t appreciate what I perceive to be the SC community’s hair-trigger approach to accusations and callouts.

[amindfv]

IMO the dev meetings have been very helpful in the past!

Dev meetings I wholeheartedly support! (In fact, if memory serves I think it was myself and Nathan Ho who started them, years ago… )