I’d be willing to take the technical supervision of the website.
Fantastic! - the last couple of slots without nominees are
Platform:Linux and
Code:Infrastructure and GH organization
Hey Everyone!
Thanks for this conversation.
I see I was nominated for CI/CD and IDE / QtCollider 
I definitely can strongly contribute to CI/CD as I helped with that area over the years.
As for QtCollider and IDE - I care about GUI and by extension Qt stuff, but my understanding of the C++ part of it is limited. I’d be happy to defer to scztt’s expertise to make decisions in that area - I can still help with managing it though.
I’m not sure what exactly would “Infrastructure & GH Organization” entail? There’s a number of people on this thread who have been with the project for some time and can offer a birds-eye view (myself included, I guess) and I think that any of us could commit to that part of the project if needed. (?)
Finally, in the past I have made efforts to support Linux (mostly in the CI/build area) so I could maybe step in to that role temporarily, but for the designated person I’d prefer it if that would be someone for whom Linux is the primary platform.
I care about SC and its many facets and I’m very excited for this effort to make the development more efficient. It’s super important that we use our limited time in the best way possible and I think making this structure will help greatly! Thanks!
3 Likes
Quick question: as we are moving to implement this, if I see a PR that I consider ready to merge (i.e. either I can understand it well or it was approved by someone else who does) from outside of my category, should I refrain from merging it, letting the designated person to “sign off” on it and merge it? Or is it still fine for me to merge PRs I deem ready? This might be a delicate balance and the last thing I want to do is to step on someone’s toes, but also the more things we can review and merge, the better.
EDIT: my preference would be for the designated person to attend to the PRs in their area if there’s a need for consensus, or if nobody else does; otherwise I think people who are active in the development do act in their best effort to approve/merge changes they feel at least somewhat confident about and maybe there’s no reason to limit that practice even if it’s outside of the outlined assignment? Let me know what you think!
2 Likes
I suggest anyone should feel free to review anything (even if we wanted to we don’t have the numbers to be efficiently territorial! 
) Do it formally so it’s marked as having at least the one required review. Then allow a reasonable amount of time for other views, and if none ask if any objection and merge.
Does that sound okay? Again I don’t think the idea here is to concentrate authority and many cases are straightforward.
1 Like
Perhaps it might be a good practice to go ahead and merge, but to @ the responsible person for their information.
1 Like
Please allow me to apologise for suggesting this idea without actively engaging in the new council structure. Given my current proficiency in English and programming, I feel I may not yet be suitably equipped to contribute as an active member.
-
Would it perhaps be prudent to establish a time limitation? For example, if the individual responsible does not take action within one or two weeks, the pull requests could then be reviewed, approved, or merged by other core members.
-
I have observed that pull requests which align closely with the interests of core members tend to be processed relatively swiftly. This is, of course, a natural outcome given the active involvement and expertise of the core members in these areas. However, I have also noticed that some pull requests with the potential to offer meaningful benefits—such as improving accessibility for less experienced users or enhancing ease of use—might not receive the same level of attention. This could be due to differences in focus areas, programming approaches, or immediate priorities between core members and the contributors submitting these pull requests. Recognising these differences, I wonder if there might be a way to ensure that such contributions, which could greatly help newer users, are given proper consideration alongside other priorities.
1 Like
I suggested (in a different chat I think) a role that is something like a “Quality + User Representative”. Rather than having a specific technical component or area as their responsibility, this person would be responsible for the overall quality of pr changes and releases, and being a representative for users. Their role would be to do things like - promote pull requests that have the most value - help prioritize what goes in a release - help decide whether a feature is “done” or needs more work (in terms of behavior, not code) - have an overview of a new release, what testing should be done, whether its solid enough to release - and being a conduit and representative for non-dev users, to gather feedback or build consensus. This would be intended as a rotating position.
This is a super crucial role on software development projects I’ve been on, and is also a way for non-developers to play an important part in whats happening with SuperCollider development. This person, for example, would be responsible for exactly what @prko is talking about here.
We have a lot on our plate already just getting things back to a state where they’re running smoothly, so this wouldn’t happen right away - but I would love to see a role like this in the longer term.
6 Likes
Meta: can we add Council structure · supercollider/supercollider Wiki · GitHub to the top post please?
2 Likes
Thank you!
(…20 char limit)