Repo Standards and Management - RoBorregos/roborregos-web GitHub Wiki

Git repo standards

Github Projects will be used to organize issues. The project will follow the Kanban board design, having these 5 main columns:

  • Icebox: issues not delegated yet.
  • To do: issues already delegated.
  • In progress: issues we are currently working on.
  • Under review: issues with a PR already created to solve them and ready to be reviewed/currently being reviewed.
  • Done [can only be modified by the PM]: issues already accepted and merged.

Issues

Specific objectives to perform, such as update the content in a view, fix responsiveness bug, create a view, etc.

To be able to move an issue from "In Progress" to "Under Review" you have to mark all checkboxes of the Merge Checklist in the issue.

Branch standard

To create a branch use:

git checkout –b [branch-name]

The branch name depends on the purpose of the branch:

  • feature/: Regular issues where something has to be developed (react component).
    • Ex: feature/membersGrid
  • hotfix/: For small changes (typos, responsiveness arrangement, adding an image to the gallery, etc)
    • Ex: hotfix/memberTitleTypo
  • content/: For changes in the content of the page (update of images/data)
    • Ex: content/timeline
  • docs/: Docs or readme changes`

How to submit code and PRs

To create a Pull Request you should follow this process:

  1. Choose one of your issues
  2. Branch from develop with a specific name to the issue, use camelcase
  3. Make your modifications in the corresponding files
  4. Check your code by running:
    • yarn eslint src
    • yarn flow check src
    • yarn test
  5. git pull and push
  6. Make the PR of your branch to Develop
  7. Check that everything on the Merge Checklist is done

Project Roles

  • PM
    • Checks PRs
    • Defines issues and their priorities
    • General support of anything about the project (testing,
  • Front-end/Content/Designer Developer
    • Solves issues in PRs

Note: If the PM wants to take a Developer Role she/he must choose one or two people to check their PRs.

Workflow

Sprints

Sprints can be done according to the PM's preference, but we recommend this structure:

  1. Have a weekly meeting at the start of the week.
  2. Putting a PR update limit to 24 hours before the weekly meeting, so that PM has time to review them and developers have time to correct/modify them.
  3. Have two-week sprints.

Meetings

In the meetings, each person has to give a quick update about their progress. Meetings can be also used to discuss:

  • Doubts that cannot be explained by message/discussion in PRs are resolved
  • New design/implementation ideas
  • Issues and their distribution

Workload

The workload depends on the urgency of the update; Usually, what we look for is 4 stars per sprint.