Assessment Overview

There are two types of assessments:

• Group Assessments are each around a month long, allowing a deep-delve into a specific area of Data Science. They make up a total of 60% of the course mark (two, each worth 30%).

• Individual Portfolios are whole-semester activities, individually undertaken to explore areas of data science covered by the lecture material in greater depth. Portfolios make up remaining 40% of the course.

• Formative Assessments (that do not contribute to grade):
  • Assessment 0 (Due Week 3)
  • Portfolio 0 (Due Week 3)
• Summative Group Assessments: total 60% (each 30%)
  • Assessment 1: Supervised Prediction (First group assessment)
  • Assessment 2: Data at Scale (Second group assessment)
• Individual Portfolios: total 40%
  • Individual Portfolio: Statistical Machine Learning

The Assessments are together in the Individual Portfolio, but are also linked separately for reference from the appropriate Block of the timetable:

• Portfolio Block 02
• Portfolio Block 03
• Portfolio Block 04
• Portfolio Block 05
• Portfolio Block 06
• Portfolio Block 07
• Portfolio Block 08
• Portfolio Block 09
• Portfolio Block 10
• Portfolio Block 11

Guidance on Individual Portfolios

The Portfolio is assessed for blocks 2-11. Block 1 is marked similarly but is formative, i.e. does not contribute to your mark. The deadline is in assessment preparation week of TB1. In each block contains two activities:

1. Multiple choice questions submitted via Noteable (log in via Blackboard). These should be straightforward, either direct from your notes or with simple experiments you can conduct as extensions of the Workshop. These are worth 20% of the Portfolio mark.
2. Long-form reflective questions that should require a deeper understanding of the course material and may require you to undertake further reading or experimentation. These are worth 80% of the Portfolio mark.

You may take the multiple-choice component at any time and it is recommended that you do this when you work through the Workshop content. The long-form content is submitted at the end of the course, and you are recommended to make a first draft/note form attempt when you first see the content, and reflect back on it in a finessing stage during the examination preparation time (in lieu of an exam).

Length and format of long-form portfolio

Your Portfolio should give a one-page answer to one question of your choice from 5 Blocks (2-11). Therefore the whole Portfolio is only 5 pages long. However:

• The goal is not to make you undertake a length-finessing exercise. If the content you provide appears as if it would fit on one page after such an exercise, you can submit is anyway. There is a strict limit of 8 pages for the portfolio content, with answers that are clearly too long being be penalised.
• You can however submit Supporting Evidence as an appendix to the portfolio. It will not be directly assessed but may be used as evidence to support your claims, i.e. any statements you make with supporting evidence will be more favourably interpreted, but if your statements are carefully given and correct the evidence is not essential. This is not limited. Appropriate content is RMarkdown files knitted to pdf, Jupyter Notebooks, etc.

Guidance on Group Assessments

There is a complete Example Assessment.

Undertaking a group project online is a difficult process that requires care and planning. Help for planning your project is given in Block 1, and includes:

• 1.3.3 Workshop Lecture on Assessments, listed completely in Block 01.
• The Example Group Assessment, which you should go over carefully.
• Appendix 1: Preparation List.
• Appendix 2: Replicability, which explains how to make your project run reliably on others’ computers.
• Appendix 3: GitHub, which explains how to use GitHub.
• Appendix 5: Bluecrystal, which is our High Performance Computing Infrastructure.
• The Equity Formula for redistributing marks.

The individual assessment instructions has significant guidance. These extra thoughts give context.

Comment on Markdown reflections:

The PDF versions of the example reflections are created using Pandoc and it is trivial:

pandoc -o RachelR_Reflection.pdf RachelR_Reflection.md 

Markdown is an acceptable format, though PDF looks nicer. Referencing is important but don’t overdo it; you might use footers [^ref1], or just place simple labels without worrying about Markdown format at all (label2).

[^ref1]: Lawson D, An Example Reference, 2020.

(label2): Lawson D, A Second Example Reference without Markup, 2020.

Comment on Report formats:

It is completely fine to present a well commented Rmd or ipynb file. You are welcome to try to generate a beautiful PDF in which all of the results are knitted together, but it can be awkward if content is fundamentally separated. Yes, you can create a PDF from each file and merge the PDF, and doing so once is educational, but it isn’t the point of DST.

Please commit your final output. It is generally considered bad practice to commit transient content to your repository. This would include the Jupyter Notebook with all of the content competed, and the html output of Rmd. However, for the purposes of generating a one-off assessed report, it is safest to do this, though best only for your final commit.

This is because it is possible that I cannot run your code, for a good reason or a bad, and therefore I want to see what the output should be.

Why is transient content bad? You repository will get bigger and take longer to process as the whole history of everything that you’ve generated is stored. Text files compress very nicely for this content, but binary objects such as images and data, hidden inside html or ipynb files, compress badly.

Comment on data:

Don’t commit very large datasets to GitHub, and don’t commit modestly large ones unless necessary (and try not to duplicate them). There are file size limits, but it is inefficient. Try to use a different data sharing solution, such as OneDrive, for such data.