Project management

For this project we are in a relatively unique situation where we have a live product but we are also aiming to "ship" feature-complete at a future date to allow migration away from osu-stable (the old osu! client). For this reason, for the time being we have a primary focus on completing remaining tasks required to "go live".

Assigning Issues

Using the "assign" feature on github should be limited to tasks you are actively working on imminently. Reducing the number of issues assigned to people lets us track what people are actively working on, and make sure we don't get stuck with backlogs of tasks that are "assigned and blocked" on certain people.

• If you start on an issue and realise the scope is too large, unassign it when you stop working on it.
• If you have tasks you want to get to in the future but not today, track it locally (in your own task manager or otherwise) rather than using github assignee.
• As an exception: if there's an issue which can only be solved by you then it's fine to keep it assigned for longer periods.

Labels

Labels track rough areas of concern or types of issues. Labels are defined as <category>:<identifier>. At most, one identifier should be chosen per category per issue.

Current categories:

• area The area in the game that the issue relates to
• platform The operating system that the issue can be reproduced on
• priority The importance of an issue that the core team should address before a release
• renderer The graphics renderer that the issue relates to
• ruleset The ruleset that the issue relates to
• size (with a slash) The ranking of lines of code that a PR changes
• type The type of an issue, if it can be defined into a common type

We also have special labels for other use cases:

• blocked An issue which is blocked on another task or external fix.
• compatibility-change Changes to be considered in the future which break compatibility with osu!stable scores.
• dependencies Pull requests that update a dependency file
• epic A feature of core importance (and also requiring considerable effort and thought).
• framework-fix-required An issue that can't be resolved without changes to osu!framework.
• good first issue A good place to start contributing to this project without going too deep.
• missing-details Can't move forward without more details from the reporter
• .NET Pull requests that update .net code
• pending-new-renderer Issues that may be fixed when using the new renderers
• next-release Pull requests which are almost there. We'll aim to get them in the next release, but no guarantees!

Projects

Projects track large areas of the game which are required for live. These can be considered "epic" issues. We don't directly use the "kanban" views and generally these are used for tracking purposes at a high level.