This is a guide and process guidance on how to conduct a beta.

Note: These instructions required that your GitLab account be provisioned as a developer. If you aren't a developer yet, please fill out the "Developer Request Form" at the Help Desk

⚠ Are you ready to run a beta?

You should really open a beta if you are nearing the finality of your product's initial development.

A beta should be for:

• private (if desired) testing of a design among a trusted and reliable group of testers
• gathering information on your design, such as its compatibility with variants of a parts kit
• gathering feedback on your design, such as whether the instructions are sound, assembly is easy and accessible, or if users are able to successfully assemble and use your product

A beta is NOT:

• early access.
• for designs that haven't been independently tested by the author.
• for designs that are clearly not of sound engineering judgement.

When a beta is announced, that will be the single event of most attention for your product until you release it. If it is public, users will be interested in testing, then quickly trail off as life beckons them or as they become disinterested.

So- it is only when you have a concrete design in place ready for evaluation that you open a beta. A beta is NOT for "what do you guys think" or for early access. For more casual evaluations, find a group of vetted testers or those interested, and create a group chat amongst yourselves to discuss your design. Beginning a beta is more of a formal step towards release.

Configuring your GitLab for a beta

The steps below will configure your GitLab repository for a beta. Your files will NOT be exposed to anyone who is not a member of your project (either explicitly added by you, or within your group).

1. Go to your repository settings, then "General".
2. Ensure Issues is enabled, for "Everyone with Access"
3. Ensure Repository is enabled, but "Only Project Members"
4. Ensure "Forks" under "Repository" is set to "Only Project Members"
5. Under Repository, disable "Pipelines", "Container Registry", and "Packages".
6. Disable Analytics, Wiki, Snippets, and Operations. (Unless you wish to use these features)
7. Click "Save Changes".

Preparing for a beta

These instructions presume you are using GitLab for version control.

1. Commit your files. You must have the following files in your package as highlighted in the Release Package Requirements guidance document.
2. Create a "Release" with a "tag" in the following format off of your primary/develop branch: vX.x where X is major version, and x is minor version. (i.e, if this is your products first beta, you could use v0.1.)
3. Do not use the release artifacts archive automatically bundled by GitLab- create a zip file with all your files EXCEPT the Natives, STEP, and all Git-related folders.
4. Upload your file to the beta channel.

Configuring the beta channel

Note: This step can only be done by a RocketChat administrator.

1. Create a channel with the following format: #beta.username_projectslug
2. Populate the description and topic.

Description: Beta channel for project Topic: Beta channel for project

3. Paste in the beta rules as described below:

**BETA RULES**
The Purpose:
To create a singular publicly released and shared package of known good files paired with instructions that would enable someone to build whatever we have released without having to come in contact with us.

The Rules:
1. Don't leak the beta files. A singular, known good, with instructions package is the first thing the broader world should ever see of this.
2. These rooms and groups are to test what the developer is releasing, not for you to make feature requests of them. Test what they are providing. Give feedback regarding the print build and assembly. Don't ask them to make it take Glock mags.
3. Do not attempt to modify beta files. We are trying to lock down a configuration.
4. Test build and report back with speed (if you're able). We understand you're busy but the faster you all report results back to the dev the faster it will get to release.
4. Beta rooms are for us to collectively verify new files, not for you to get some cool shit early. Do more than watch or print. (This is not early access.)
5. Have fun. Seriously. And don't be dicks.

Info:
GitLab Link for submitting issues: <insert link>

4. Drop in the beta files archive.
5. Set the designer as the Channel Owner.
6. Add channel to #z.beta, with note if beta is public or private.
7. Update private channel link directory with non-expiring permanent beta invite.

Pro-tips:

• An announcement can be updated to display a persistent message in the channel, and can be found in its channel settings.
• It's strongly, STRONGLY recommended that you do not include source files (STEPs, Natives) in your beta.

Running the beta channel

There is no concrete guide for running a beta, but there are some pointers that can be offered:

• Participate in your beta channel. You are the single most important person in that room- your testers depend on you for updates, correspondence, and feedback. You have to ask them questions about their findings and evaluations.
• Be responsive to feedback and questions that your testers may have.
• Publicize your beta (if you so wish) on social media. You will want many testers with their parts kit and errancies in printing to get the best variety of information.
• Be concise with your beta's requirements. If your beta requires a specific parts kit, and a tester shows up with an incorrect kit, gently guide and tell them how to get the right parts to participate.
• Don't be discouraged with your beta participation. You will get users that have no kit and join your room just to join. You may see dwindling participation the longer your beta is open. Don't worry- use an "@\all" to summon them when you have a new update.

Closing your beta

x