Skip to content

github-planning.md

Latest commit

 

History

History
130 lines (94 loc) · 3.74 KB

github-planning.md

File metadata and controls

130 lines (94 loc) · 3.74 KB
Raw

GitHub Issues, Projects, and Milestones

EF uses Let's Go as the internal task-tracking tool and connects it with GitHub Issues, Projects, and Milestones through the GitHub API. GitHub stores the developer-facing records used for branches, pull requests, project boards, and release milestones. Let's Go gives the internal team a familiar task view and can sync relevant task status with GitHub.

Let's Go Integration

Let's Go should link internal tasks to GitHub records instead of duplicating work manually.

Expected integration behavior:

  • A Let's Go task can link to a GitHub Issue.
  • A GitHub Issue can be added to the relevant GitHub Project.
  • Milestones in GitHub can represent releases, sprints, launches, or project phases.
  • Status changes should stay aligned between Let's Go and GitHub Projects where possible.
  • Pull requests should link to GitHub Issues so development activity remains connected to the internal task.

Issues

Every meaningful code or documentation change should have a GitHub Issue, even when the work starts in Let's Go. Small typo fixes can go straight to a pull request, but the pull request should still explain the change clearly.

An issue should include:

  • A short, specific title.
  • Context describing the problem or opportunity.
  • Acceptance criteria that define when the work is complete.
  • Links to designs, Slack threads, docs, or related pull requests.
  • Labels for area, type, and priority when available.
  • An assignee once someone starts the work.

Recommended issue title format:

[Project] Short action-oriented title

Examples:

[EF Connect] Add mentor availability filters
[Website] Fix mobile navigation spacing
[Docs] Document Gitflow production tag process

Projects

GitHub Projects track the state of active work across repositories.

Use the project board to answer:

  • What work is ready to start?
  • What is currently in progress?
  • What is blocked?
  • What is in review?
  • What has shipped?

Recommended project statuses:

  • Backlog: accepted work that is not ready to start yet.
  • Ready: scoped work that someone can pick up.
  • In Progress: actively being worked on.
  • Blocked: waiting on a decision, dependency, access, or another change.
  • In Review: pull request opened and awaiting review.
  • Done: merged or otherwise completed.

When you start work, assign yourself and move the issue to In Progress. When you open a pull request, move it to In Review. When the pull request is merged, close the issue and move it to Done. If a linked Let's Go task exists, keep its status aligned.

Milestones

Milestones group issues and pull requests into a planned delivery window or release.

Use milestones for:

  • Release planning.
  • Sprint or monthly planning.
  • Launch checklists.
  • Large project phases.

Each milestone should have:

  • A clear name.
  • A target date when known.
  • A short description of the goal.
  • A focused set of issues that can realistically be completed together.

Avoid using milestones as broad categories. Labels and projects are better for categorization.

Labels

Each repo may have project-specific labels, but these common label types are recommended:

  • Area: frontend, backend, docs, design, devops.
  • Type: feature, bug, chore, refactor, question.
  • Priority: priority: high, priority: medium, priority: low.
  • Status: blocked, needs review, needs design, needs decision.

Pull Request Linking

Link pull requests to issues so GitHub can close the issue automatically when the pull request merges.

Use one of these phrases in the pull request description:

Closes #123
Fixes #123
Resolves #123

If a pull request only partially addresses an issue, link it without an auto-close keyword:

Related to #123