Table of Contents
When projects are first created they are marked "invisible to students". This means that students cannot see the project when they log in to the SubmitServer.
Instructors and TAs can see invisible projects. Thus you can create a project and let your TAs try it out for a couple of days before officially making it "visible" to your students.
![[Warning]](warning.png) | Warning |
|---|---|
| Once a project is made visible, there's no way to make it invisible again (without changing the value of the field in the database). |
![[Note]](note.png) | Note |
|---|---|
| An Invisible project is only invisible when a student logs into the server, but the project still exists and will accept submissions. Thus, students can submit to an invisible project using either the command-line submission tool or the Course Project Manager Eclipse plugin. This can happen if student CVS repositories or project skeletons are made available before the project is made visible. These submissions will be tested normally and should not present any problems except for potential confusion to the students that they are submitting but can't find the project on the server. |
To create a project, select the "create new project" link from the course main page. The following sections describe some of the fields in this form.
The default when students use a release test is to reveal simply the names of some number of tests failed (the number of release tests to reveal information about is of course configurable).
After using this policy for several semesters, it became clear that there are situations where students need or deserve more information to help them learn about their code. For example, if a student submission fails many release tests because of run-time exceptions, then it will be useful for them to know the type of exception and perhaps the line number in their code where the exception is generated.
Similarly, there are many situations where the test-drivers used for Makefile-based projects (C/C++, Ruby, etc) generate output that the students could greatly benefit from seeing. Thus we have created some new policies regarding how much information to reveal that are detailed in the following table.
Table 10.1. Stack Trace Policies: How much information to reveal when students request a release test
| policy | language(s) | description |
|---|---|---|
| test name only (default) | any | Reveals only the name of the test case |
| line number of exception | Java only | Reveals a partial stack trace including the name of the exception and the line in the student code that generates the exception. Will hot-link the line that generates the exception, if possible. Does not reveal all methods called in student-written code leading up to the exception. |
| line number of exception, if covered by public/student-written test | Java only | Reveals the partial stack trace as described by the "line-number of exception" policy, but only if there is a public or student-written test case that covers the source of the exception. This rewards students that are writing their own test cases to achieve better coverage. |
| full stack trace | any | Reveals the full stack trace for Java or everything that was printed to stdout and stderr for other languages. |
Table 10.2. Best submission policies
| policy | description |
|---|---|
| Last Submission (Default) | The best submission for a category (on-time or late) is the last submission that compiles in this category. |
| Release Test Aware | Best submission for a category (on-time or late) is the max of the last submission that compiles and the highest-scoring release tested submission. |
| Note |
|---|---|
The best submission policy takes into account extensions granted to individual students, as well as late penalties. |
| Note |
|---|---|
We don't simply pick the highest scoring submission overall to prevent students from taking the "shotgun" approach of submitting 200 versions of a program knowing that we'll pick the best one. By choosing to release test a submission students are (hopefully) telling us something about the quality of a submission. |
When creating a project, you have the choice between two types of late penalties:
- Late Constant: The value specified will be subtracted from the score of each submission. For example, a Late Constant penalty of 20 means that a late submission worth 85 points would be adjusted to 65 points.
-
Late Multiplier: The value specified will be multiplied by the
score of each submission. For example, a Late Multiplier penalty
of 0.8 means that a late submission worth 85 points would be
adjusted to 68 points.
Warning The Late Muliplier will be multiplied by the score, so to subtract 20%, be sure to set the Late Multiplier value to 0.8!
| Note |
|---|---|
To have a project without a late deadline (i.e. where late submissions are worth zero credit), make the on-time and late deadlines the same. |
Whether a submission is ontime, late or very-late is computed dynamically for each student based on the deadline for the project and any extension granted to that student. Thus it is possible for a submission to change from late to ontime when an extension is granted or if the deadline is changed by the instructor.
Only the on-time and late submissions are used when determining the "best" score for a project. Very-late submissions are kept for a variety of reasons:
some classes have a policy that students must make a "good faith" attempt to implement each project before the semester ends,
students are somtimes granted extensions retroactively.
Instructors and Superusers can update all the parameters that were specified for a project when it was created including the project deadlines and release token rules.
From the main course page, go to the project page by selecting the
viewlink next to the project in question.From the project page, select the
Utilitieslink.In the Utilities page, select the
Update this Projectlink and make any desired changes in the project update form. ClickUpdate Projectto save changes.