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. (Timeline: setup with A4)
    • 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. (Timeline: after the group deadline)
    • To do this, you'll have to download the previously mentioned marmoset project. Within the course account, you will find the directory ~/marking/FinalProject/group. 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.(Timeline: when A5 is posted)
    • 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.
    • Copy the marmoset classlist to ~/.classlist_project. This allows marm_sql with the command line argument -p to be used to download submissions from Marmoset.

  4. Set up file sharing for the students.
    • File sharing facilities given to the student from term to term vary.
    • GitLab: The instructors should create a document on how to use the uwaterloo Gitlab for their projects.
    • SVN: In the case of the course reverting to svn repos, see "Depricated Items" below.
    • Remind students not to post their assignment publicly in anyway before the assignment deadline.
The following points are only relevant if project demos are being used.

  1. Allocating TA time slots. (Timeline: after A5 posted)
    • 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.
  2. Lab booking. (Timeline: after TA time is available)
    • Make sure to book Linux Lab instead of Mac Lab to avoid potential X Window issues.
  3. Setup the webpage for demo time slots.(Timeline: approximate one week after A5 is posted)
    • 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.

  4. Preparing the marking schemes.(Timeline: after A5 is posted)
    • 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.
    • Recently, marking has been moved to using a webpage through the CS246 webpage: https://www.student.cs.uwaterloo.ca/~cs246/cgi-bin/project_demo/demo.cgi. A detailed README file is also available under the project_demo directory on the course account.
    • 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 ultimate 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.
  5. Conduct the TA training session. (Timeline: one or two days before the first demo)
    1. 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.
  6. Dowload students' projects to the course account (Timeline: right after A5 is due)
  7. 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)
In the event that demos are not being used:

  1. Prepare marking schemes:
    • The instructors will have some idea of the marking scheme for the tests. Develop tests to comply.
  1. Testing: Prepare tests to do automated testing
    • If using Marmoset, prepare scripts as with any other marmoset project to test the accuracy of the final projects.
    • If not using Marmoset (not recommended), submissions will be downloaded and tested after the deadline. Create some set of scripts to test the projects localy after the deadline.

Online Marking Schemes

Marking can now be done through the cs246 webpage. To maintain this for new projects, a checklist will have to be made. Using html, create checkboxes with unique names for each category. The format of this files should look similar to the marking schemes in ~/public_html/cgi-bin/finalProjects (eg cc3kMarkScheme.txt). Add any new marking schemes to this folder. Additionally, create a file project-name-Categories.txt which contains the names of categories being marked. This file will be used to order the criteria when students marks are calculated. As such, do not change the order of criteria after marking has begun.

Additionally, the files ~/public_html/cgi-bin/final.cgi will need to be edited so that only the final project being offered are listed.

Each group's marks will be saved to ~/public_html/cgi-bin/finalProjects/marks/proj-name--userid1-userid2-userid3.csv. When marking is complete, proj-name--*.csv can be combined to create the mark spreadsheet for each project.

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.
  • Download Marmoset submissions using marm_sql using the command line argument -p.

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.
Printing marking schemes. Now done online.

  1. 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. (To make your life easier, you might want to sort booked_slots so the schemes will not need to be sorted afterwards.)'
-- KirstenBradley - 2014-12-17

-- YangTianZi - 2015-08-13

Edit | Attach | Watch | Print version | History: r15 < r14 < r13 < r12 < r11 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r15 - 2017-03-10 - GangLu
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback