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:
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.
Using vscode, we can find and replace strings of the files in a folder and all its subfolders.
That is not the problem.
then synchronise it.
That is the problem. 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. Fortunately, there are countless of tutorials on the internet. Ideally, you have a programmer friend who can show it to you.
There are a lot of unreviewed PRs, which is another reason for getting stuck.
I think just reviewing and approving current PRs is a dynamic way to speed up development.
I am sad that I do not understand C++ and many GitHub details, as well as my imperfect English. However, the community members are kind enough to understand my clumsiness in contributing, and there have been primitive changes that reflect my soft-coded modification. It is not fast, but it has been being developed!
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
*/