... | ... | @@ -2,6 +2,26 @@ 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](https://gitlab.deterrencedispensed.com/deterrence-dispensed/help-desk/-/issues)
|
|
|
|
|
|
# ⚠ 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).
|
... | ... | @@ -56,7 +76,11 @@ GitLab Link for submitting issues: <insert link> |
|
|
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:
|
|
|
## 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. |
|
|
\ No newline at end of file |
|
|
- 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 |
|
|
\ No newline at end of file |