I favor @jrsurge 's idea of standing up groups as a way of both increasing the number of participants ( ( Lucille’s point (b) ) and also partitioning discussion and effort. Ideally this would free up time for the most senior devs (who should probably form a meta group).
Support and onboarding become more efficient with groups as information can propagate.
Groups would also present a clear ladder of technical difficulty - moderation/docs < classLib < server < lang for example - a helpful path to bring ppl in.
This thread began with enthusiasm from people who aren’t currently contributing, that should be exploited rather than tamped down!
Reading responses form @dscheiba and @lnihlen it seems one question is how to respect and best make use of developer seniority and earned authority in this scheme - Two thoughts:
Perhaps groups could be expected or required to include at least one and/or be sponsored by a senior “trusted” person.
Or groups could include a designated chair who’s authority could be accepted and revoked by some collection of more senior devs outside the group.
I think this ladder thinking could suggest a false sense of difficulty, complexity, or perhaps even value.
Everyone should be invited to contribute according to their interest and ability, thinking in a hierarchy suggests a prioritization that IMO interferes with such a credo.
If you have never programmed before, but are interested in DSP programming, who am I to tell you that you should start somewhere else? Curiosity is the best driving force in learning, and we should encourage that as much as possible.
Revisiting the idea of multiple BD within each domain of sc: I think it comes from the experience that it is much easier to have a 1:1 discussion than a 1:N / aka group - especially in technical domains.
Of course, this can lead to abuse of power and privilege, but it also seems to be a very efficient use of resources (something that seems necessary?), but I think a group/council can make sure that this assigned person operates in areas that the group considers desirable behavior.
A core question should be why there seems to be a lack of contribution (at least that is the motivation I read from the post)? Is it because people don’t feel included or because of the organization of the contribution? [assuming it is possible to separate them].
Personally, I think you are doing a most excellent job in the area of inclusion and transparency (this discussion is a prime example), and my suggestion would be that the management and structuring of the contribution could be improved.
At least the vagueness in/of feedback and the bureaucracy due to the 1:N setup is what frustrated me during contribution and is the reason I paused contributing, but after all I would really like to include some new ideas and do some maintenance work within the SC framework.
@josh - you asked the scsynth community for feedback, but what does the “dev council” consider to be a goal or next action within this discussion?
I’m hoping - to be honest - that a sort of dev council forms from this conversation, and the current people doing dev figure out how they can contribute to it.
I like the suggestions of forming teams, and I’d be very happy to be part of the scsynth / plugins group. So - how should we go about this? Should we just try this route and start organizing? One path forward may be making the initial groups as a thread here with a welcome message and listing the scope of that group - then go from there.
I would like to pick up this thread because the future of SC development is very important to me. I am using SC now for more than 20 years and grew very fond of it. I feel like I have become a reasonably experienced user, not least because of the great support from everybody in this forum.
I am using SC on macOS and Linux. On the former I run it with the native JACK backend, which is why I have to build SC regularily myself. I also tinkered with implementing and testing some features I would like to see in SC, both in the language and the server. So I have some basic notions of the code base.
If there was a possibility for me to directly contribute to the development of SC, I would be happy to get a chance to grow into such a role. The idea of developer groups who coach less experienced members is very appealing to me - I hope these will materialise and function well. As I am going to retire in a few years, I will soon have more time to spend on coding.
I also hope that this thread will pick up speed again and SC development will have a successful furture!
yes indeed! @josh would you be willing to lead things off by posting an initial thread for a scsynth/plugins group? I think it would be encouraging to all to see experienced people launching these efforts! Members could be encouraged to subscribe by clicking the bell - and if the group became sufficiently active multiple threads could be started and tagged with the group name perhaps.
One concern that both @jrsurge and @lnihlen stressed is safety - I think it would be good to stand up a CoC/moderation group alongside this first dev group. If there is any chance of giving previous developers the confidence to to re-engage it would be great!
Anyone interested in joining the first Dev group - to focus on the class library - @jordan has started a thread here: Class Library Developer Group.
As there has been a lot of discussion in this thread about the importance of seniority and earned authority I hope some of our senior devs will head on over there and help get the conversation started!
I do think that we should stand up a group to look at the CoC and moderation - if @jrsurge or anyone with more experience here would like to get that started I’ll defer - otherwise I’ll put together a post a little later…
I jumped on board for helping with development during the pandemic, but unfortunately my personal life exploded and I got real sick about it for a few years. I’m back now, and I’m wondering who to talk to. It looks like things got kind of unwieldy last year.
Look, the do-ocracy is most accessible IMO. We can teach each other and learn from each other by doing. I’ll make a pull request, I’ll get feedback from developers at all levels, and at the end it’s either accepted or rejected. If my efforts stagnate, others can clone my in-progress work and flesh it out, and my name still appears in the contribution history (if people take care to use git correctly).
I care deeply about accessibility in tech, both the commercial industry and the practice. I’m one of the marginalized. I’m disabled and can’t work full-time. I am a very competent dev but I don’t have the educational or class background, and the US South is a socioeconomic war zone. I lost 3 people last year. I have gotten stolen from when I tried to freelance. I could get better work based on the portfolio of contributions to SC I am building, but I wouldn’t want it! It’s all for-profit medical, petro, and war! My entire culture is rotten!
We work in a hostile environment. It’s a ton of work to build bridges to each other and focus on value and creativity, and you’re gonna watch some of what you build get destroyed so cheaply… I’m not into religion, myself, but I get it. There’s no absolute solution. We have to do our best and let forces more powerful than us sort out the rest.
But at the end of the day, for me all this extra rhetoric is just an additional accessibility barrier. Talk is cheap. Let’s go back to Github and tear into it. And if people need money to stabilize their lives so they can contribute, give it to them. If people dislike/have enough money and want to trade on value alone, that’s fine too. My late sister used to say “get in where you fit in”. We have a lot to learn from each other and a lot to build together. Don’t be shy, let’s get back to it. The war pigs don’t have to come after us with guns if they got us with drugs and drama. Avoid fear, shame, and dogma. Let us creatives create.
The Class Library Dev group and the Server Dev group each met a couple of times last year and there were some (I thought!) super interesting discussions and initiatives. Later at a general meeting the fear was expressed that setting up multiple groups might fracture the community so it was decided to fold the groups back into a single thread - the plan was that meetings would be held weekly with a rotating focus. This scheme persisted for maybe a month but sadly there have been no meetings at all this year.
Its heartening to see an uptick of good things happening on Github and esp to see new blood starting to stretch out there… But one shortcoming of the Do-ocracy I think is that its hard to coordinate a larger vision or to triage scarce resources. And a good number of worthy efforts seem to be stalled due to a lack of decision/review. Even if meetings might mostly be a time sink, it is nice to see who else is doing stuff and to be able to make some quick and dirty decisions in a face to face setting.
So I wonder whether there would be any purpose in restarting the smaller Dev groups? or whether ppl feel like the scene at Github is sufficient?
As stuff scales up, I can see more organizational infrastructure being handy. But really it’s about communication with the users, and since this is a programming environment there’s overlap between users and maintainers but not fully, so we still need to reach the users.
So questions like “Does your code use this library?”, “Do you have any thoughts about these proposed changes?” could appear in polls and discussions in the Discord/Slack/here. But yeah even that is like, a lot of channels to check. Keeping the technical discussion next to the code can help a lot.
I’m currently doing a big push of updates to the HID subsystem of sclang, which I personally use heavily. So it’s somewhat on me communicate my ideas and get feedback. I’ve been putting most of that content on Github and then I can link to it on these other channels.
If anybody joins me, then we become a de facto working group. I think the thought I’m trying to express is that this sort of thing is emergent, not contrived. We negotiate as we work. If you wanna know what’s happening with SC’s development, watch the code and issues. And if we discuss something on another channel we can always drop a link to it on an issue/PR comment.
Off-topic: I’m seeking funding for my work because I’m disabled but don’t have my shit together and am not on government assistance, and my tech career aborted before I could build up savings. Refer me a disability lawyer, and buy me some groceries in the meantime: https://fundrazr.com/42MvCf
Oh and about stuff stagnating because there’s not any feedback, maybe that implicitly means “go for it according to best practices” – so like if you make backward-incompatible changes to an API, bump the major version as a clue, but it’s okay to move forward.
I’d be confident triaging some Github stuff, I’ll watch out for the next few dev meetings and get to know everybody. I have some professional experience and a deep love of the craft. I just move slower than a commercial dev, and sometimes I get sick for awhile. That’s life, it’s not like we’re trying to impedence match with the market anyhow. My whole soapbox here is we don’t have to try so hard and we can go ahead and express ourselves.
There is a rich diversity of backgrounds and expertise. From engineers who are great performers, to composers who, over time, entered the art of computing. But people are shy/disconnected/focused on their projects. If there is some kind of renewed collective organization where everyone helps or guides each other, we can have a positive phase now, in terms of taking care of the project and forming our community ethos.
In a recent discussion, one contributor expressed both support and skepticism about the inclusivity in the SuperCollider development community. They commend the idea of broad inclusion but are concerned about the effectiveness of a diverse group in making sound software engineering decisions. This viewpoint seems contradictory, as highlighted by their comment: “While in principle I support the effort to broaden the inclusion of folks with a diversity of knowledge levels and skills, I don’t think that such a broad group is necessarily empowered to make the right decisions about software engineering topics.”
(Let’s find out what they mean using the word “engineering”)
Additionally, they discuss concerns that the community has historically not placed enough emphasis on software “engineering,” which they believe has contributed to the technical debt burden that SuperCollider now faces. This perspective suggests a preference for a more structured, merit-based system where authority in decision-making is tied to significant contributions. As they mention, “I would prefer to explore a model commonly seen in open source [SIC] that is one of earned authority.”
This sounds very contradictory to other conversations, with SuperCollider history and communal ethical life.
While their concerns about maintaining high standards in software “engineering” are valid, it is worth considering whether a more inclusive approach that embraces the huge variety of talents in this community, that could be guided and result in contributions at all levels of the project could not only enrich the development process but also create a more dynamic and community.
Another feedback that surprised me was how collaboration and guidance can become an “emotional burden”. Do more people feel this way? In any case, this is a highly individual discussion.
This approach should NOT forget to address recent concerns about the project being frankly *stuck. I wonder how formal is this distinction, they mean real engineers with a solid academic formation in mathematics, calculus, formal logic, all the good stuff, etc? or those with coding jobs? what is that exactly?
Anyway, nobody checked in much code in those more conservative “how-can-you-be-on-the-council-and-not-be-a-master-?” times, those with and without a PhD did not contribute much code. The vibe just contributed to the situation, I think. Most of the changes were not relevant and out of touch with the community. From the top of my head, I remember a discussion on changing the NAMES of functions and variables or changing the name of git branches.
That’ 's OK if people want to do this. I was just waiting to see the big engineering work. This " engineering" is the result of one person? Shouldn’t it be developed on a much higher level with all the leadership? Is it really about " engineering"?
That is clear among physicists debating real physics. The distinction between those who can discuss physics is very clear and those who don’t understand deeply math. The conversation is impossible in this case.
But, is that the case between us? People have all kinds of formal education and experiences here. Let’s be more careful.
EDIT: If you don’t want to engage in this kind of discussion on this forum, or prefer meeting online or another format, you can just reply by answering this question: What is the development culture and ethics and you want for SuperCollider? Reply in a respectful tone what is the vision for the community that you would like to see.
yeah, thanks a lot for bringing that up. I do see various levels of naivete, and I’m sure I also display it to some more senior engineers. I can’t wait to learn more, and share too.
It’s important to note that the cultural/demographic bias among experienced engineers is a systemic problem with much greater scope than this project. I’m white and male-passing and really good at code-switching to corporate-engineer, and even I still get marginalized. This is a generational task, we’re just one grove of trees in a whole ecology.
That’s why I’m saying that although it’s important to build an inclusive, mutual-mentoring, playful and creative culture, it’s OK to acknowledge that we’re not yet the majority and we don’t have to solve this systemic inequality ourselves. Furthermore, SuperCollider itself is a powerful tool for communicating these technical ideas/practices/knowledge. It’s OK if, for example, a squad of industry-vet American White Males do some heavy lifting for a few seasons to bootstrap things/keep it unstuck, because the work is being done in public and the tools we’re using and creating are accesible to everyone. The GPL requires that you release the source, all of our communication is done in public. This is public education. If it’s not accessible to you now, it will be within 5 years if you lurk with us, and reach out if you need support. This software stack isn’t simple. I myself have been lurking in these spaces since 2015.
We need more trust. We’re aligned on the long games; artists have always been the global communicators. Art is our most ancient information technology. The internet just reduces latency. Just had a thought: It’d be interesting to see an initiative to translate our work into other languages.
I always felt that SC community has high ethic standards. I’ve seen the discussions around Code of Conduct many years ago. I’m proud of change from Pstutter to Pdup. It means a lot to me that there is no master branch but a ‘main’ branch. Politics like that are important to me. I rather have a less polished, a bit chaotic and slightly inconsistent programming language with a community where I feel people of all kinds are accepted (and minor contributions are kindly aproached) than a highly polished software with authoritative leadership that is either ignoring or scornfully rejecting contributions from less-capable devs.
I once tried to contribute something into documentation, it was more or less a corrected typo and took a wrong approach of editing it on github. I was rather dryly and non-verbosely instructed otherwise and it took me quite a while to understand git and branches and that I need to clone the whole codebase first to my drive, make a branch, add my correction, git push it to my own repo and then submit that as a pull request via github. it felt so much work for someone who has infrequent experience with git for a small typo it was quite offputting.
Some other (later) time I was treated less dryly, I admit.
I’m aware all development is purely volounteer work. I understand that crowdfunding efforts were somehow not suitable for this community. And perhaps it is better so.
I also think about how mastodon is developed - there’s a great dev in germany who makes all decision by himself and too often decides against an outcry from the community (users and devs alike) of queer and non-white minorities. at least that’s my impression after being on mastodon (and running 2 or 3 instances) for 7 years.
So, my bottom line: I have high expectations that development culture of SC remains or becomes even more sensitive to these ethical and political questions. I feel that technology is much more beneficial to society if it has this kind of politically-aware context - a context of solidarity and mutual aid, kindness and awareness of problems like racism, misoginy, transphobia, ableism. I don’t know if from what I wrote there’s anything useful for the problem at hand. I also want to say that I believe it is quite possible that a more diverse group of devs is less effective, I really don’t know. I just feel that “collaboration and guidance” is one of many aspects for a just society and community. I don’t believe in meritocracy or ‘earned authority’ as something that reflects where we as society need to go/be. I SC community to be less about effectiveness and competition and innovation, and more about collaboration, diversity, and social responsibility.
I appologise if my comment is completely out of touch with what is being discussed here (you know phyisicits discussing real physics, or real engineers).
I wonder if anything could be done about this. Does anyone have any thoughts/technical insights about making the ide allowing editing of doc files and easily submitting a pr?
Doing it that way would be a bad idea, as the documentation in your IDE may not be in sync with the develop branch. It’s also a lot of work.
For documentation I think a better approach would be to write a script/tool that automates the process for people. And maybe there could be a link to that in the documentation itself?
I think it is good to remember that the people who work on SuperCollider are donating their free time unpaid. And that one of the principle reasons that SuperCollider is "stuck’ is that there are not enough people with the technical skills to do much of the work that needs doing.
I’m not involved in the project, but I’d guess that the following are what are needed. You want to get the project moving, contribute where you can with these:
Find C++ developers, particularly developers willing to work on an antiquated code base who have experience with RTAudio/compiler development.
Find people with experience in CMake/build/deployment stuff.
Project Management
Find people willing/skilled in automated testing.
Find ways to take the load off the developers so they can focus on coding:
Mentor/assist people who want to write documentation, or do SuperCollider contributions, and look for ways to make that easier.
Additionally, they discuss concerns that the community has historically not placed enough emphasis on software “engineering,” which they believe has contributed to the technical debt burden that SuperCollider now faces. This perspective suggests a preference for a more structured, merit-based system where authority in decision-making is tied to significant contributions.
The SuperCollider code is old and has a lot of technical problems. I take this on trust from the people who did the work. Some people worked very hard on fixing the technical debt (Moss Heim in particular) - which is a non-glamorous and not particularly fun job. I don’t think it helps anyone to imply that this is unnecessary. Unless you’ve worked on the code (or perhaps have extensive experience working on maintaining aging code bases), then I think maybe consider that they know stuff that you don’t through their extensive experience of doing the work.
I also think it is perfectly reasonable that the people who do the work get to make the decisions about what should and shouldn’t be a priority for them. If you think the priorities should be different, then learn C++ and work on the things you think are important.
Maybe take a step back, think seriously about what you’re demanding here and then maybe think about how you can contribute in a positive way to this problem, using the skillset you have. Or alternatively if you’re not willing to contribute, then perhaps don’t criticize the people who do.
Generally open source projects that are successful have someone who does a lot of what is effectively project management. For anyone who isn’t very technical, but has good interpersonal skills, that is a really useful way to contribute. Basically your job is not to lead, but to make things run efficiently and to remove obstacles that prevent developers from coding.
@Jordan@cian
Using vscode, we can find and replace strings of the files in a folder and all its subfolders.
So the development branch can be copied into a folder on a user, and then she/he/they can edit documentation when finding a typo by finding and replacing the string across files, then synchronise it.
