After you have run your service as a private beta, open it up to the public.
A public beta is a version of your service that’s available for any member of the public to use. Sometimes it will exist at the same time as the current available service, while in other cases it will replace what the previous service. Contact firstname.lastname@example.org for guidance.
What to do in public beta
- Work with your department’s Communications staff to advise on and develop a suitable communications plan to announce your service. A simple plan can include an email message to staff and a post on the government intranet. A more advanced plan can also include banner advertising, social media promotion and offline communications. In all cases, start the user journey at Yukon.ca.
- Contact your department Communications staff to help write and publish a related page on Yukon.ca. Do not add a button to link to your service until after it is live.
- If your service has online payment, the merchant account for your service will have been using a development or sandbox account. In order to go live with a public beta version, the service owner should send the production Merchant ID and Hash Key Value to email@example.com so they can make changes.
- If the service is replacing an existing service and will be available at the same time, a beta banner should be added to the existing service and the public beta version. Contact firstname.lastname@example.org for assistance.
- Avoid making any last-minute changes to the service that could affect its stability or performance. Save those changes for after the service is in public beta. To prepare, choose a date to make your service available as a public beta, then subtract two weeks. For example, if you want to launch your public beta on October 1, plan for September 15. Then, follow this schedule:
- Make no changes to content two weeks prior to launch. This is called a content freeze. Do not alter any words including form field labels or messages after this date.
- Make no changes to code one week prior to launch. This is called a code freeze. No new code or infrastructure after this date. Wait until after launch to make adjustments, starting on the test server.
- Remove the network change or username and password that restricted access during the private beta. Go to a public location outside of government and check if it’s working. Test by opening a web browser tab in private or incognito mode. Test from different networks (for example, from home or using a mobile network). You should be able to freely access and use the service.
- During the public beta, monitor user feedback. As you receive it, add each submission to the backlog and label it as a bug, improvement or new feature. Prioritize items by their value and complexity.
- While the service is in public beta, make critical improvements as needed.