CS246 Assignment 5 (Group Project) Walkthrough

In recent terms, CS246 has had a partner final project. This means some extra handling for this final project. The following is the list of things you will need to do for the final project.

Please make sure you finish reading ALL of this article and related scripts before proceeding.

1. Determine the groups.
   • Have a question in the previous assignment where students submit the userids of both partners in a textfile. The instructor should know to include this question in the assignment. However, if they do not, you should remind them.
   • You should set up a marmoset project which accepts these files. The current marmoset tests are setup to check the classlist to ensure the userids belong to students who are enrolled in the course but you can change this in later terms if you desire.
   • You will have to add a copy of the current term's classlist for this marmoset test to work.
2. Create the groups list.
   • To do this, you'll have to download the previously mentioned marmoset project. Within the course account, you will find the directory ~/marking/FinalProject/groups/before. Within this directory, a series of scripts that get the groups files into a usable format for the rest of the tasks you will need to complete.
   • There is a README file which tells you more about the scripts, the order to use them in and what they do. By the end of this step, you should have two files "_groups.txt" and "_nogroups.txt".
3. Set up marmoset for groups.
   • You should have a second marmoset page called something similar to "CS246_Project" which you have not yet used this term. You need to create and upload a marmoset classlist so that each group of students shares a marmoset account for the project.
   • Creating the classlist is actually done using a script in the previously mentioned groups directory which is also discussed in the README document.
   • Once you have this file, upload it to marmoset but make sure you do not limit the length of userids to 8 characters as each groups "userid" will be thier names combined which is almost always longer than 8 charaters.
4. Set up file sharing for the students.
   • The instructors should create a document on how to use the uwaterloo Gitlab for their projects. In the case of the course reverting to svn repos, see "Depricated Items" below.
5. Allocating TA time slots.
   • You are responsible for allocating TA to their timeslots. Send them an email well in advance to inform them about A5 demo so they can tell you what time they are avaliable during the demo days.
   • Make sure you uses an Excel spreadsheet or something similar to avoid conflicts. Some rules you should follow:
     • Make sure one TA is only responsible for one project.
     • Make sure one TA is only responsible in one group per time slot.
   • In the end, send the timeslots to the ISC and TA to let them check if they are okay with the timeslot.
6. Setup the webpage for demo time slots.
   • You will find the required files in ~/public_html/cgi-bin/project_booking. You will need to copy the _groups.txt and _nogroups.txt files created in step 2 into this directory. There is a README.txt which explains the scripts.
   • It is recommended to run the emailmissing script about 12 hours before the deadline for signing up for demos to e-mail students who have not booked demos yet. Typically, each TA will only mark one of the offered final projects to make their job easier.
7. Preparing the marking schemes.
   • The instructor may ask you to draft/edit existing marking schemes of the projects. You will come up with a draft of the marking scheme and the instructor(s) will finalize them. Make sure you finishes them early so that
   • Some things to note:
     • Your marking scheme should cover most of the basic functionality of the program, along with a few boundary and edge cases.
     • Marking schemes should be no longer than 5 pages or having more than 70 marks (if you have 1 mark per test case). The untimate goal is to keep the demo at 30min (or whatever time instructor decides), or the demo will be too long if you exceed this limit.
     • The wording in the marking scheme should be clear and concise. One criterion should be no longer than three lines. If you exceed this you might want to split it into multiple criteria.
     • You also need to write/edit the test cases that come along with the marking scheme. Make sure that they are correct. You could try pulling out some submissions in the past term for checking if you are correct.
     • You might want to write up some additional test cases if you feel like so, but get instructor consent first.
8. Conduct the TA training session. Meet with the TAs close to the marking demos to explain the projects and go over the marking scheme. This will lead to the TAs being more prepared for the marking. You should also e-mail them the final projects pdfs so that they can get a chance to read through them before the marking demos.The training session should cover the following points:
   • The time for each demo (currently it's 30 minutes) and the TA should be wrapping up at around 5 minutes left;
   • TAs should go over the marking scheme in a linear fasion;
   • TAs should type a single "make" command (with no arguments for non-bonus version of student program) to compile the program;
   • TAs could choose wheather to enter keyboard input themselves or let the student enter it.
   • Regarding test files:
     • It takes a lot of time for the game to start up, so we have tests that simulates a middle of the game
     • Goal: Allows the demo to go shorter
     • The test cases should be found under the directory where their program is compiled; there will be backup test cases (Yes, the ISA should keep a backup of the test files somewhere) in case it is necessary for student to change the test files.
   • It is perfectly fine if TAs forget what the program should do (or the rules of the game), ask the students to explain it for TAs.
   • Introduce valgrind. Some TAs do not know it, so better give a bref exmaple usage. Tell them how to look for memory leaks and/or other memory errors.
   • Regarding bonus:
     • At the end of demo, TAs should ask what bonus feature students have implemented. Students are expected to show the TA the feature they claimed.
     • TAs should record all the bonus feature down in the marking scheme.
     • After the students left (This is strictly enforced to avoid argument), give a rate of difficulty between 1 to 10.
     • The ISA will determine how many bonus marks to award for each student, to maintain consistency.
9. Print out all the marking schemes. This requires you copying the book_slots file created in step 5 to ~/FinalProject. If a new project is introduced, you will need to make a directory with the name of the file. You should store the marking scheme and a directory of files for testing in the created directory. Running the script makeFile will create the LaTeX file for all marking scheme and the pdf which matches. Make sure that each marking scheme has a multiple of two pages before printing out this pdf. (To make your life easier, you might want to sort booked_slots so the schemes will not need to be sorted afterwards.)'
10. Organize Redemos.
    • Redemo is very similar to demo, but it is often done by you.
    • Almost always get instructor permission before granting a redemo. (Unless instructor says otherwise)

Some things to note about

• When downloading Marmoset submisssions, the names of the directory for each group will be like "-usernam1-usernam2-". Please change to "usernam1-usernam2" for compatibilty of almost all scripts.

Depricated items:

1. Set up file sharing for the students.
   • Recently this has been done with svn repositories but it may be switch to git repositories soon. If svn repositories are still being used, follow the instructions in the README_FOR_CS246_INSTRUCTORS_GROUPS file in the ~/svn. I've recently altered many of the scripts to have a groups version to make the svn repositories easier to check out as a group and these instructions explain how to use the updated scripts. You should post the README_FOR_STUDENTS.txt to Piazza so that students have the instructions to check out the repositories.

-- YangTianZi - 2015-08-13