2023-08-06¶

Started out discussing the Dev process.¶

At a high level, we’d like to see:

Clear development cadence for a sense of momentum and that SC is a live project.
Communicate the dev process more clearly so people new to contributing have a sense of the process, and where they can start.
Focal “projects” to rally around, that can also drive release milestones.

Ideally these would consist of small working groups (or very motivated individuals) that do the varied work of large changes:

E.g. state the problem clearly to the community, field their ideas in response, triage and prioritize requests, set the milestones and provide periodic summaries to keep the community updated and solicit targeted feedback.
A couple examples of focal projects might be ():
- Cleaning up the quark system: systematically identifying and removing pain points
- Refactoring the class library
- Outreach and documentation around dev processes
An example of a project suited for a personal initiative:
- Make the Quark library more deeply searchable (keywords, class names, etc.)
Not everyone wants or has time to be involved with larger focal projects, we should still be actively supporting individual initiatives for those with passion projects (more exploratory, open-ended, or less deadline-driven)

Some initial discussion took place…

The existing directory structure in SCClassLibrary already suggests what might stay and what might better be a Quark, e.g. “Core” should obviously be kept.
Interestingly, any group implementing this would, in the course of testing, come up with a “Vanilla SC install”, akin to pd-vanilla. This is essentially the goal of the project: to make SC itself “vanilla”.
- So as a thought experiment: in lieu of consensus or of a successful refactor, what about the possibility of an officially maintained fork: sc-vanilla.
- - there were murmurs of skepticism, w.r.t. counterproductively growing the maintenance base, but… worth considering?

How do we move through “low-hanging fruit” on the ever-growing Issues list?

Meanwhile we have people eager to become new contributors!

New Contributors are confused on how to get started and on the review process.
- What’s the review process? Who are reviewers?
  - Related resources:
  - Reviewer instructions
  - Creating-pull-requests
  - git-workflow-and-guidelines
  - It could be worth refreshing/reorganizing these. And should they be cross-posted elsewhere?
- How do we get more people to join the review process?
  - We have “good first issue” for contributors, how about a “good first review” for reviewers?
We can try to make more effort to usher in and follow through with “Good first issue” contributors.
This has been discussed many times on various forums, it’s worth revisiting those posts…

The never-ending Project

It’s a common complaint, and a #goodFirstIssue
Related resources:
- contributing-helpfiles
- Setting-up-the-IDE-for-easy-contribution (this could use improvement)
Recommend: a SCDoc Style Guide, akin to SuperCollider Style Guide https://github.com/supercollider/supercollider/wiki/Code-style-guidelines -This would make the those good-first-issues related to Docs much smoother!

We recognize dev efforts are spread thin, if you have an open issue or PR, you may need to follow through with pings/reminders.

Don’t be afraid of being annoying, showing enthusiasm and commitment is generally a good thing ;)

A kind of meta quark that would install all required quarks for your project

Temporarily remove non-project quarks?
Would help when sharing/migrating your project to new systems.
There is partial support for this already, but could definitely be smoothed out.
Examples:
- Your art project has x, y, z dependencies. You sit down to work on it, when opening that project you can expect all the quarks to be loaded/pulled down, and none you didn’t need.
- For contributing to the SC, you want to make sure you’re not accidentally including Quark-dependent methods, so you load “SC Dev” Project that removes/disconnects all quarks so you can be sure you’re just compiling the default classlib.

…aren’t technically supported (maybe SC 4 X-P), but for Quark authors, a prefix on class names is helpful. Ex: Josh’s CTK quark.

keep in mind that if you modify your existing quarks, it can break that for users that already use it. Make use of the quarks versioning feature so users can check out old versions!

This brings up the question: do we have a Tutorial on publishing quarks?

Does it highlight all the features? In particular, versioning/tagging. #GoodFirstIssue

Many quarks are black boxes… Are the current metadata fields enough to learn about the quark at-a-glance?

Should we add more metadata fields?
Should they be displayed differently in the list view?
Many Quark authors haven’t made use of the existing metadata features, most importantly the description! Should PUNISH them??? Well ok, no… but we can
- do a public service campaign to encourage them to put at least a description
- sort the Quark list in the GUI so that those with descriptions are listed first

There’s been a spirited discussion around inclusion of a Pitch class to SC.

There are lots of conventions to consider, with variations in, e.g., scales and nomenclature varying across culture.
- We won’t capture all the possibilities… but that shouldn’t stop us from having some solid foundations for people to get up and running without having to build their own.
- And we can keep adding in the future of course with community feedback!
- Better yet, if the class is easily extendable so composers can easily build their own wild tonalities.
By one view, this is a perfect candidate for a Quark. On the other hand, the functionality is close enough to the heart of SC that a case can be made for it to be in the Core.
As an example of a class that is well underway to this end: CTK’s PitchClass https://github.com/joshpar/Ctk/blob/master/Ctk%20classes/PitchClass.sc
- This is NOT a good example of how to (not) document a class (Josh!!! X-P)

Could there be ways to handle threading in the language more gracefully?
Examples discussed would, in some cases, alleviate the need to call the mysterious s.sync.