I think we just have to accept that anyone who wants to contribute to SC needs to have at least a basic understanding of git.
This is true. However it could be made easier. Even a basic tutorial, easily accessible (maybe in the documentation) that described the steps would be a huge improvement.
I think just reviewing and approving current PRs is a dynamic way to speed up development.
That and reviewing/triaging bugs are usually 2 excellent ways to help with any opensource project. If you have the skills to make a PR, you probably have the skills to review at least some PRs. And that’s an excellent way to improve your skills generally.
Happily there is a resource in the wiki which has recently enjoyed a facelift thanks to @mike :
for help files:
more generally:
and re: git
there is also an excellent PR to make the wiki independent of GitHub… Make wiki independent of GitHub · Issue #6181 · supercollider/supercollider · GitHub
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.
As a former contributor I can say that this is very true, but the last 5 words are crucial. Don’t spend too much time theorizing about the perfect organizational structure, bureaucracy, process, political implications, etc. Try and actually roll up your sleeves and help with small tangible things, even if they aren’t technical!
Briefly…
I don’t know anything about web tech or authentication, but I see that github has an API to create issues, would it be possible to create an issue from the supercollider IDE? Perhap a button in the top of the help browser saying, ‘improve me’, that opens a copy of the help file, which the user edits and saves somewhere, then passes the filename as a supercollider string to some class which opens a page in the help browser asking the user to login to github, following which an issue is made.
This wouldn’t actually alter the users supercollider install, they wouldn’t be able to see their changes when they browse the docs, which should avoid a bunch of issues.
Having knowledge of git & github to fix a typo is a big hurdle, having an account is less so.
This would also communicate directly with all users of supercollider, rather than the small subsection who hang out here.
Similarly there could be a ‘submit a bug report’ or an ‘ask for help’ button, the latter could open this website.
There used to be something like that. Unfortunately the bug reports were often not actionable, and if they didn’t create a github account, there was no way to reach the bug report author for clarification.
hjh
Anonymous reports definitely seems like a bad idea, but if the user has to go through the trouble of making an account they should be more reachable.
Sure some of these suggestions, help documentation changes, bug reports, and questions, will not be very helpful, but it would still provide two, I think, important benefits.
First, going through these is an easy way for someone to begin contributing on the GitHub side. Right now, there is quite a leap from non-contributor to contributor, these would provide a stepping stone and it would be easy to point people towards when they ask ‘how can I help’. While the project might need a cmake witch or wizard, I think just more engagement generally is a good thing.
Second, many of the bug reports will be people misunderstanding supercollider, knowing where common
misunderstandings occur is good because it leads to issues. Right now many of the issues on GitHub are not of this nature. When these issues come up here, I’ve seen a few people (myself included) submit a PR, often the very next day. Generating more of these issues would be good.
One project I contributed to there was a guy who had zero coding experience who just managed bug reports. He closed old bug reports that were no longer relevant. He made sure that open bug reports had more information if they needed them, he made sure that bugs were assigned properly. If someone showed an interest in fixing a bug, he would make sure they knew where developer resources were and would notify the developer with the relevant expertise of their interest if he thought it could be helpful.
One of the most useful people on that project.
I mean… we do have 838, I’d quite like to look through some. Already spotted a few that could be closed and some easy fixes.
What is the process for getting the access to do things like add tags to issues? I can’t see that on the wiki.
Ask nicely I think! Let me know your Github username and we can look at what appropriate permissions would be. I’ll run it by the dev folks of course, but I think people will be happy.
I’d like to share our development process at Pure Data, just to give some ideas on how to make things more efficient.
Generally, Miller Puckette is the BDFL and ultimately decides what gets merged. However, we have a dedicated branch (develop) for small trivial fixes where core members can just push without PRs or any formal code review. This means that when I, for example, find a little crasher bug, I can immediately push a fix and forget about it. This has drastically reduced our number of PRs and general friction. Again, this is only done for trivial fixes/improvements; we are all experienced devs and trust each other.
Also, we have a dedicated branch for documentation fixes that is managed by a single very dedicated person (@porres). He can just push his updates whenever he wants and Miller will just merge it. I think most developers hate writing documentation, so if you find people who enjoy doing that, embrace them and make their life as easy as possible!
Also, we have a dedicated branch for documentation fixes that is managed by a single very dedicated person (@porres). He can just push his updates whenever he wants and Miller will just merge it. I think most developers hate writing documentation, so if you find people who enjoy doing that, embrace them and make their life as easy as possible!
This is brilliant.
I think in general non-developers do not realize how much developers hate doing anything that is not development. And if you’re technical, but have no desire to learn C++, the following are all time consuming but necessary tasks:
If you know C++, but lack the skill level to contribute, level up by reviewing the code and documenting stuff. It will help you, it will help future people.
I think there is a good middle ground here - and PD may have found it. Less PRs makes sense to me as well.
/*
Josh Parmenter
www.realizedsound.net/josh
*/
Super useful to know. I guess one difference for us is that we simply don’t have any full-time or even regularly-scheduled-time developers (which is, I imagine, what MP is for PureData). We HAVE had that from time to time, and ofc those were also the times when we were able to sustain lots of changes. The idea of someone taking over a specific area like documentation is VERY appealing, but ofc it comes down to a person stepping up 
Some historical perspective (not directly responding to @Spacechild1 - more for everyone): SuperCollider slowly came to a more pull-request-and-review based model after a period of many years where the develop builds were regularly broken, buggy, or contained incomplete work. This made it extremely difficult for anyone - but especially less experienced developers - to made contributions to the project, because they were mostly not able to build it and get it working in the first place. This problem was massively helped by continuous integration, automated unit testing, and a process where changes were checked before merging to develop. There’s a delicate balance here, and at either edge you probably end up with an ecosystem that’s somewhat elitist (just in the sense that only a small class of people with specific skills have a chance to contribute).
In the past, SuperCollider maintenance was heavily supported and subsidized by graduate or PhD students who were able to contribute time and code very regularly because it was part of their university research / paid employment. I don’t really know this for sure, but it SEEMS like this doesn’t really happen much anymore? I know of a few examples in the last few years (of big contributions that were done by people whose work was supported by a university), but I don’t know of anyone right now that is able to put in regular hours to the core project with the support of an educational institution - DEFINITELY not at the scale of earlier eras.
I wonder if this is also related to a change in the educational ecosystem in the last 10 or 15 years? It’s unfortunate, because many educational institutions (with relatively solid funding backends) are using SuperCollider to teach classrooms of students, but seem to treat it as a free no-strings-attached resource. This is unfortunate, because the most plausible (only?) model that’s really available right now for maintaining regular effort on SC is a collaborative one between universities and arts institutions, and it just doesn’t seem to be happening. Without larger time commitments from individuals (which, pragmatically, take material economic arrangements to be sustainable), we’re sort of stuck with the kind of swarm development that we’ve had. There are lots of positive and exciting things about developing software like this, but it’s extraordinarily hard to organize and there aren’t really many working, real-world examples to base this on (especially in niche creative software!)
The idea of someone taking over a specific area like documentation is VERY appealing, but ofc it comes down to a person stepping up
A middle ground here might be if someone was willing to manage documentation pull requests. Making sure they get reviewed quickly, merged in and providing feedback to new contributors. That shouldn’t be too onerous (I am not volunteering 
).
Huge huge exclamation point on this. There’s a massive amount of “development” effort that requires people that are organized, detail-oriented, clear communicators, and code-savvy but NOT AT ALL experienced C++ developers.
In the past, SuperCollider maintenance was heavily supported and subsidized by graduate or PhD students who were able to contribute time and code very regularly because it was part of their university research / paid employment. I don’t really know this for sure, but it SEEMS like this doesn’t really happen much anymore?
CSound seems to be mostly developed by professors at various colleges. I wonder if it will die when they retire, though.
There is a fundamental difference in how US and EU institutions work. All of this work has happened in the UK or EU because there are grants that are (were) available to cover this. It will never happen in a funded manner in the US. The system doesn’t work that way.
Sam
It’s unfortunate, because many educational institutions (with relatively solid funding backends) are using SuperCollider to teach classrooms of students, but seem to treat it as a free no-strings-attached resource.
Yes, that’s really unfortunate. The IEM in Graz has been supporting Pd for decades: they host our website, our mailing list, our package manager and let one of their staff members work on Pd during office hours. They have also funded my work on VSTPlugin. Universities do have the financial resources, it just needs the right people to make a move.