• Specifications Grading
• Assignments
• Submitting Assignments
• Using External Sources and AI Tools
• Extensions and Resubmissions
• Grade Reporting
• Using GitHub
• Working with Git Branches

Specifications Grading

We use specifications grading in this course in an effort to motivate you to engage at whatever level you decide. Whether a “C+” is fine or you feel you must get an “A”, either is perfectly acceptable from my perspective, and the grading scheme describes precisely what is required to get that grade—no more, no less. Here’s how it works:

1. You select which assignments to submit. A certain minimum set is required; how many additional assignments you complete beyond that minimum is up to you.


2. Completed assignments are graded using the Satisfactory/Needs Improvement/Unsatisfactory (SNU) scale. The SNU scale is defined as follows:
   
   

     Satisfactory (S)

   Work is complete and demonstrates adequate understanding of the material.

   • Code works as specified
   • Code contains no/very few minor errors
   • Code implements error handling
   • Specific references provided

     Needs Improvement (N)

   Work is mostly complete and/or demonstrates some understanding of the material, but is missing one or more critical elements.

   • Code works partially as specified
   • Code contains some errors
   • Code implements no error handling
   • Only general references provided

     Unsatisfactory (U)

   Work is incomplete and/or demonstrates limited/no grasp of the material.

   • Code does not work as specified
   • Code contains significant errors
   • No references provided

   
   


3. Your final grade is determined by a "bundle" based on your level of participation and performance, as defined in the table below.



Requirements	Grade Bundles
		A	A–	B+	B	B–	C+	C	C–, P/F
Watch all required videos
Group 1 assignments @ "Satisfactory"	10	10	10	9	8	8	8	8
Assignment A14 @ "Satisfactory"
Group 1 assignments @ "Needs Improvement"	—	—	—	1	2	2	1	—
Group 2 assignments @ "Satisfactory"	3	2	2	2	1	1	1	1
Group 3 assignments @ "Satisfactory"	2	2	2	2	1	1	1	—
Group 4 assignments @ "Satisfactory"	2	2	2	1	1	1	—	—
Pass Quizzes (50% is passing grade)	3	3	2	2	2	1	1	1
Final Exam Grade	>75%	>70%	>65%	>60%	>60%	>55%	>50%	>45%

= required, "—" = not applicable

Assignments

Assignments are submitted via GitHub as described below. You also have the option to re-submit some unsatisfactory work; see Resubmissions and Late Resubmissions below.

A note on the workload in this class: Over the years, students have reported the amount of time they spent on each assignment; the average range of hours spent is shown in parentheses next to the assignment name. Your experience may be very different, but I want you to have some indication of what to expect going into this class so that you're not surprised later in the quarter (when it will likely be too late to make changes to your schedule). Pay particular attention to these numbers if you're taking multiple classes that have final projects due in the last couple of weeks of the quarter: the workload in this class also becomes much heavier during that time, and some students have found it difficult to cope. We cannot help you if you take on more than you can handle, so please be advised now.

* Dates may change depending on our progress in class. Notifications of any changes will be posted on Ed Discussion.

Submitting Assignments

You must submit assignments in this class via GitHub. A note on submission is provided in each assignment; run the command shown to create your repository for the assignment. If the command does not work your GitHub account is most likely not in our GitHub team. You must send me your GitHub ID to be added to the GitHub team, otherwise your assignments will not be graded.

The basic flow for using GitHub to submit assignments is described below. Please ask on Ed if anything is unclear; do not wait until the last minute to tell us that you’re having GitHub issues and that your assignment will be late.

The due date and time is listed at the top of each assignment, e.g., Due: Thursday, January 29, 2026 at 5:30pm CST.

We will treat the most recent commit timestamp displayed in GitHub as your submission time. In the case where an assignment specifies that you include a commit message (e.g., “A14 - Final Submission”), we will consider the most recent commit with that message as the submission time. Please make sure you understand this. You will receive a “U” if there are any changes to your code or commits after the deadline—please don’t modify the repository or any other part of your code in the AWS environment after the deadline.

Using External Sources and AI Tools

I fully expect you will use external sources (such as StackOverflow) to research potential solutions and find sample code for your assignments. While you may consult and be guided by such sources, you are expected to write your own code and supporting artifacts.

Please see the class policy on usage of AI tools.

Extensions and Resubmissions

Under our grading scheme you have the option to request a 24-hour extension to submit an assignment late or to resubmit an assignment in order to improve your grade. During the quarter you may exercise these options up to three times, in total (for either resubmissions or 24-hour extensions, with the exception of assignment A5 which may not be submitted late and is not eligible for resubmission since the solution will be discussed in detail during class).

Extensions

Late submissions will not be considered for grading but you may request a 24-hour extension. If you want to exercise this option, you must notify us before the due date/time by posting a private note in Ed Discussion. Any submission beyond 24 hours after the due date/time will not be graded. Please don’t ask for exceptions.

Resubmissions

If you receive an “Unsatisfactory” or "Needs Improvement" grade on an assignment you may revise and resubmit it. The following apply to resubmissions:

• You may only resubmit an assignment if the assignment was originally submitted on time, i.e., by the deadline specified in the assignment.
• Revised assignments must be resubmitted within three days of receiving the original grade on the grading branch in your GitHub repository—no exceptions/extensions.
• You may not resubmit an assignment more than once.

If you decide to revise your work and resubmit, please do the following:

• Create a branch named <assignment_number>-resubmit, e.g., if re-submitting Assignment 14 you must create branch a14-resubmit.
• IMPORTANT: Post a private note on Ed informing us that you have resubmitted. If you don’t notify us via Ed we will not know that there is a resubmission for grading and, if the AWS environment is cleaned up in the interim, your efforts will have been wasted.

After reviewing your resubmission we will update the grade.txt file in the grading branch in GitHub.

Grade Reporting

When your assignment is graded, we will add a “grading” branch to your repository. This branch includes a file called grade.txt that contains your grade and comments/feedback from the grader. You are expected to review the grading branch and, if you have questions/concerns about the accuracy of your grade that you would like us to review, please post a private note on Ed—please do not email me or the TAs directly.

Make sure that you have GitHub notifications turned on so that you're notified when the grading branch is pushed to your repository. You are responsible for checking the grading branch in a timely manner if your wish to re-submit an assignment (see above) or otherwise have your grade reviewed.

The grade in your grading branch is not the final/official grade. Once the TA pushes the grading branch to remote I will review and then publish grades on Canvas (as Canvas is the only officially sanctioned system for communicating grades). There will typically be a few days lag between your grade being pushed to GitHub and my posting it on Canvas. Please do not wait until Canvas grades are posted before resubmitting because it will usually be past the re-submission deadline.

Using GitHub

There are countless GitHub “quickstart” guides online (e.g. git—the simple guide ), but for our purposes you can just follow this process:

1. Create a remote repository on GitHub. For each homework submission, simply run the command provided in the assignment document. For example, if I were submitting A3, I would run mpcs git accept vasv a3 ("vasv" is my GitHub ID, not my CNetID) and that would create a repo called a3-vasv.
Note: This command must be run on an EC2 instance, and will only work if you have activated the "mpcs" environment.

2. Clone the repository to your laptop or EC2 instance:
   

   $ git clone https://github.com/mpcs-cc/a3-vasv.git
   Cloning into 'a3-vasv...
   ...
   remote: Total 4 (delta 0), reused 3 (delta 0), pack-reused 0
   Unpacking objects: 100% (4/4), done.
                                   



3. Add your homework file(s) to the working directory:
   

   $ cd a3-vasv
   $ touch a3.py
                                   



4. When you're ready to commit your new file(s) to the GitHub repository, first add them to the staging area (there is no output from this command):
   

   $ git add .
                                   



5. Create a commit (with an appropriate comment):
   

   $ git commit -m "My first A3 commit"
   1 file changed, 58 insertions(+)
   create mode 100644 a3.py
                                   



6. Push the local changes to the remote (GitHub) repository:
   

   $ git push origin main
   Enumerating objects: 7, done.
   ...
   Writing objects: 100% (6/6), 532 bytes | 532.00 KiB/s, done.
   Total 6 (delta 1), reused 0 (delta 0)
   remote: Resolving deltas: 100% (1/1), done.
   To https://github.com/mpcs-cc/a3-vasv.git
   1afd4fd..74fe452  main -> main
                                   



7. Repeat the "add → commit → push" cycle every time you want to update the remote repository.

Working with Git Branches

Since you’re the only one working in your repository you can make and commit all changes directly into the main (default) branch. However, when the work becomes a bit more complex during the capstone project, you will need to use branches to avoid breaking any working code.

Let’s say your main branch contains code from past assignments, and you have one last assignment to complete. You can create a branch and work on the assignment in that branch:

$ git checkout -b 'a20'
Switched to a new branch 'a20'
                        

Now make all your changes. Once you have it working, commit updated code as before:

$ git add .
$ git commit -m "Finished the CAPSTONE!!"
[a20 8deb085] Finished the CAPSTONE!!
1 file changed, 1 insertion(+), 1 deletion(-)
                            

Then, merge the a20 branch back into main:

$ git checkout main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.
$ git merge a20
Updating 74fe452..8deb085
Fast-forward
... | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
                            

And, finally, push main to the remote (GitHub) repo:

$ git push
Enumerating objects: 5, done.
...
Writing objects: 100% (3/3), 271 bytes | 271.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To https://github.com/mpcs-cc/gas-instructor.git
74fe452..8deb085  main -> main