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.

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.