How to deliver Copy updates

Once you receive a copy update task you should:

  1. Find the repository
    The repo name should match the domain name, i.e. for ubuntu.com it will be github.com/canonical/ubuntu.com
  2. Fork the repo, clone your fork
  3. Identify what needs to change
    The change will be described in the copy document (shortly “copy doc”). A copy doc can be found in the Jira task inside the “Attached forms” section → “Add Copydoc link” field.
    The changes will be described as suggestions inside a copy doc. If you are still not sure about what needs to change, reach out to the reporter of the Jira task.
  4. Implement the change
    Create a new branch forked from the “main” branch** and add changes to the codebase.
    ** There is an exception to this, please read point 10 below.
  5. Test the changes
    Locally you can run dotrun to test the changes.
  6. Make sure you have djLint installed on your machine as that’s the linter/formatter we use for our Jinja templates. This topic about linting and formatting includes steps how you can install and use it.
  7. Create a PR:
    • fill in the description by specifying what changed
    • add link to the copy doc in the description
    • provide a link to a page in the demo instance for peers to have a quick access to a changed webpage(-s)
    • add “Code needed” and “QA needed” labels
  8. Request a review, i.e. in the “Web code review” Mattermost channel. If applicable, assign and @mention the UX/visual reviewers that are assigned in the Jira ticket, and add the appropriate labels to the PR.
  9. Once the changes are merged and deployed, open the copy doc file and accept the suggestions that you have implemented.
  10. When the copy update is related to an Ubuntu version that is not released yet, you should first create a branch for that release (if it does not exist yet), e.g. 24-10-release. Then you should base your copy update branch on this branch, and merge your changes there. This way, release-related updates can be prepared ahead of time. The release branch will be eventually merged into main when the right time comes.

Please note that copy updates are considered as high priority tasks and should be delivered (merged to “main” branch) within 2 days. Release-related updates that are requested weeks in advance do not need to be delivered so quickly, but should be merged to their target release branch at least 1 week ahead of the release.

Last updated 3 days ago.

Help improve this document in the forum.