Previous Lecture Lecture 22a Next Lecture

Lecture 22a, Mon 11/23

Monday: Getting Ready to Start Coding

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

Today we start work on the three projects for the course:

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

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

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 “todo” 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.

Project Points

The project phase is worth 40% of your grade (see discussion from Lecture 2 and the newly updated Syllabus

In addition, we’ll be using peer evaluations through a tool called CATME to assess your individual contributions to the project’s success. The peer evaluation may apply a multiplier to your project grade, increasing it or decreasing it, per your team’s assessment of your contributions. It is important to be sure that you are meeting your committments to your team for a variety of reasons; your grade is among those.

Project points will be earned by contributing to one of the three open source legacy code projects. You’ll be assigned to a project team, and the project team will be assigned to a set of bug fixes and feature requests. This mirrors real world software development practice.

To earn a “perfect score” (100%) for this 20% component of your grade, your team needs to earn 100 project points. If you only earn 80, then an 80% will be recorded for that 20% of your grade.

Some assignments in the project category are worth more points, and some worth fewer.

If you accumulate more than 100 project points, up to 10 project points may be used to raise your final average in the class up to 2.0 points. (The points will be recorded as extra credit). (Each point raises your final course average by 0.2% ).

You may not earn more than 110 total project points–any points in excess of 110 will not count towards your grade (though you’ll probably learn a lot from having under taken the work to earn them.)

Breakout room activity: turning epics into stories

Choose a leader/scribe. The leader/scribe should share their screen (you may need the latest version of Zoom 5.3.1 to be able to share screens in breakout rooms.)

First, please ask each member of the team to put their “time zone” into the team’s slack channel (both as an attendance check, and to collect this information). (Time zone= Pacific, China, India, European, for example. The notation UTC-8 or UTC+8 may be used also.)

What we will be doing today is turning our epics into stories.

We want to break up the epic into different stories, and get each story into a separate issue on the Kanban board. This will help us be ready on Monday to start work on these stories.

A story is an issue on the Kanban board that has this format.

# User Story

As a ____ I can ____ so that ____

# Acceptance Criteria

- [ ] First thing that should be true when story is done.
- [ ] Second thing that should be true when story is done.
...

# Implementation Todos

Front end:

- [ ] First thing that must be done in the front end code.
- [ ] Second thing that must be done in the front end code.
...

Back end:

- [ ] First thing that must be done in the back end code.
- [ ] Second thing that must be done in the back end code.
...


Testing:

- [ ] Front end tests pass and there is adequate coverage
- [ ] Back end tests pass and there is adequate coverage
...

We’ll talk about what goes into each of these placeholders in lecture, but here are some quick notes.

First, here’s a concrete example of a user story that has all of these:

Edit Page