- Course Components
- Assignments and Due Dates
- Monday Lecture Schedule
- Wednesday Domain Meetings
- Lab and Office Hours
- Working in Groups in Remote Environments
- Academic Integrity
In DSC 180B, you will execute on the project proposal you drafted with your group in DSC180A. This entails working closely with the group you formed last quarter to follow through on your idea, producing a complete project that includes:
A code repository that conforms to best practices in data science workflows,
A written report that summarizes and explains the output of the project,
Visual presentations of the material, aimed at general and technical audiences,
Oral presentations of the material, in varying length, and for different audiences.
Your group will work on the project openly as a part of your greater scholarly community (i.e. your section), contributing/receiving feedback to/from your peers. At the end of the quarter, you will be able to represent your project effectively to a diverse audience: possibly presenting it to the greater HDSI community, potential employers, family, and friends.
This course revolves around your work as a group and the deliverables your group produces. Regularly scheduled check-ins encourage steady, incremental progress without last-minute obstacles.
Lectures are pre-recorded videos that you may watch asynchronously. They will contain context, specifics, and standards to which your course assignments will be held.
Discussion section will be synchronously held; attendance is required. These will be held over Zoom and consist of giving project updates to instructors and classmates.
Lab Hours and OH will be held over Zoom from Canvas (exact structure, TBD).
The course deliverables are described below (with links to assignments therein):
Participation in the process of project development involves giving weekly updates in Discussion Section, submitting updates to Canvas, and giving assigned feedback to your peers.
Refining your group’s proposal and schedule at the begining of the course and after each project checkpoint.
The project artifact consists of a code pipeline following the best practices outlined in the methodology portion of the course, documentation for users/developers, and a report summarizing the project and analyzing the results.
The project artifact includes 3 project checkpoint similar to those in 180A.
A primary and secondary visual/written communication of your project, along with a checkpoint.
Two oral presentations: An elevator pitch for a general audience and a longer slide-based presentation aimed at a technical audience.
|Component||Assignment||% of Grade|
|Participation (10%)||Weekly updates||5%|
|Proposal (5%)||Refinements (3x)||5%|
|Project Artifact (30%)||Code Pipeline + Documentation||21%|
|Visual/Written Comm (40%)||Primary||20%|
|Oral Communication (15%)||Elevator Pitch||5%|
Each assignment will be graded on an A/B/C/F scale, without the precision of plus/minus grades (A=4, B=3, C=2, F=0). The reason for this policy is twofold:
Grading each project on the same scale, across domains, requires using broad guidelines for satisfactory work.
Stripped of physical campus resources and space, the suitability of student work environments in this rushed delivery of remote instruction vary wildly. Such variability adds more noise in student output, which needs to be met with a decrease in grading precision.
Assignments will be graded using the following rubric:
|A (4.0)||Accomplishes the task accurately, completely, and clearly. Code is clear, effective, and efficient. Written component is concise, at the appropriate level, and correct. Oral component (when applicable) is effective both visually and explanation; is within the time limit.|
|B (3.0)||Accomplishes the task well, but lacks some completeness or clarity. Code runs but lacks some aspect of clarity, effectiveness, and or efficiency. Written component is logical and generally correct, but lacks either clarity or accuracy. Oral component (when applicable) is moderately effective and/or slightly outside the time window.|
|C (2.0)||The task is somewhat accomplished, but lacks significantly when it comes to completeness and clarity. Code present but does not accomplish the task up to the standards of a data science graduating senior. Written component lacks substantial clarity/correctness. Oral component (when applicable) significantly lacks effectiveness/clarity.|
|F (0.0)||The task largely remains unaccomplished. Code lacks completeness, structure, and is unclear. Written component lacking required information to understand what you did and/or your results. Oral component (when applicable) is nonsensical/unclear.|
Final grades will be computed using the grade-points above, using the proportions given in the course components table. Letter grades will be assigned using the standard university cutoffs.
The DSC program is offering students the option for students to take 180B on a P/NP basis, with a P counting toward graduation requirements. This policy is meant to give students the option to reduce stress in their life during this continuing crisis, without penalizing their plan for graduation.
You have the option to change from a letter grade to P/NP (or vice-versa) through the end of week 10, so this is not a choice you have to make early in the quarter.
Written assignments are in part graded against the rubric that each group creates in their project proposal, which specifies the tasks that each group member is responsible for. These written (and coded) assignments will be submitted with a list of the group members and the portions of the assignment each member completed.
Assignments will largely be graded uniformly as a group. However, if the balance of quality or quantity of work is significantly non-uniform, grades may be apportioned out individually. This is especially relevant in relation to this quarter’s P/NP policy.
Assignments in the participation category are due on a regular schedule:
|Title||Turned in How?||Regular Due Date|
|Weekly check-ins||Canvas||Tuesdays 11:59PM PDT|
|Peer-feedback||Canvas||Tuesdays 11:59PM PDT after each assignment is due|
The assignments and due dates for the remainder of the assignments are in the table below:
|Title||Turned in How?||Due Date (Sunday after end of week)|
|“Getting Started” assignment||Gradescope (code) + Turnitin (report)||Week 1|
|Project Checkpoint #1 (Data); proposal revision (again)||Gradescope (code) + Turnitin (report)||Week 2|
|Project Checkpoint #2 (EDA); proposal revision (again)||Gradescope (code) + Turnitin (report)||Week 4|
|Elevator Pitch||Recorded and uploaded||Week 5|
|Checkpoint for visual presentation (e.g. blog)||Gradescope (code) + Public website||Week 6|
|Project Checkpoint #3 (full project artifact)||Gradescope (code) + Turnitin (report)||Week 7|
|Long oral presentation||Live (and recorded) presentation on Zoom||Week 8|
Lecture will be pre-recorded and should be watched by the Monday given in the schedule below. Each lecture contains specifics necessary for properly developing your project and completing assignments according to their grading rubric.
|1||Planning software projects and agile development|
|2||Developing software on GitHub in teams|
|3||Effective (visual, oral) communication principles|
|7||More effective (visual, oral) communication principles|
Wednesday domain meetings will be synchronously held; attendance is required. These will be held over Zoom and consist of giving project updates to instructors and classmates.
Before meeting each week, each group must submit a written version of their project update on Canvas (one submission per group).
Lab hours and office hours will be available on both a drop-in basis, as well as by appointment, over Zoom.
Mondays from 9:00-11:00 are reserved for methodology questions.
Fridays from 9:00-11:00 are domain office hours (may vary by domain).
Other office hours will be announced on Canvas.
Zoom meeting details for office hours will be posted on the Canvas calendar.
Setting up a comfortable, quiet environment to work is important for success on your project. However, it’s a reality that both students and staff will be working in spaces not necessarily set up as a work environment. As such, we all will endure and tolerate hiccups in both delivering and taking the course. Good communication is the key to handling such hiccups.
If you are sharing a physical environment that regularly makes it difficult to do the required coursework or attend any required course component in real-time, please reach out to course staff early.
If you experience hiccups that make working difficult, share them early. Course staff and classmates may have helpful tips to solve or alleviate these problems. If such problems are affecting your ability to make a deadline, surfacing them early will help course staff accommodate you.
Success in this course requires working closely with your fellow group members. You are required to have regular meetings with your group. Consider using multiple modes of collaboration and communication with your groups, including audio-visual (e.g. via Zoom, Hangouts, etc), synchronous chat (Slack, Hangouts, Whatsapp, etc), and asynchronous chat/writing (Canvas Groups, Piazza, Google Docs, GitHub issues).
In DSC 180, we expect you to work hard, act with integrity, and accurately represent any work you produce as your own. The capstone project is unusual for a DSC course, as all of the work you produce is public and meant to be shown off to the world! However, this both increases the likelihood of exposing such behavior, and magnifies the consequences of any act of cheating or plagiarism:
- If your work copied the analysis of a book, paper, article, or blog: the work’s author might notice and contact you, or a prospective employer might notice and pass on your job application.
- If you copy the code of someone else: this may be noticed as above, or at the very least, you won’t be able to represent the code well when asked about its details (say, in a job interview).
In the course of your capstone project you are required to read, understand, and incorporate others’ work into your project; this is how progress is made! However, you need to:
- Always cite work when both directly quoting or paraphrasing/summarizing others’ work.
- Always cite code in comments when using others’ code (even Stack Overflow).
We understand that understanding the line between building off of others material and plagiarism takes practice. You are expected to try your best by acting with integrity and err on the side of caution. All reports will be turned in to Turnitin with the Similarity Matching feature made visible to you; this transparency will help you to improve the quality of your citations. You are also encouraged to ask course staff for guidance, when unsure!
On each of the checkpoints, the content-similarity feature is visible upon submission to help you better learn to quote and paraphrase sources. Remember, you should be using outside sources and you should be citing them! On the final project, the content-similarity feature will be turned off.
Of course, following the UCSD Policy on Integrity of Scholarship is required in this course. Ignorance of the rules will not excuse you from any violations.