Skip to content

Project Guidelines

Jump to bottom
Charlie edited this page Nov 22, 2024 · 38 revisions

Templates

PR template

The PR title should follow : Actual title
The PR should follow this structure :

# Actual title
[if the PR is still a draft] **This PR is still a WIP**
## Description
This PR introduces... It closes issue #...
## Changes
## Files 
#### Added
- file 1
- file 2
- ...
#### Modified
#### Removed
## Dependencies Added
- dependency 1 for XXX
- ...
## Testing
## Screenshots (if applicable)

Review Template

Make sure Code Reviews follow this structure :

## Summary
## Important (which includes)
#### Code Quality
[This includes readability, consistency]
#### Functionality
[This includes correctness, edge cases]
#### Performance (if applicable)
#### Security (if applicable)
## Testing
## Documentation
## Suggestions
## Steps before PR approved
[Explicit the changes you want the assignee to implement before you approve this PR]

Task description

Below is the template for task descriptions. For subtasks, see below.

## Description
Provide a brief overview of the task, its purpose, and how it fits within the current sprint or project goal. Include any necessary context for the team.

## Done
Specific, measurable criteria to confirm the task is complete.
- **Functional Requirements:** Detail what must be completed, such as behaviors, outputs, or UI elements.
- **Quality Standards:** Ensure consistency with baseline standards: code quality, performance benchmarks, error handling.
- **Testing Requirements:** Specify required tests (e.g., unit, integration) and any code coverage targets if applicable.

## Preconditions
Optional: Add any dependencies or prerequisites required before starting, like related tasks, resources, or tools, as necessary.

## Steps to Completion
Break down the task into actionable steps. Make sure those steps are separable so that you can easily create subtasks/subissues from these:
- [ ] ...
- [ ] ...
- [ ] ...

## Points to Consider / Known Risks
Optional: List any potential risks, technical constraints, or dependencies. Mention limitations or assumptions, such as “Requires access to external API” or “Limited by current design framework,” if applicable.

Subtask description

### Description:
This is a subtask from #000. Brief description.

### Done:
- ...
- ...
- ...

Guidelines

PR

For most tasks, a PR should be small, touch few files and have few commits. Don't forget to add labels. Draft a PR as soon as possible (from 1st commit), then mark it as ready for review only when you're finished with it. If you have changes to make following a blocking review, mark it as draft again.
Try to link every PR to an issue but if not possible, don't forget to add the PR itself to the Scrum Board (Sidebar > Project > Scrum Board then add the corresponding task tags).

Review

Ask questions when code is unclear. Be constructive and complimentary. Prefix code comments with "nitpick" if unimportant. "LGTM" if you have no remarks.

Communication Protocol

  • Notify the group about the problem
  • Meet up in person: create issue (@Coaches), create BRANCH
  • Do other tasks while concerned classes are fixed
  • Assign responsibilities to solve the problem (Scrum Master)
  • Notify the group when fixed
  • (If someone is absent, ask for clean PR)

Product Backlog maintenance

The PB should contain :

  • Epics as items with two tags: one user story tag (Epics) and one ID tag (Epic)
    • We apply the ID tag to the corresponding tasks and user stories
  • All user stories that are not completely implemented

When a user story in the PB is implemented, we place it in the corresponding "Done" section. At the beginning of each sprint, the PO creates tasks corresponding to the user stories/epics he wants to implement.

Branches Naming Conventions

Format

<type>/<epic>/<description>
All lowercase, use slashes (/) to indicate folders and hyphens (-) to separate words. For instance, feat/authentication/view-model

Types

  • “feat”: used for developing new features
  • “fix”: used to fix bugs
  • “release”: used to prepare for a new production release
  • “docs”: used to write, update or fix documentation
  • more if needed, following the Conventional Commits type naming convention if applicable (for consistency and ease of use)

Epics

Use epics as defined in the scrum board.

Description

The name should be descriptive and concise.

Stand-Up Meetings

Place: BC rooms

  • Mondays 11:15 - 11:30 (Zoom)
  • Wednesdays 11:15 - 10:30 (**In person !!)
  • Fridays 9:15 - 10:00 (In person !!)

SM and PO Timetable

Date Milestone / Week / Sprint Scrum Master Product Owner
7 Oct - 13 Oct M1 / W5 / S1 Alejandra Bruno
14 Oct - 20 Oct M1 / W6 / S2 Charlie Laura
21 Oct - 27 Oct Vacation - -
28 Oct - 3 Nov M2 / W7 / S3 Laura France
4 Nov - 10 Nov M2 / W8 / S4 Bruno Alonso
11 Nov - 17 Nov M2 / W9 / S5 Alonso Charlie
18 Nov - 24 Nov M3 / W10 / S6 France Alejandra
25 Nov - 1 Dec M3 / W11 / S7 Bruno Laura
2 Dec - 8 Dec M3 / W12 / S8 Harrishan Alonso
9 Dec - 15 Dec M3 / W13 / S9 Alejandra France
16 Dec - 22 Dec M3 / W14 / S10 Charlie Harrishan

Clone this wiki locally