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).
| Community | Forum | scsynth moderators |
| Website | ||
| GitHub | scsynth moderators | |
| Code | scsynth | spacechild1 elgiano |
| supernova | spacechild1 | |
| Server plugins (no sc3-plugins) | mtmccrea | |
| IDE / QtCollider | dyfer | |
| sclang | Jordan Henderson scztt |
|
| class library | jamshark70 muellmusik telephon |
|
| class library test suite | elgiano | |
| SCDoc | ||
| CI/CD | dyfer capital-g |
|
| Infrastructure & GH Organization | ||
| Platforms | Linux | |
| macOS | capital-g (Intel) | |
| Windows | spacechild1 | |
| Documentation | Tutorials | |
| Class documentation |
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.