Previous Lecture lect03 Next Lecture

lect03, Thu 04/08

Thursday Breakout: Meeting Logs, Initial README, Team Agreements

Homework for Tuesday

Teams are Assigned

You should have been:

Today, you’ll also again be put into a Breakout Room with your team during the section time.

Lecture: First ntroduction to Web Technologies (HTML, CSS, JavaScript)

The first half of today’s class will be a presentation on the basics of web app technologies.

The Slack: _articles vs. _help channels

On the Slack, we will make available several pairs of channels that have the endings _articles and _help, for example:

In each case:

The #js_* channels are for everything JavaScript related

Note that the #js_articles and #js_help channels will be used for all technologies that relate to JavaScript-based technology stacks, including:

The #mobile_* channels are for everything related to mobile ecosystems and app development

If you aren’t sure, you can always use #teaching-team

A few more special purpose channels:

Absences

If you need to miss class for an unavoidable reason, please notify:

Please send these notifications:

This is a matter of showing respect for your team.

Then, as soon as possible after the class, check with your team to see what you missed. It should be a team responsibility to help one another with unavoidable absences.

Unavoidable reasons might include:

Of course, unavoidable absences should be rare if you are going to remain in good standing with your fellow team members, folks that are depending on you to do your part for the team.

Breakout work today

Today, during your breakout sessions, you should accomplish the following tasks:

  1. Add an initial README.md to your github repository (details below)
  2. Hold a quick standup meeting and log it on GitHub!
  3. Plan to meet for a Sprint planning meeting (if not done yet) and finish the discussion of your team agreements / team norms and record whatever agreements you are able to reach in team/AGREEMENTS.md (details below)

Initial README.md

One member of the group should go to the page for their main project repo, e.g.

On your own team repo, click on the green button Add a README

In your README.md, put the following:

Holding and capturing a Scrum Meeting on GitHub: Start documenting your team’s work

In the meeting notes, write the name of your project, your mentor, and the names of the people on your team (recording who is present, and noting those that are absent.)

Example:

Project: Teaching CS148

Mentor: Self-Mentored ;)

Meeting Time: lec03

Type of meeting: <one or several of [sprint planning, daily scrum, sprint review, retrospective, story time]>

Team: Sabrina Tsui [x], Tobias Höllerer [x], Chen Zhu [ ], Jayleen Li [x], Vincent Tieu [x], Shiran Wang [x], Paul Kuang [x]

Scribed Discussion:

Jayleen created web technology stack slides. Submitted for comments by the teaching team. Next task: Prepare Lab01. No current roadblocks

Chen is absent but announced it beforehand. He is currently grading h00. No current roadblocks.

Tobias …

Sabrina…

Vincent…

Shiran…

Paul…

Taking attendance for today’s lab, and making sure your name is on the flip chart with a ✓ or an ✗ is a portion of your group’s grade for this week’s lab.

NOTE 1: The first team member listed should be the ‘lead’ for this meeting, i.e. a team member who is responsible for recording meeting information this time (also called a ‘scribe’). In the future, this person likely called/coordinated the meeting. Meeting leads are different from project owner and Scrum master and we expect/require that this responsibility rotates among your team members!

NOTE 2: Having a group member (or two) absent will not cause your group’s grade to be reduced. However you are require to record attendance in order for the group to get full credit for the lab. In the future, team members that cannot make it to a meeting should message their information to the meeting lead beforehand.

NOTE 3 In the future, meeting time can also be something like lec05 (for Lecture 5), or 01-17-2pm for an out-of-class-time meeting.

In your github repository, you will structure the documentation of your meetings into ‘sprints’ (your team will decide on the Sprint length / interval. Typically, for this class a Sprint is one or two weeks).

From now on, please document all your meetings in the github repository in this way.

team/AGREEMENTS.md

In addition to the NORMS.md file that was part of the last lab session, please create, in your team folder, a file called AGREEMENTS.md.

In this file, you’ll first put the names of the members of your team.

Then, you’ll enter a list of agreements. These are things that you all agree are good practices for creating a harmonious productive team.

As a suggestion, the first few team agreements, might be these:

  1. When one of us is absent for an unavoidable reason, we will let the other team members know on the team slack channel, in advance when possible, as soon as possible afterwards when not.
  2. We will each try to keep such absences to a minimum.
  3. Those of us that are present will do our best to share with the absent team member(s) what they missed and help them get back up to speed.
  4. We will all do our best to contribute to the teams success.

You then might add a few more.

Consult this article for ideas:

If you run out of time

If you run out of time, the agreement discussion can be continued outside of class over the slack, and during the next lab and/or lecture.

If you finish early

If you finish all of the above, you can start on a discussion of the following things. These are discussions that will carry over into Tuesday and Thursday lectures, but you can start them now if you’ve finished the items above.

Add to your README.md:

Which tech stack

We’ve provided some information for you already, and when we formed groups, mentors probably discussed stack possibilities a bit already. So in some groups, there is likely to be a quick consensus on which tech stack to use. But you should still discuss the pros/cons of each, and share your preferences with one another.

If you have questions, or need guidance, ask the course staff (Prof. Hollerer, Sabrina T., Jayleen L., Paul K., Shiran W., and Vincent T.).

Planning your app

For the second item, focus on writing a single paragraph in which you go into a bit more detail about what you plan for your project.

Some things to consider:

How many different kinds of users are there, and what are their roles?

Examples:

Think about the fact that your app will be available on the public internet. If your app allows user contributed content of any kind, there is the potential for inappropriate content (spam, or worse) to be added. One option is restrict your user base to folks with an @ucsb.edu login; we can provide example code for both Spring Boot and next.js that you can build on to add this feature to your app.

What will each different kind of user be able to do in your app?

Future steps: .gitignore and LICENSE.md

Two future steps will be to also add .gitignore and a LICENSE.md

The .gitignore will depend on your tech stack choice.

For the LICENSE.md: