PgM Team repository

The primary repository for the team is the pgm_team repo. This document describes how we use it.

Status files

We use the git repository to record status documents. An example file is in the root of the repo.

The example file is a guideline. You do not need to strictly match it. Add or remove information as you see fit. It is not machine-parsed, so as long as the meaning is clear to the rest of the team, variations in style and content are okay.

The following guidelines apply:

  • Active work should be in a markdown file in the current/ directory.

  • Previous work should be moved into the past/ directory.

  • If you have additional supporting information with no better place to store it, create a directory with the same name as the markdown file.

  • The top of the markdown file should contain basic information about the project (e.g. main contact, links to resources, etc)

  • Put the latest updates at the top of the update section (so updates should appear newest to oldest)

  • Add updates as frequently as appropriate, but generally at least once a month. For most projects, once every one or two weeks is probably better.

  • Include links to specific issues, etc that are blocking the work or that are major unresolved decisions.

Remember that these files are so that others can step in to help you if needed. Try to document what you’d want to know if you were coming into the project.

Pagure setup

Tags

We use the following tags (or "labels"):

  • documentation. This is used for issues related to documentation. Generally that means things we document in the PgM Team (or other program management) documentation.

  • support request. We use this to tag requests from other teams in Fedora.

  • schedule. This tag is for issues related to the Fedora Project Schedule.

  • spins keepalive. This tag is for issues related to the semi-annual keepalive process for Spins and Labs.

Is there another tag you think we should use? Propose it!

Priorities

The respository intentionally does not have any priorities defined. We will need to use it for a while and see what naturally arises for us.

Boards

The respository intentionally does not have any boards set up. We will need to use it for a while and see what naturally arises for us.

Roadmap

The respository intentionally does not have any roadmap milestones defined. We will need to use it for a while and see what naturally arises for us.