1 of 13

Project Boards

SP00: Design Sprint

MT26

Slides by: Kiernan Almand and Andrew Lockard

UNC Department of Computer Science

COMP 423: Foundations of Software Engineering (Spring 2025)��Sit in your assigned tables!

2 of 13

  • SP00 - Due Sunday
  • RD31 - Google Engineering Practices: Code Review - Due Sunday

Announcements

!

!

3 of 13

  • Issues
    • Task or problem that represents some work to be done
  • Tickets / Cards
    • Colloquial/informal term used to reference an item/issue on your Project Board
  • Pull Requests (PR)
    • Proposal to merge code you’ve written into your team’s stage branch
  • Code Review
    • Process of reviewing your teammate’s PR to determine if it is ready to be merged

​

Definitions

​

4 of 13

  • An easy way to organize your development, right in GitHub
  • Allows you to link your Pull Requests to milestones in your development
  • Customizable task manager that allows you to define fields to track and visualize work
  • Demo from a COMP523 Team: https://github.com/orgs/unc-csxl/projects/3

​

​

Project Boards

​

5 of 13

  • Detailed unit of work
  • A Good Issue Has
    • Title: Brief but descriptive name in command format (“<Command> <Stuff>”)
    • Description: Summary of the task.
    • Why?: Motivation for the issue
    • Acceptance Criteria: What needs to be done/conditions for acceptance
  • Examples:

Issues

​

6 of 13

  • Work as a team to create a detailed issue and linked project board card
  • Submit a screenshot of your issue on Gradescope for attendance

COMP 423: Foundations of Software Engineering (Fall ‘24)

Issues: Your Turn

​

SP00: Design

Project Boards and PRs

CL27

  • A Good Issue Has
    • Title: Brief but descriptive name in command format (“<Command> <Stuff>”)
    • Description: Summary of the task.
    • Why?: Motivation for the issue
    • Acceptance Criteria: What needs to be done/conditions for acceptance

​

!

7 of 13

Presentations: 5 Minutes

Looking for:

  1. Each member of the team speaks in the presentation�
  2. Quick introduction to feature being attempted and what value it presents to users�
  3. Click-through, with explanation and narrative, of one user story�
  4. Click-through, with explanation and narrative, of second user story�
  5. New routes needed and likely AI integration points discussed

8 of 13

  • Good for working on in-progress tasks in a separate flow from completed code
  • Allows multiple people to work on different things at once without immediate conflicts
  • Often there are branch naming conventions to follow
  • Use one “feature” branch for each issue on the task board
    • Then use “sub-task” branches for individual units of work on that ticket

COMP 423: Foundations of Software Engineering (Fall ‘24)

Branching: Best Practices

​

SP00: Design

Project Boards and PRs

CL27

GET

POST

PUT

Implement TODOs branch

stage

DELETE

9 of 13

  • Formal way of requesting to merge your feature branch into stage
  • Connect to Issues on your Task Board by either:
    • “Development” section of your Pull Request
      • Found on right-side of Pull Request page
    • Keywords in your Pull Request
      • <Keyword> #<Issue Number>
      • closes #10, fix #3, resolved #23 etc.

COMP 423: Foundations of Software Engineering (Fall ‘24)

Pull Requests (PRs)

​

SP00: Design

Project Boards and PRs

CL27

10 of 13

  • Be concise but descriptive and use markdown formatting!
  • A good PR includes:
    • Title: Brief but descriptive name in command format
    • Description: Summary of the changes
    • Major Changes: List of changes and important points
    • Testing: Testing you have done
    • Future Considerations: Future features or fixes, other comments

COMP 423: Foundations of Software Engineering (Fall ‘24)

Writing a Good PR

​

SP00: Design

Project Boards and PRs

CL27

Example: https://github.com/unc-csxl/csxl.unc.edu/pull/107

11 of 13

  • Necessary step for merging a PR into the stage branch
  • Provides an extra set of eyes on the code before merging 👀
  • GitHub will not allow you to merge code from your branch onto stage until at least one other teammate has approved it
    • You can assign someone to review your code use the “Reviewers” section
  • Should be completed in a timely manner (~1 day)

Code Reviews

​

12 of 13

  • Be concise but descriptive and use markdown formatting!
  • Things to consider:
    • Does this PR do what it is intended to?
    • Does the code comply with codebase best-practices?
      • Using up-to-date Angular syntax (@if as opposed to ngIf)
    • Is the code clear/will future developers understand it?
      • Naming conventions, flow of code, etc.
    • Is the testing sufficient?

Writing a Good Code Review

​

13 of 13

For the rest of class:

    • Work with your teams on SP00.
    • We recommend trying to go ahead and turn your stories into detailed cards and issues in your project at a small enough granularity that

Work Time