Previous Lecture Lecture 21 Next Lecture

Lecture 21, Thu 11/19

Monday: Understanding our teams' epics

Show: http://ucsb-cs156.github.io/f20/lectures/lect21

Last Thursday, each team was assigned an epic from one of these three legacy code projects:

Section Project Repo
5pm https://github.com/ucsb-cs156-f20/proj-ucsb-courses-search
6pm https://github.com/ucsb-cs156-f20/proj-ucsb-cs-las
7pm https://github.com/ucsb-cs156-f20/proj-mapache-search

Each of your teams has a Kanban board, shown in this table:

  TA LA 5pm 6pm 7pm
a Mara Andrew F20-5pm-a
Searches		 F20-6pm-a
public/member facing		 F20-7pm-a
Search by user, summarize message data by user
b Mara Bryan F20-5pm-b
Personal Schedule		 F20-6pm-b
admin dashboard		 F20-7pm-b
Slack Bot
c Scott Gabriel F20-5pm-c
Department Statistics		 F20-6pm-c
crud operations		 F20-7pm-c
Message Display Improvements
d Scott Tanay F20-5pm-d
Basic Course Search UX + CSV		 F20-6pm-d
course info		 F20-7pm-d
Custom Search via Google

In the “planning” column, on each of your pages, there is one issue that is labelled as an “Epic”.

This issue should remain in your “planning” column on your board throughout the remainder of the course. You can refer to it to come up with the issues that you’ll work on throughout the remainder of the quarter.

Each of your teams has a Kanban board, shown in this table:

  TA LA 5pm 6pm 7pm
a Mara Andrew F20-5pm-a
Searches		 F20-6pm-a
public/member facing		 F20-7pm-a
Search by user, summarize message data by user
b Mara Bryan F20-5pm-b
Personal Schedule		 F20-6pm-b
admin dashboard		 F20-7pm-b
Slack Bot
c Scott Gabriel F20-5pm-c
Department Statistics		 F20-6pm-c
crud operations		 F20-7pm-c
Message Display Improvements
d Scott Tanay F20-5pm-d
Basic Course Search UX + CSV		 F20-6pm-d
course info		 F20-7pm-d
Custom Search via Google

Each of these Kanban boards should have these columns:

Planning Todo In Progress In Review Done
Your teams epic, and issues in the planning stages Issues that are fully ready for someone on the team to pick up and work on Issues that someone on the team is currently actively working on Issues for which there is a pull request ready for review or being reviewed Issues where the PR has been merged to main

These Kanban boards started with one card on them, in the TODO column, representing an Epic.

Each team was asked to:

Reviewing from Thursday

Tasks for today:

  1. Set up a shared Auth0 tenant
  2. Getting your team’s repo running on Localhost
  3. Getting your team’s repo running on your team’s private Heroku deployment
  4. Understanding the stories that the team will get started on

Your task today (and continuing into tomorrow’s lecture as needed) is work as a team to

By “understand at a high level”, what I mean is exploring questions such as these:

What about coding?

My guess is that many teams wont be ready to start coding in earnest until after Tuesday, or perhaps even until the Monday after Thanksgiving Break.

The deadline, by the way, for final pull requests to be ready to review is midnight on Wednesday Dec 9. In the final lecture on Thursday Dec 10, we’ll be doing only code reviews and testing.

The final exam slot on Tuesday, December 15, 2020 4:00 PM - 7:00 PM will be for demos:

Anyway, back to coding: if/when you do start coding, please note that you should do it in this manner:

  1. ALWAYS START BY CREATING A BRANCH. You should not be making changes directly to main.

    To create a fresh branch off of main, do this:

    • git fetch (to update the cloned local repos information about each branch)
    • git checkout main ( to get yourself on the main branch; you’ll create a new branch from main)
    • git pull origin main ( to update main to the latest before you start).
    • Create a new branch, following this naming convention: git checkout -b 6pm-b-NewThingWeAreDoing`

    That naming convention is section-team-description where:

    • section is 5pm, 6pm or 7pm
    • team is a, b, c, or d, and
    • description is a camel, snake or kebab case very short description (no spaces or special chars) of the new feature you are implementing, e.g. crud-for-courses, slack-bot-mapache-command, search-by-ge, etc.

    It may not be clear right now why having a branch naming convention is important. It will become more clear as you begin working and need to coordinate with members of your team and other teams on merging pull requests, and resolving merge conflicts. Being able to see at a glance where a given pull request is coming from and what it’s trying to accomplish is quite handy.

  2. Work on the branch. Do all your commits to that branch, and push it frequently

    • git add filename1 filename2 filename3
    • git commit -m "xy - what you changed and why" (xy are your initials; make it xy/ab/jk if multiple team members are involved)
    • git push origin 6pm-b-NewThingWeAreDoing (push changes to your branch)

  3. When you are done, do a pull request to the main branch

Edit Page