Meta: The Future of SuperCollider Development Efforts

[capital-G]

Over at scsynth.com, there is a discussion about the future development of SC that concerns this very community: https://scsynth.org/t/the-future-of-supercollider-development-efforts/7857

For the sake of visibility I thought it would be a good idea to post the link here and welcome everyone to the discussion.
If you don't want to register or post on scsynth.com, I also think it's also fine to post your statement here.

[cdbzb]

Just wanted to add that there is now also a thread inviting people to participate in a Supercollider Class Library Developer Group here: https://scsynth.org/t/class-library-developer-group/7974/3

[JordanHendersonMusic]

I'm going to convert this to a discussion, because it isn't an issue.

[telephon]

Maybe you need to explain what "discussions" are?

[JordanHendersonMusic]

From github's website, seems like a perfect fit for this this topic. Could be a good alternative (less noise) than scsynth, or could just be yet another competing standard.

GitHub Discussions is a collaborative communication forum for the community around an open source or internal project.
Discussions are for conversations that need to be transparent and accessible but do not need to be tracked on a project and are not related to code, unlike GitHub Issues. Discussions enable fluid, open conversation in a public forum.

Discussions give a space for more collaborative conversations by connecting and giving a more centralized area to connect and find information.

You can also directly reply to comments, which helps with noise!

I'm totally fine with putting this back if there's any disagreement, I just thought (since discussions are enabled on this repo) the goal was to keep issues for topics directly relating to the code, or generally things that someone could work on and fix.

There's a few other issues that could be discussions.

[capital-G]

Hi @capital-G, what exactly do you think is counterproductive? Having a conversation across platforms, or changing this post from an issue to a discussion?

As I wrote: It creates another place for discussion to be covered/visited. Instead of concentrating the discussion on an open platform, it establishes another feature of the proprietary platform GitHub - we should always be ready to leave this platform, which we do not own, and be ready to move to something free and open like forgejo. I don't want to move there now, but we should always keep that in mind when we're looking for new ways forward.
At the same time, I see the benefit and necessity of keeping the discussion close to the code/CI, and a completely decentralized approach like linux is not friendly to newcomers, so Issues/PR discussion seems necessary.

And personally, I already have trouble keeping up with issues and PRs here, and so I have already stopped keeping track on the forum b/c there is too much noise for me over there.

I personally would like to keep the places for discussion more focused to have a more diverse but focused and precise discussion as I can be aware of what the current state of the discussion is and can be somehow sure that everyone has access to the same information within a discussion and can refer to them in a common and shared manner.

This was a small, and I thought uncontroversial, part of an on-going attempt to tackle the vast number of issue we have.

I consider this a rather important issue as it should be addressing the devs on GitHub that there is an important discussion happening at another place which people may not be aware of - it has been created for visibility.

And I don't know if a number of issues is a problem in particular? An issue should only be closed if it has been resolved, and if so it should be stated why it is considered resolved.
Having a big number of issues makes the management and prioritization of issues necessary, but there are better tools and ways to create this streamlining via boards, milestones or projects.

[JordanHendersonMusic]

You can configure github notifications to get updates about discussions so they appear the same as issues, that way, issues and discussions appear as similar 'places'. I understand your point between this website and scsynth, but no so much between the issues and discussions tabs on github.

An issue should only be closed if it has been resolved, and if so it should be stated why it is considered resolved.

Under what condition could this topic be closed — could 'close-ability' be considered a necessary property of an issue, otherwise, they will exist forever? Discussions, on the other hand, never need to be closed.

boards, milestones or projects.

Are these tools also propitiatory to github?

we should always be ready to leave this platform, which we do not own, and be ready to move

Would be nice to hear more opinions on this!

[capital-G]

Under what condition could this topic be closed

For example, if a consensus is reached on next actions describing future development efforts :)

Are these tools also propitiatory to github?

ofc, as GH is a propriatary platform per se - but having to migrate CSV-like data linked to URLs is easier to migrate than messages which are linked to users on such a platform.

I understand your point between this website and scsynth, but no so much between the issues and discussions tabs on github.

Maybe it's just a personal thing, but when there are so many places to share information, I tend to get out of the loop, which isn't necessarily a bad thing, but for me it makes it harder to contribute in such an environment b/c I don't know the current state of the discussion and I tend to stop contributing b/c I'm afraid of repeating things that have already been said or contradicting things that may be obvious for other people, and so on. - If it's just me, that's fine, but I'd be curious to know how other people feel about it.

There are notifications, but I already find the PR/issue separation hard to manage (did we agree to do X or Y? Often there are contradictions and a timestamp has to be used to reconstruct the events) - and if there are discussions now, there is a third place (or fourth, if you count scsynth) to check if a consensus on X or Y has been reached somewhere, e.g. about the future of SC dev efforts :)

[telephon]

Yes, I agree it is good to use as little features as possible to minimize lock-in. And in a way, even the discussion about this could happen in a topic of our forum. It is further away from the current code base, but independent.