No duplicates and no additions policies discourages participation

[grantr]

(Response to #258 (review)):

Please don't make changes in other people's directories.

@KiloQubit I understand why that's a policy, but it combines with the no duplicates policy in discouraging ways.

If the only way to get a mod into the repository is to submit something unique or integrate it with an existing mod, then there are potentially many refinements to those mods that will never make it to the repo, because the refinements can only be placed in the original directory (to avoid making a copy) and the original author is no longer paying attention, or maybe was never that familiar with GitHub in the first place and couldn't execute a multi-step PR sequence without a lot of help. The burden of this kind of contribution is high, and will get higher over time as more "unique" ideas are taken by the first mover.

I understand maintaining this repo is a significant time commitment and something the maintainers do for free for the community, which I and many others greatly appreciate. Thank you for your time!

[KiloQubit]

added @FHeilmann

[FHeilmann]

Let me try and start with a bit of history on VoronUsers so I can later motivate why these rules are in place:

Before VoronUsers, there was a "community mods" folder in each of the main printer repositories. This quickly became a nuisance, because they were shipped with every major voron release, and their submission cluttered up the development of the printers themselves.

Thus, we were looking for a place where only mods could be submitted, with the following requirements:

• Quality: All mods should at least try to match the VoronDesign polish of quality (printability, part orientation, documentation etc.) so a vetting process was necessary.
• Hosting: Hosting STLs can quickly burn through a lot of cash, especially if parts contain a lot of fillets and are exported with ridiculous resolutions. This ruled out things like dropboxes, google drives or any self-hosted solutions because nobody is making any money off of VoronDesign to compensate for these costs.
• Licensing: Thingiverse was ruled out because, frankly, their site doesn't run well most of the time, and moreover, makerbot has some shady clauses in their licensing agreement. Thangs wasn't a thing at the time, prusas repo was just starting out and grabcad wasn't really well known in the community either.

This caused us to pursue Github, because we could vet all submissions for quality, didn't have to worry about hosting, and can attach any license (GPLv3 in our case) to the mods. To be honest, I never expected VoronUsers to gain the popularity that it has, and with that popularity came the following issues:

1. Easy of navigation: The overview readme thing worked well, but it doesn't anymore. I know. There were several reasons it was chosen this way, and we're trying to look into different ways of accomplishing the discovery of mods.
2. Github learning curve: It's there, but I've always encouraged anyone to hit me up and discord and spent a lot of time guiding users through the process.
3. Inherent with bad overview comes the issue of duplicates, which I'll address in a minute.

Before I start addressing your concerns, let me say this: VoronUsers was created with a focus on functionality, not for users in the community to show off their CAD skills. As such, any submitted mod should have a meaningful intent that directly applies to VoronDesign 3D printers (for this reason we previously rejected generic rPi cooling fan mounts for example) and improves their usability or opens them up to new variants.

On to your concerns:

• Duplicates: Duplicates would further complicate the discovery of mods, without improving the value that is contained in this repo. A new user looking for mod X would be presented with multiple identical submissions and get confused which one he should use. If the functionality between similar submissions differs (which is why we accept new mods that improve upon an existing mod in a meaningful way) the user can select the one that fits his needs best.
• Abandoned mods: This has not happened yet to my knowledge. Whenever the original author was pinged, they showed up. If any difficulties with integration of new and old mods arise, we're happy to assist both submitters. If a user ends up abandoning his mod or not reacting to pings (again, this hasn't happened yet) we will gladly transfer "ownership" and responsibility to the new submitter, so he can upload his improved/fixed variant and credit the original owner appropriately. This has to be done in agreement, however, so the request to not change other users content that you referenced is still valid.

Finally, I want to add that VoronUsers is by no means the only place for legit mods. People have been sharing their mods on discord/thingiverse/dropboxes before and there is no issue with that. However, with mods that are listed under the official VoronDesign name, we reserve the right to vet the submissions and impose rules as we have done so far. Again this doesn't mean that this system isn't without its flaws, and we're trying to solve the most glaring ones to hopefully also reduce the load on the reviewers.

I hope this clarifies the issue somewhat. If there's any additional concerns, I'll be happy to hear them.

Bests,
-Florian

[grantr]

Thank you for your extensive and clear answer Florian! Sorry for the delay in answering; I had to find time to give your reply justice.

It helps to know some of the initial motivations. I think your focus on functionality is good for the community and makes sense.

If the functionality between similar submissions differs (which is why we accept new mods that improve upon an existing mod in a meaningful way) the user can select the one that fits his needs best.

I'm not sure this principle is working as intended. A concrete example: #207 "improves upon an existing mod in a meaningful way", such that the original author of the mod acknowledged it was a better version. I won't recount the whole history here, but you can check out https://github.com/deepfriedheroin/VoronUsers/pull/1, #258, and https://github.com/deepfriedheroin/VoronUsers/pull/2 if you're interested.

A new user looking for mod X would be presented with multiple identical submissions and get confused which one he should use.

I think this is not giving the user or mod author enough credit. Are there cases when users duplicate mods so identically that the differences between them can't be explained? A possible compromise: allow variants, but ask variant authors to explain in their README why their variant is interesting and different from the variants that already exist.

In theory, variants could live in GitHub forks, but the discoverability of this is essentially zero. GitHub is not a good way to discover content. The overview README, GitHub file search and repo search (forks are not code-searchable, ask me how I know) are too difficult to use and organize for the purpose of discovery. I think this leads to a desire to keep the repo as minimal as possible, but IMO the repo should just be a repository, not a discovery mechanism. A separate index and search/browsing interface would be a better experience for mod authors, maintainers, and users.

Instead of an overview readme, why not maintain a machine-readable index? A yaml file (or multiple files) listing a few details about each known mod, inside or outside this repo, could be processed by a GitHub Action that generates a GitHub Pages site that functions as a search/browsing interface, for free (or to be extra fancy, use Netlify's free open source plan). Or feed a discord bot that answers mod queries (no more "does anyone have a link to the mod that does X" questions in Discord). There are a lot of possibilities when automation is involved.

For example:

mods:
  - name: Under-bed Wago mount
    printer: Voron 0
    author: NA411
    readme: https://github.com/grantr/VoronUsers/blob/master/printer_mods/deepfriedheroin/v0_bed_wagos/readme.md
    summary: QUAD 221-412 WAGO Holder
    description: Attach Wago 221-412 to your v0 bed.
    # used to narrow down to a specific area or function
    categories:
      - electronics
      - print-bed
      - wago
    images:
      # shown in the browsing view
      - https://github.com/grantr/VoronUsers/blob/master/printer_mods/deepfriedheroin/v0_bed_wagos/images/InstalledFusion360WagoHolder.png
    stls:
      # shown in the browsing view using GitHub's embedded stl viewer
      - https://github.com/grantr/VoronUsers/blob/master/printer_mods/deepfriedheroin/v0_bed_wagos/stl/Quad_Wago_221-412_Holder_Rev1.stl
    duplicate_of:
      # Add a callout linking back to the preferred variant, for users who are confused about which to use
      - name: V0 bed wagos
        readme: https://github.com/VoronDesign/VoronUsers/blob/master/printer_mods/deepfriedheroin/v0_bed_wagos/readme.md
        reason: Rotates the wagos to the back of the bed
    # non-vetted mods get a warning callout and are hidden from search by default. This allows mods
    # to make it into the index before an admin has had a chance to vet them. Only vetted mods can
    # live in the parent repo, to preserve its existing quality bar.
    vetted: true
    license: GPL3

The richer information here can help the user navigate a wider range of mods and accomplish their specific task:

• Finding mods for a particular printer
• Finding a specific mod they saw once before
• Finding mods that modify a specific function
• Finding the preferred version of a mod that has many variants
• Understanding which mods have been vetted

Reviewing submissions to the index is work, so the maintainers still have to do just as much as before, but they no longer have to vet submissions immediately (thanks to the vetted warning). Mod authors have an easier time of getting their mods into the index (because duplicates are allowed). Users will be able to find what they're looking for easier, despite having more variants, because searching and browsing mods is easier.

I know the maintainers of this repo have real jobs, and what I'm describing doesn't just come into being from my head. I'm not trying to sign anybody up for anything. If this idea seems useful, I'd like to work on a prototype. No harm done if it doesn't work out, but I think the upside for the community is significant.

[awickham10]

Random third party chiming in. I really like the idea of the metadata file for the mods. I would throw out there that maybe it isn't one massive file but a standard file per mod. That would be much easier to maintain than managing conflicts a massive single file. For example, each mod folder would have a metadata.yml file with the information in there. Merge conflicts could be a thing of the past!

You could the probably use GitHub Actions to parse all of the metadata.yml files into a single metadata.yml at the root that machines could then use to parse.

[claytono]

@awickham10 That's come up before, and in the past there has been some indication that sort of thing would be welcome. I got the impression that mostly someone needed to step up with a prototype for discussion.

[awickham10]

@awickham10 That's come up before, and in the past there has been some indication that sort of thing would be welcome. I got the impression that mostly someone needed to step up with a prototype for discussion.

I'm happy to take that on. Will message back here when I have a prototype.

[a7hybnj2]

This was linked in the discord and seems somewhat applicable to the subject here:
https://faked.org/voronmods/

[jangrewe]

I'm that guy with the Voron Mods page, and i'd love to see any kind of metadata, be it a YAML, JSON, or even (if really necessary) an XML.
I'm currently parsing the Markdown files and try to make some uneducated guesses, with fairly usable success, but just using straight data without having do do any parsing would be a lot nicer...

I'd be happy to create PR that has a e.g. "metadata.json" generated for each and every mod - i have the data already, so i'd just need to write it to a fork. ;-)
But before i invest any time, it would be great to get some agreement about the structure, required fields, etc.

[FHeilmann]

more than 2 years later, and I think we've finally made a significant step towards the discussion that's been happening in this issue.

We have introduced a metadata system as suggested above, together with a much more comprehensive CI toolkit to check more things about mods and leave more time to do the actual reviews. We have brought in ~5-10 new reviewers to help out, and have rethought the mod submission rules a lot.

Specifically on the topic of this ticket, while we'd prefer to see people collaborate on a single mod rather than submit two mods that are mostly similar but differ in the details, we'll try to be more lenient and not stick to the categorical 'no' that was the starting point of this discussion.

I hope the way forward will be much easier, but only time will tell.

Florian