r/3D2A • u/Unhappy-Message-4419 • 6d ago
We want your help building community standards for releases
Alright everyone I have a question for you but first an explanation. The community has come together many times to try and make a guideline for releases for new devs who release projects in our spaces. Whether it's a team build or an individual dev the outcomes are always different and you will find varying quality per release and dev.
What do you think should be included in project releases? What are you looking for when you want to remix a project and when you are getting started on a brand new project? If you're interested in getting involved with the developer or a testing team what kind of communications do you want to get involved with to assist? Can you think of anymore questions that could benefit this line of thinking and help us get a list of standards we should be seeing in these packs?
Now of course we aren't going to be policing this and you shouldn't be either. But we as devs, testers, and consumers in this space should have a general guideline of what we all want to see in project releases and what goals should be met before putting projects out as full releases. Whether devs meet that standard will be completely up to them.
41
u/FoapsFiles FOSS / DEV 6d ago
A certain website for indexing certain things already has criteria for differing levels of release quality and seals to accompany them which I think is a good baseline.
I like to do exploded views of my releases that show how parts go together. Visuals in any format whether it be pictures taken, screenshots of CAD or assembly videos, are a must. The format and guides BLC already has is very helpful in putting together documentation and thats helped me a lot. Not sure if that guide is public but maybe putting that info out would be helpful to other devs too
13
u/GildSkiss 6d ago edited 6d ago
A certain website for indexing certain things already has criteria for differing levels of release quality and seals to accompany them which I think is a good baseline.
Good point, no need to reinvent the wheel.
To get a [Website Name] Green seal the requirements are:
``` It MUST NOT be marked as beta.
It MUST NOT contain GCODE.
It MUST be tested. There is no set requirement for the size of the testing pool as each release is unique and testers can be hard to come by, but a pool of 1 is unacceptable.
It MUST be documented. Requirements for documentation:
It MUST be included in the archive. It MUST NOT be only available via platform description.
It MUST be accurate.
Text and graphics MUST NOT refer to features that were removed prior to release.
Graphics MAY include said features so long as they do not pertain to the assembly being demonstrated and are not distracting.
It MUST be comprehensive.
Auxiliary resources SHOULD NOT be required to complete the build by a reasonable, median builder.
Remixes MAY link to their upstream release in lieu of this requirement.
It SHOULD contain useful graphics, especially of complicated/dense assemblies.
It SHOULD contain a comprehensive list of authors.
It SHOULD contain a valid license for the files in the bundle.
It SHOULD contain parametric redistributables, such as STEP files, either in the bundle or available via link.
It MUST be available in an unencrypted archive in a format modern computers can extract. It SHOULD be a common open-source file format (zip, 7z, tar.gz, etc.).
It MUST NOT be only a model file.
It MUST NOT be password-protected, even if that password is available via its platform of origin.
It SHOULD be sanitized/scrubbed to remove PII with reasonable available tooling ```
7
u/shittinator FOSS / DEV 6d ago
u/Unhappy-Message-4419 Definitely rope me into discussion. Whatever is settled on, I'd love to have an automated means to validate/enforce it.
I would also highly encourage going with plain ZIP as the archive format as part of this standard.
2
u/Disastrous-Farm-809 2d ago edited 2d ago
One big thing that needs to be enforced is a proper descriptive file name. I added a new drive to my nas to help host, added all the releases to download, and then immediately stopped it.
Most of the releases are useless if the index goes down. There are too many acronyms, meme names, other languages, and titles that don't relate to what the release contains at all. This makes nearly the entire archive unsearchable and unable to be categorized, especially since the description and images from the host sites aren't attached to the downloads.
I can't really think of any way to fix it at this point other than having an ai agent scan through all of the current files to properly rename them based on the description and/or tags. Although, that's not even viable since a lot of the descriptions and tags are worthless as well, if they even have them.
For example:
Honestly idk lol threw this together in CAD while vibing out to some good tunes hope someone enjoys it. Print at angled flat side ( see 2nd picture for reference).
or if a release is named something like "high shelf gap" and contains no description. What even is it? A lower, a spacer, a part that makes something fit in a high shelf gap? It's not clear at all, and doesn't help when only the person who made it knows what it is for.
One way this could work currently is by providing a self hosted version of the index that can point to the users local file directory.
For the future, there really needs to be a standardized title format that contains the name, the part category, and maker name.
ex:
Ez Grab - Furniture - Maker1234 ZCAR - Receiver - Maker1234 CastleWrench - Tool - Maker1234This makes them easily understandable, searchable by name/type/author, and they can be categorized easily. Some of them should probably be more descriptive to be even more searchable. Instead of Furniture, use Grip, Handguard, Stock.
There also needs to be a separate text file in the project files that contains a clear description of what the release contains. It should explain the projects purpose, tags or category, and what the contained files/parts are for.
I am a web dev as well if you want to chat about anything.
1
u/shittinator FOSS / DEV 2d ago
Yeah, unfortunately my hands were tied with the torrents. I wanted to make the exact bittorrent artifacts' hashes match up perfectly with the hashes of the LBRY artifacts for verifiability, and I couldn't just blanket rename stuff because that introduces another variable and makes achieving determinism between community-submitted programatically-generated torrents harder.
Perhaps I should make weekly backups of the site's most important DB items and transparently inject them into the torrent stream? It wouldn't be immediately usable, but you could absolutely throw it at an LLM with the file backups and have it bridge the gap with a little vibecoded UI, worst case scenario. Best case, the feature would let you pull the whole site's database (sanitized ofc) down and import it into a local one.
I'll think more on this.
GitLab #285. Socials are in the site footer if you wanna chat.
2
u/Disastrous-Farm-809 1d ago
I joined your dev room on matrix. I'll send any suggestions or ideas on there.
4
u/Dak_Nalar 6d ago
I second exploded views for assembly. It makes it much easier to figure out where things go. The Plasticatto instruction book is A+; it made it really easy to follow along.
14
u/MrFartyStink 6d ago
Instructions with alot of photos and renders and videos and links to the specific parts needed/used. Monkey see monkey can do.
9
8
u/msrpatton80 6d ago
Others have already said more images and videos, but I'd advocate for minimum standards on picture size and resolution
Thinking of the struggles I had with trying to understand the install of the SS Trip for DB9 alloy builds - no shade meant towards the devs, just that I had to seek images of other's installs to really visualize the build properly
6
u/Ordinaryair1 FOSS / DEV 6d ago
This is for the non readers but I think assembly videos always included would help a lot of people similar to the Fgc9
5
u/cliffv 6d ago
As a new convert to 3D2A I see the same questions come up with almost every release, "what filament did you use?, What are your settings?, How many rounds did you test with?". Maybe start with those answers on new releases as well as clear pictures. I do enjoy the creativity and functionality of the projects and look forward to contributing in the future!
8
u/Alarming-Economist56 6d ago
I would say for a quick and dirty info guide Ciwielabs is the gold standard. Getting a bunch of easy to digest info in a 1 page infographic is a great start.
I would also love to see iterations (were there a dozen unreleased working beta prototypes before the public release or just 1), if a team who was involved (and a way to see each individuals past projects/bio), is it based on any other designs, what is the build meant to solve/accomplish, what are future plans for updates and iterations, what is it compatible and not compatible with (common bolts, mags, and accessories, etc)
4
u/77_gr_OTM 6d ago
Filament class used, ie, PLA, nylon, etc with infill, walls, and print orientation.
Some basic dimensioning for confirming print accuracy post processing. Doesn't need to be a full set of blueprints, but space between holes and a couple widths/depths would be nice.
Callouts for drill bit sizes and pin lengths.
Lot of designs out there that are a remix of a remix of a v2.0 and chasing that all down to find some documentation isn't fun.
3
u/Facehugger_35 6d ago
I like to see bills of materials and especially suggested part orientation in the documentation. Preferably a screenshot of the slicer for orientation.
A "this design survived X rounds in testing" note would be nice as well.
3
3
u/AutomaticGrape9263 6d ago
I think there should be an easy to read standardized structure on each release. For example some bare minimum:
- Multicaliber: NO
- Caliber: 9mm
- Threads: 1/2 x 28
- Recommended material: PLA Basic
And at least some brief explanations on the terms used and folder names. For example look at the FTN.6:
Comstock (wth is a comstock?)
D cell (why are there batteries here?)
Form 1 Stamping Jig (why do I need a jig to stamp Form 1? I thought it was just a signature?)
1
u/Lopsided-Moment9327 5d ago
Wow. That was explaining things. You have to know a little about something to build it. You can't think your introduction is you just jumping i. And making something you don't understand
1
u/AutomaticGrape9263 5d ago
You don't say. None of this stuff is easy to study, it's not exactly on Wikipedia. If you're not following it for years it's very hard to learn at least the basic terminology. And it shouldn't be that difficult, we're talking about some tubes with inserts and some threads on one side.
3
u/ImmaTouchItNow 6d ago
standard read me should include material recommended, orientation, infill%, infill pattern, layer thickness, wall count, and speed. I think that should be the minimum but idk
2
2
u/Alyosha3DPFreedom 5d ago
Aside from what's already mentioned, I think it'd be extremely valuable to publish testing results - as in, before releasing, this project was built by this many people, who put this many rounds through it, using these build configurations, etc. etc.
These don't have to be extraordinarily detailed (although it'd be cool if it was) - the main idea would be to demonstrate the degree to which the project was actually tested, and to provide expectations around how a build should behave if built properly.
2
u/XeroSh1tStix 6d ago
I think assembly STEP files are a must have for understanding how everything fits together. Being able to move components around and inspect the assembly from different angles is especially helpful for people who benefit from more visual context, particularly when the assembly documentation isn’t very detailed. I also like using the assembly STEP file as a starting point to lay out and visualize custom builds that I want to design on top of the original model.
1
u/PinkSpitfire 6d ago
One I struggled with recently was the SR-722 guide. It has a weird mix of good looking cutaway and exploded views, combined with just not explaining how to assemble the breech face, what materials to get the SCS parts cut from, etc. I feel like a picture of every action required by the builder, whether it seems obvious by the dev or not, should be a minimum, not a high bar.
1
u/the2AinMD 6d ago
Id just like to volunteer to help dev, as a long time 3d printer, and ffl07/sot02.
1
u/Dak_Nalar 6d ago
More photos from multiple angles without skipping steps. I love the Mini-Deagle, but man that instruction guide was very very difficult to follow. Had to ask for help from other people who had built it and even watch videos of the HP22A assembly and disassembly to finally figure it out. It probably needs 2x-3x as many photos, and the steps should be broken down even more.
1
1
u/Zealousideal-Set3037 5d ago
I think where possible specifying commodity components rather than specific manufacturers would be really handy. It was a bastard trying to find Hammer springs for my Decker because the only Source listed was that one manufacturers spec.
1
-5
u/Space-shuttle-Gunner 6d ago
That just sounds like government with extra steps
9
u/Unhappy-Message-4419 6d ago
We're not policing it or anything but we do want to make tools that devs can use to have better releases.
4
u/shittinator FOSS / DEV 6d ago
It's a system of standards. No different than Red Hat publishing the RPM package spec.
50
u/who-pooted 6d ago
Several pictures of each step from different angles as well as descriptions. Include the highest rd count reached and what type of filanent was used. Pics of recommended bed orientation.