Open grantr opened 3 years ago
added @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:
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:
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:
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
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, https://github.com/VoronDesign/VoronUsers/pull/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:
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.
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.
@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 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.
This was linked in the discord and seems somewhat applicable to the subject here:
https://faked.org/voronmods/
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.
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
(Response to https://github.com/VoronDesign/VoronUsers/pull/258#pullrequestreview-617054996):
@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!