New request flow === The Funkwhale collective handles 3 types of user request: 1. [New feature requests](#New-feature-requests) 2. [Feature enhancement requests](#Feature-enhancement-requests) 3. [Bug reports](#Bug-reports) Each request type has its own workflow to ensure the best possible user and developer experience. ## 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. ## Request workflows ### New feature requests A **new feature** is a new behavior in the product. 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**: 1. A user or developer suggests a new feature **in the forum** 2. Members of the collective discuss the new feature and answer the following questions: * Should the feature be included in the product? * What is the expected behavior of the feature? 3. If the collective decides to include the feature, the development team creates an **epic** for the feature 4. The responsible working groups are assigned tasks to complete their part of the spec 5. Once the spec is complete, the **epic** is marked as **Ready** 6. The feature is selected for development 7. 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 8. Once all tasks are complete, the feature is **tested** to ensure it aligns with the spec 9. The feature is released ```mermaid flowchart TD Start(User requests a new feature) --> Discussion([The collective discusses the feature]) Discussion --> Decision{Should we include the new feature?} Decision -- no --> Exclusion(The feature is not included) Decision -- yes --> createEpic[The development team creates an epic] createEpic --> Spec([Working groups complete the spec]) Spec --> SpecFinish[The epic is marked as Ready] SpecFinish --> Selection[The feature is selected for development] Selection --> Implementation([The responsible groups are assigned tasks to work on]) Implementation --> Test[The feature is tested against the spec] Test --> Release(The feature is released) ``` ### Feature enhancement requests 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**](#New-feature-requests) This is the workflow for a **feature enhancement**: 1. A user or developer suggests a feature enhancement **in the forum** 2. Members of the collective discuss the enhancement and answer the following questions: * Does this enhancement break or change the expected behavior of the feature? 3. If the collective decides to include the enhancement, the development team creates an **issue** for the enhancement 4. A related issue is added for the responsible working group(s) to update the spec with the enhancement 5. Once the spec if updated, the issue is marked as **Ready** 6. The issue is selected for development 7. 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 8. Once all tasks are complete, the enhancement is **tested** to ensure it aligns with the updated spec 9. The enhancement is released ```mermaid flowchart TD Start(User requests a feature enhancement) --> Discussion([The collective discusses the enhancement]) Discussion --> Decision{Does the enhancement change behavior?} Decision -- no --> Exclusion(The enhancement is not included) Decision -- yes --> createEpic[The development team creates an issue] createEpic --> Spec([Working groups update the spec]) Spec --> SpecFinish[The issue is marked as Ready] SpecFinish --> Selection[The enhancement is selected for development] Selection --> Implementation([The responsible groups are assigned tasks to work on]) Implementation --> Test[The enhancement is tested against the spec] Test --> Release(The enhancement is released) ``` ### Bug 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**: 1. A user or developer reports a bug **in the forum** or **in the issue tracker** 2. The development team assesses the report against the spec and confirms the bug 3. The **issue** is assigned to the responsible working group(s) 4. The issue is marked as **Ready** 5. The issue is selected for development 6. 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 8. Once all tasks are complete, the bugfix is **tested** to ensure it aligns with the spec 9. The bugfix is released ```mermaid flowchart TD Start(User reports a bug) --> Reproduction([The development team confirms the bug against the spec]) Reproduction --> Assignment([The issue is assigned to the responsible group]) Assignment --> Ready[The issue is marked as Ready] Ready --> Selection[The bug is selected for development] Selection --> Implementation([A bugfix gets implemented]) Implementation --> Test[The bugfix is verified against the spec] Test --> Release(The bugfix is released) ```