Working on GitHub

This document outlines the rules to contribute and to create issues to a project on the organisation Canonical-websites

Table of content

How can I contribute?

In the Canonical web-sites organisation, we work with Github. All types of work are tracked as GitHub issues. You will find in this section how you can contribute to this organisation.

Report bugs

Well done you have found a bug! Go to the corresponding project, it should be in the Canonical websites organisation and open an issue. These are the steps you need to follow to add an issue:

  • Title: should describe your feature/bug
  • Description: fill this template
  • Add labels: see labels description
  • Submit your issue: we will try to fix it as soon as possible!

Suggest enhancements

If you think details could change on our websites you can suggest enhancements by creating a new issue. These are the steps you need to follow to suggest enhancements:

  • Title: should describe your feature/bug
  • Description: fill this template
  • Screenshots: Don’t forget to add screenshots of suggestion designs to explain
  • Add labels: see labels description
  • Submit your issue: we will try to fix it as soon as possible!

Work on an issue

You are welcome to pick up any unassigned issue on any of our projects - simply assign yourself to the issue, fork the project and start work. Once you finish your work open a pull request.

Pull requests

In this section you will find a description on how to create a pull request for a Canonical Web-sites project. These are the steps to create a pull request:

First contribution

Forking the Repository

If you want to create a pull request you will need to fork the project you are working on. From your fork, create a branch and work on your issue.

Setting up Git Config

When you have your own forked project, you may want to make sure that your local project is kept up to date with the remote upstream project. Traditionally, this can be done through the Github UI where you can manually sync your fork with the remote upstream project, however you can also set up your Git Config file so that you can fetch from the remote upstream through your CLI.

[remote "upstream"]
	url = https://github.com/canonical/<CANONICAL-PROJECT>.git
	fetch = +refs/heads/*:refs/remotes/upstream/*

Setting up your Commits and PRs

To ensure successful integration of your work with the remote upstream branch, be sure to familiarise yourself with the following Git commands before you open up a Pull Request.

Most projects have their own PR or MR process. Discuss with your team to see which approach suits your use case best.

Styleguides

When making changes to any of our projects, please follow our styleguides:

Along with any common community standards (e.g. Python’s PEP8).

If we haven’t written a styleguide for the language you’re working in, please feel free to suggest one.

Merging review process

Here are the steps that need to be completed before merging:

  • All review labels have to be at +1
  • Your pull request must be approved by at least one person
  • Any automated checks must have passed
  • Special care should be taken to ensure there have been no further changes requested
  • Any team member may merge a Pull Request once it has met the above requirements. This will usually be the person who added the final +1.

Templates

Issues template

## Summary

[please describe the issue]

## Process

[list the steps to replicate the issue]

## Current and expected result

[describe what happened and what you expected]

## Screenshot

[if relevant, include a screenshot]

Pull request template

## Summary

[please describe the issue]

## Process

[list the steps to replicate the issue]

## Current and expected result

[describe what happened and what you expected]

## Screenshot

[if relevant, include a screenshot]

## Issues

[if relevant, include a list of issues that this pull request will have an impact on]

Last updated a month ago.

Help improve this document in the forum.