/
Fedora 4 Development Process

Fedora 4 Development Process

Owned by Esmé Cowles (Unlicensed)
Jan 23, 2015

  1. Sprint organization

    • Sprints last two weeks.
    • Developers sign up on wiki (blocked out in 6-month chunks).
    • There are no dedicated developers, the only full-time staff is tech lead.
    • The focus of each sprint is tailored to interests/strengths of developers working on the sprint.

  2. Sprint process

    • The tech lead touches base with developers the week before a sprint starts, especially with new developers to make sure they have the accounts setup, understand the process, to discuss priorities, etc.
    • The tech lead organizes the backlog with tickets, sometimes pre-assigning them.
    • Sprint meetings are usually led by tech lead, but sometimes by senior developers when tech lead is away.
    • Sprint planning: 2-hour meeting on the first Monday of the sprint to talk through goals of the sprint, assign and estimate tickets.
    • There are often several unassigned tickets that developers can pick up if main work gets done early, is blocked, etc.
    • Daily standup: quick meeting to touch base, identify blockers, etc.
      • Larger discussions should not happen during standup, they should be taken offline or to separate meetings (or just defered to end of standup so anyone not involved/interested can drop off).
    • Weekly committers' call: open to larger group, place to discuss architectural questions, get feedback, etc.
    • Sprint wrapup: meeting on last Thursday of the sprint to triage any tickets not finished, review how the sprint went, and discuss process.
    • Focus on wrapping up all tickets by the end of the sprint, because developers rotate off and back to their main jobs, and aren't available to clean up.

  3. Ticket process

    • Used Pivotal Tracker in main development phase.
    • Have switched to JIRA entering maintenance phase, because of better integration with community tools (wiki, shared accounts).
    • Try to keep tickets small and focused (ideally single-day).
      • When you hit complexity or pre-requisites, create tickets for them.
    • Try to work only a couple of tickets at a time.
      • Finished tickets can be reviewed.
      • Unstarted tickets can be picked up by another developer.
    • Start tickets you are working on.
    • Work in a fork and/or branch.
    • Open Github pull request when done (doesn't have to be squashed).
    • Link between PR and ticket to make it easy to navigate.
    • Travis CI automatically builds each PR, will get feedback if your PR doesn't pass.
    • Mark ticket finished to signal it's ready for code review.

  4. Code review

    • Code review is usually done by tech lead, but is sometimes delegated.
      • Currently working to increase the number of senior developers who can do code review to remove this bottleneck.
    • Focus on test coverage, code style, sustainability.
    • Other developers brought in to review and comment when appropriate.
    • Tickets are rejected pending addressing code review comments (don't take this personally).
    • Additional updates pushed to the same branch/PR.
    • PRs squashed before merging.

  5. Documentation and test coverage

    • Documentation and tests are generally the responsibility of the developer writing the code, and required before PRs are accepted.
    • Sometimes broken down into separate tickets, but still usually the same developer and the same sprint.
    • There is a periodic focus on improving documentation and test coverage.