To prevent our issue tracker getting filled up with issues that are hard to follow, we propose a new way of handling features. You can see the whole flow in more detail in this pad.
Specification-driven design
The Funkwhale collective follows a specification-driven design. Each feature is outlined in a specification (spec) that contains the following information:
- The problem the feature addresses
- The solution the feature proposes
- The scope of the feature
- The behavior of the feature
- The availability of the feature
- The working groups responsible for delivering the feature
Each request type follows a workflow based on this design philosophy. You can find a template for feature specs here.
New feature request
A new feature is a new behavior in the software. This can be a new API, a new task, or an addition to the application. Each new feature must be defined by a spec before development begins.
This is the workflow for a new feature:
- A user or developer suggests a new feature in the forum
- Members of the collective discuss the new feature and answer the following questions:
- Should the feature be included in the software?
- What is the expected behavior of the feature?
- If the collective decides to include the feature, the development team creates an epic for the feature
- The responsible working groups are assigned tasks to complete their part of the spec
- Once the spec is complete, the epic is marked as Ready
- The feature is selected for development
- The responsible working groups are assigned tasks to complete their part of the spec. These tasks are linked together to show if any tasks block other tasks
- Once all tasks are complete, the feature is tested to ensure it aligns with the spec
- The feature is released
Feature enhancement request
A feature enhancement is an extension to an existing spec. This can take the form of additional fields in APIs or adding existing information to the frontend app. A feature enhancement doesn't change the behavior of a feature, it only extends it. If an enhancement changes the behavior, it is considered a new feature.
This is the workflow for a feature enhancement:
- A user or developer suggests a feature enhancement in the forum
- Members of the collective discuss the enhancement and answer the following questions:
- Does this enhancement break or change the expected behavior of the feature?
- If the collective decides to include the enhancement, the development team creates an issue for the enhancement
- A related issue is added for the responsible working group(s) to update the spec with the enhancement
- Once the spec if updated, the issue is marked as Ready
- The issue is selected for development
- The responsible working groups are assigned tasks to complete their part of the spec. These tasks are linked together to show if any tasks block other tasks
- Once all tasks are complete, the enhancement is tested to ensure it aligns with the updated spec
- The enhancement is released
Bugfix reports
A bug report aligns a feature to its spec. Bugs should be reported when a feature does not align to what is outlined in its spec or if there is a performance issue. A bug report doesn't change the behavior of a feature.
This is the workflow for a bug report:
- A user or developer reports a bug in the forum or in the issue tracker
- The development team assesses the report against the spec and confirms the bug
- The issue is assigned to the responsible working group(s)
- The issue is marked as Ready
- The issue is selected for development
- The responsible working group(s) are assigned tasks to fix the issue. These tasks are linked together to show if any tasks block other tasks
- Once all tasks are complete, the bugfix is tested to ensure it aligns with the spec
- The bugfix is released
