Library team

[AndrewBelt]

Participating in the Library team is the simplest of the four. Requires knowledge of submitting PRs and editing JSON in the manifests/ directory.

Tasks

• Keep plugin manifests correct and up-to-date.
• Handle issues opened by plugin developers who want to add/update their plugin.
• Seek new plugins/updates when developers don't notify us.

Workflow

Begin by checking this repo's issues for requests from plugin developers.

If someone requests an information change, simply make a commit (and send a PR if you don't yet have VCV community access) with the change to the manifests following the manifest format at https://github.com/VCVRack/community#library-team, and someone with write access will accept it after a quick review. You may combine multiple manifest updates in one PR.
Do not modify or add the "status" or "latestVersion" property.

If someone requests an update to their build, leave that to the Review team (or become part of the build team by reading the instructions #353).

If someone requests a new plugin to be added, add a new JSON file to manifests/ with all known information. Do not add the "status" or "latestVersion" property.

Finally, send a pull request, and someone with write access will review and accept it.
After accepted, notify the plugin developer by commenting "Updated information" in the original plugin's thread.

I think that's it, pretty simple. I may add JSON validation scripts that you should run before committing, but I'll wait until we've had a case of invalid JSON. Expecting all plugin developers to write valid JSON (like we did in during Rack 0.5) is impossible, but I can assume Library Team volunteers will do most everything correctly since you'll be more familiar with the process.

Members

• @cschol
• @phdsg

[AndrewBelt]

I'll use this issue #356 as a practice for someone on the Library team. Typically, each plugin developer will create an issue with the title = plugin slug (I'll personally change it if not) where they'll communicate with the Library team upon updates.

@MarcBoule has provided a scratch JSON file. Usually developers won't do that. Some things the Library team should note about this particular example:

• Remove duplicate URLs. In this case, websiteUrl should be removed since a GitHub URL is not their custom website. manualUrl should link directly to their README, if it is helpful to end users
• Status should be removed. I'll figure out what to do with that later.

[MarcBoule]

DISCUSSION: Just to understand better the proposed method, is it your intention that each dev's issue, titled with his or her slug as mentionned above, remain persistent (i.e. always open), and thereby serves as the communication channel between the dev and the Library team? In this manner a request for an update of the repo's version of our plugin, for example, would be a new comment in the plugin's "issue" of that dev, instead of a new issue each time? EDIT: not sure if this is the best way to go, just brainstorming...

[AndrewBelt]

Yes, keep the same issue for each plugin.
If the issue creator closes the issue, can they reopen it? If not, just keep it open indefinitely.

[cschol]

A few questions:

• Should the manifest .json files always contain all keys, e.g. contactEmail or donateUrl, even if the value is not known or used (e.g. no contact email provided or no donations)?
• Should we tag the plugin developer in the PR for updating the manifest to review?
• Do we only care here about open-source plugins and if yes, only those that have been migrated to v2 already?

[AndrewBelt]

• No. A blank string is an invalid URL and email address.
• Nah. You can if you want though.
• The manifests collect all plugins, even dead ones. repos/ contains only open-source ones though.

[n6smith]

Note: Both links in initial post are non functioning 404s.

[AndrewBelt]

@n6smith Thanks, switched to master branch.

[cschol]

A few more questions:

• At this stage, developers are updating plugins without updating the version to get to final version 0.6.0. In general, can the plugin manager handle rebuilt plugins with the same version or do we have to rev the latestVersion in the manifest with every pull of new source in the submodule?
• Should the status be set to "not available" (or removed) when a plugin source code is updated (pull in submodule and PR with new SHA) until the Build Team has built the plugin or does that not matter?
• Who is responsible for setting the status key?

[AndrewBelt]

• An update to the build requires that the user change the version somehow, so Rack knows that an update is available. It checks oldVersion != newVersion as a criteria for requesting an update.
• I'll type something to answer these questions in the Build team #353 issue

[AndrewBelt]

I've updated the first post with the WIP workflow.

[phdsg]

case: #398
dev requested addtition. manifest was created and accepted. thread says "updated information"...
is this the point where the review team picks up and creates the submodule?

[AndrewBelt]

The Library and Review teams can work in parallel. If you want to act on behalf of both teams, you can combine your commit as long as you follow both workflows (e.g. acknowledge that the repo has been reviewed).

The idea behind splitting these two teams is because the bar is lower for the Library team, so a PR might be made in a matter of minutes, while a review takes more effort and might take a day or two.

[phdsg]

creators can reopen their issues unless you closed them, right?
i think it'd be good to encourage devs to close their issue unless there's something to do...
just for readability in the issue tracker.

[AndrewBelt]

@phdsg Yes, that's what the test at #393 concluded.
I'm writing a better documentation for plugin developers.

[phdsg]

@AndrewBelt do you handle the free closed-source plugins like #376 and others?

[AndrewBelt]

I haven't thought of a procedure for that yet.

[AndrewBelt]

Thanks for the help so far guys! To organize team members, state your name and I'll list your username in the first post.

[cschol]

Great work! I am going to catch up and mark all 238971231 GitHub notifications as read. If you need help with any specific plugin let me know.

[cschol]

I used to be able to add tags to issues filed, e.g. plugin, but can't anymore. @AndrewBelt Are you taking care of that?

[AndrewBelt]

I've disabled everyone's write access to this repo until later. Still need to make sure everything will be work properly when PRs are no longer needed.

[cschol]

Ah, cool. No problem.

[phdsg]

i assume you'll handle the VCV open source entries yourself @AndrewBelt !?

[AndrewBelt]

@phdsg Good question. Yes, I'll handle everything for the open-source VCV plugins whenever they need an update.

[AndrewBelt]

@cschol @phdsg I've given you commit access so we can finally skip PRs.

If someone would like to join the Library Team, send a few correct PRs following the Workflow in the first post, and I'll also give you commit access.

[AndrewBelt]

I haven't tested whether the issue OP can close an issue reopened by a collaborator, but I know that they can't reopen an issue closed by a collaborator.

[AndrewBelt]

I've been informed that many versions are incorrect (e.g. most of the them beginning with 0.5) on https://vcvrack.com/plugins.html for plugins not available in the build system.

So, if "status" is not "available", you are free to set "latestVersion".

[phdsg]

did a few of them...

it'd be cool to find a way to make more people participate here instead of going to places like this or on fb

[AndrewBelt]

@phdsg Should I make a quick post on the Facebook user group to request 2-3 more Library Team members?

[AndrewBelt]

We need to add this to the workflow: When a developer requests a change on their plugin's issue, a repo maintainer should open it, and then close it when the change has been satisfied. Unfortunately when a maintainer closes an issue, the OP can't reopen it, so maintainer will have to open/close all issues by watching the issues. But some additional questions:

• If I close an issue, can a maintainer reopen it?
• If I open an issue, can a maintainer close it?

Someone try reopening this issue.

[phdsg]

works fine.

[AndrewBelt]

Great! When I'm at a computer I'll close all the issues that have no withstanding changes. You're welcome to get started on that before me though.

[AndrewBelt]

Done. Here's a handy link to all open plugin issues sorted by recently updated. This would be a good bookmark.

[AndrewBelt]

All of the currently open ones should probably be closed, but it wasn't immediately clear the their status is.

[AndrewBelt]

Suggestion: Previously I requested to avoid redundancy and not include a pluginUrl if it was the same link to sourceUrl or manualUrl. Now, let's try to include a pluginUrl on as many plugins as possible, given that the URL is targeted toward users. Redundancy is fine. For example, LOGinstruments has a sourceUrl of https://github.com/leopard86/LOGinstruments, but let's now add https://github.com/leopard86/LOGinstruments/blob/master/README.md as the pluginUrl so users can quickly preview the list of modules using the same column as other plugins with separate websites.

[cschol]

Stats:

• Total plugins: 137
• pluginUrl exists: 61
• no pluginUrl, but manualUrl exists: 69
• no pluginUrl, no manualUrl, potentially built from sourceUrl: 7

built from sourceUrl means: sourceUrl + "blob/<branch name>/README.md", IF README.md exists on a branch, e.g. master.

I can script the update of the manifests and push an update to the repo to set pluginUrl for all plugins. Thoughts?

[AndrewBelt]

It isn't necessarily true that the README is the best URL. Sometimes the github wiki, sometimes a new website was added. Sometimes the README isn't a good resource for users, so it shouldn't be the pluginUrl. Since it's only 69 without, I'd just do it on a case-by-case.

[cschol]

For the 69 the pluginUrl would be the manualUrl (whatever it is set to) since it exists. The remaining ones without a clear choice are only 7.

[AndrewBelt]

Okay, you can script whatever you need, but it would be good to review the changes afterwards.

[cschol]

Sounds good. I'll just do a PR.

[AndrewBelt]

You can commit directly.

[AndrewBelt]

Rack v1 will require all plugins (except Core) to supply a plugin.json file in its root. (Example at https://github.com/VCVRack/Template/blob/7c28f8d276e51d9d2c8e8de639e6823648c97e8c/plugin.json.) There are many great things we can do with this metadata. The file will be written by the plugin author rather than the Library team, so this reduces the team's responsibilities to zero, or rather transfers the responsibility to the Review team to review the metadata according to guidelines.

[netboy3]

I'm the new maintainer of MSM and am getting ready to push 1.0.0 to the library:

• Should I use the old "MSM" issue to post a request or open a new "MSM" issue?
• Would posting the 1.0.0 overwrite/remove the 0.6.51 entry in the plugin library?

[AndrewBelt]

You can use the same issue. Yes, since you'll be using the MSM slug, it will overwrite the old manifest and thus the entry on the VCV Library website.

[RemiCollin]

Do you need help with the library repo ? I can help on managing github issues / do code review if you want.

[AndrewBelt]

Closing since this issue's purpose has been served, and the VCV Community forum is a more organized place for discussions.