Go back to Course Home Page

CSCI 1913 Course Rules

This is a large course with many parts, so there will be more course rules and policies than in most classes. We’ve done our best to organize this for easy reference, and make it as direct as possible. Please give it a read, and if anything is unclear, let professor Picoral know.

Lecture Rules

1. Computer use is allowed in lecture so long as it’s not disruptive. One of the most disruptive things you can do is to have volume on, so I recommend checking that your personal electronics are muted in-class.

2. Like computer use – “side-conversations” should be careful to be non-disruptive to others. In general, if you’re in the lecture room, I assume you’re here to learn – not to work on assignments, chat with others, etc. Learning is an active task, not something you can plan on doing by letting lecture wash over you.

3. Speak up about issues in lecture This ranges from the obvious (the screen isn’t projecting correctly) to “easy fix” issues (slowing down when coding, scrolling up/down so you can reference past code quickly, etc.) to “harder fix” issues (changing font-size in the future, adjusting layout, font, or color choices to enhance readability, etc.)

4. You can raise your hand to ask a question at any time, but Professor Picoral may not call on you immediately. You can also ask questions through piazza. The professor will try to handle questions asked both ways as soon as she sees them.

5. Lecture will include exercises and questions. These often serve as primary programming practice for our lectures, so ignoring them or not working to help the class solve them often makes future programming tasks like the labs and projects much harder.

Health and Safety Related Rules

If you are sick, or think you might be sick (COVID-19 or otherwise):

• Do not attend lecture or lab.
• Follow standard health-and-saftey guidelines.
• Contact the professor for assistance with any missed lectures/labs.
• Notify course staff if your illness might effect your ability to complete work in a timely manner. UMN Policy explicitly allows for absences due to illness of yourself or a dependent. This includes make-up work or extension as appropriate. If an illness is only short-term (a few days) a doctors note will not be required, but if you miss a few weeks we might require formal documentation.

Because you may not always know if you are infected you should make a point to follow reasonable self-quarantine procedure after any suspected or possible covid exposure.

If you are sick and are unable to complete assignments by the deadline, contact the professor before the deadline to discuss an extension.

Reading Rules

• Reading assignments are generally due Monday before lecture. If there is inconsistencies about the deadlines as shown on zybooks and canvas, please contact course staff so we can clear things up.
• Late readings are rarely allowed except as described by UMN Policy or by explicit agreement with the professor
• Reading grades are based on your score on the in-line participation and challenge questions. These questions typically allow multiple attempts without consequence.
• Reading grades will typically automatically post-over to canvas, but not always – if there’s an issue you are responsible to reaching out to course staff – there’s normally a quick-fix for the issue on our side, but if there isn’t the sooner you let us know the sooner we can reach out for further technical support from zybooks.

Lab Rules

Lab assignments will generally be started in-lab and completed out-of-lab and submitted to gradescope. As such this section will cover lab-meeting rules, as well as lab-assignment grading rules.

Lab Meeting rules

1. You are expected to attend all weekly lab meetings. Obviously, this rule is secondary to the Health and Safety Rules. If you are not attending lab for health/safety reasons, simply notify us about this fact and you can miss without consequence (you will still need to finish the lab assignment, but we can work over email to support you on this).
2. You are expected to work on the current lab in lab. We do not promise to answer questions on non-lab topics topics if on-topic questions are being asked by other students.
3. Please plan to stay until you finish the assignment, or until the two-hour lab session is complete. Arriving late, and leaving early, is disruptive to your fellow students and can be viewed as rude or inconsiderate behavior by others.
4. If you have a question in-lab please raise your hand or get the attention of the TAs.
5. The TAs are there to help you learn and apply programming processes to the lab assignments. While they are instructed not to tell you the answer, they can often help guide your own thinking for how to approach a problem as well as help you resolve tricky software bugs. You should make use of the lab TAs as a learning tool in lab.
6. If your behavior is disruptive, your lab TAs may ask you to leave, if they do, please leave as instructed. If you think they are being unfair, please leave, and then contact Professor Picoral directly about the issue so we can talk it out. “Fighting” the TA about this is itself disruptive and will only make things worse.

Lab Partnerships

You are allowed to, and encouraged to, work with a partner on labs. The maximum group size is three.

1. Work should be shared equally between members of one lab group. You should both fully understand each part of the solution, and be able to answer in-depth questions about it if needed. The professor may refuse credit if we learn that one person did substantially more work than another on a lab.
2. Both names should appear in a comment at the top of every file submitted or edited. This is to help make sure you are fairly attributing your partner. Failure to follow this instruction has gotten students accused of cheating in this class, so make sure you check with every single assignment. Do this even if you only work with your partner on part of the lab, and ultimately want to make two separate submissions so we know why shared code is seen.
3. You are allowed to work with partners not in your lab section – if you do so, note that you’re still expected to attend the lab you enrolled in, and work productively (and independently) for 2 hours each week.
4. Partners can (and should) make one joint submission. To do this, please submit your final version once (under one name) then add the other student to the submission as a group member on gradescope. More information on how to do this is available in gradescope’s guides. Make sure you do this on the final submission (or each submission that “might” be final) as this does not carry over submission-to-submission. 5.. If you worked with a partner in lab, but finished the assignment alone, both students should make sure both names are on both submissions (to avoid academic dishonesty by not crediting collaborators) and then both students should independently submit lab through gradescope (so the two versions can be graded separately)
5. You are allowed to change partner each lab. You are not required to keep the same partner the whole semester.
6. Do not share work between groups Unless specifically allowed in the lab instructions.

Lab assignment submissions

Lab assignments are generally due at 5pm on Monday.

1. If your lab is later in the week you may find it useful to review the lab PDF before your lab time. You should not, however, start pre-writing the lab. Sometimes key instructions or announcements are made in-lab which affect how you would want to approach the programming problem.

2. Labs can be resubmitted on gradescope as many times as you want, however if you make a submission after your deadline, this is the version we will grade.

3. We recognize that sometimes life gets in the way (in ways ourside of UMN Policy), or sometimes you will want to prioritize another class over this one. As such, your lowest two lab scores (by percent) will be dropped when computing your final grade. If you think this might happen you should communicate this clearly with your lab partner – don’t “surprise them” with this. NOTE Don’t think of this as two skippable labs – this is your safety net for when things go wrong – you don’t want to “use it up” early in the semester.

Lab assignment resources

You are expected to exercises good judgment both in limiting which resources you use to seek assistance with lab assignments, and how you document what assistance you get.

1. TA support is always considered reasonable If you are getting substantial help from a TA it is reasonable to leave a comment citing their assistance in the code. This can help us understand situations where two groups get similar help from one TA and therefore have similar code upon submission.
2. Use good judgement about which resources you use while some online sources are reasonable (as will be discussed in class) these are mainly about the programming languages themselves. any online resource that explains how to solve a specific problem is expressly forbidden (even if that problem is only a small sub-problem of an ongoing assignment).
   • Using an inappropriate resource and citing it will result in a reduced grade on the assignment, which may be up to a 0 at the professor’s discretion.
   • Using an inappropriate resource and not citing it will result in a grade of 0 on the assignment, and may lead to a grade of F in the course (as this is a violation of the academic integrity policy for the course)
3. Use code comments to cite any source you reference. If you take any amount of code or software design from any source for your submission, you are expected to leave a clear notification of reuse in a code comment which includes a link to the source. Note – this is separate from the above rule. It is one thing to copy code from chegg or an AI assistant – it’s another issue altogether to claim the work of others as your own.
4. Use only approved software libraries Unless a software library has been explicitly discussed in lecture you should ask permission to use it. This includes both external libraries and the language built-in software libraries. Some problems can be trivialized by using third-party (or in some rare cases, built-in) software libraries. We design the problems with a certain practice and skill-building in-mind for you, so it’s important not to use unexpected software libraries that change the nature of the task.

Lab grading

Labs will contain both “automatic” and “manual grading”

1. Automatic grading will be shown to you at submission these points are real points so you should strive to earn all of these.
2. Automatic tests Sometimes produce useful output Like any other “error message” you may need to do some work to “decode” the error message, but you shouldn’t ignore it.
3. Often, however, the autograder will not be useful for testing and debugging most labs have an accompanying tester file that runs essentially the same tests in a more debuggable form. This should be your preferred debugging tool.
4. Some automatic graders will be very fussy – requiring specific numbers of spaces, or capitalizations/spellings of words. You are expected to meet these expectations, and will lose points for being unable to resolve these issues. (Naturally, we can help you resolve them in office hours or online. small stuff like this is often easy to fix)
5. Manual grading will take longer to get back to you, and will look at issues outside of what can be identified by direct testing: code style, efficiency, reasonable approaches. In Computer Science it is not, in fact, sufficient for your code to work. You should aim for easy to read, logical code that makes sense and makes the solution to the problem clear. As such you may lose points for bad approaches, or bad readability even if your code works.
6. Manual grading may also overrule the automatic grading in cases where students clearly sought to cheat the autograder. Passing tests (like the autograder) is not enough to promise your code works – always code against the requirements as listed in the lab PDF.

Project Rules

We will have three Projects over the semester, these will be substantial affairs taking place over 3 weeks

1. Projects are to be completed individually You cannot work with a partner on lab in any way. (not even to brainstorm solutions – as that is part of the programming process.)
2. Projects follow the same “resources” rules as labs See those rules for rules on what resources are allowed, what level of dicsussion is permitted, and the importance of citing your sources.
3. Late Projects are generally not allowed without prior authorization from the professor.
4. Projects will be submitted through Gradescope, and will generally have a small automatic grader, and a larger and manually graded component.

Quiz rules

There will be one in-class on-paper quiz per week, usually on Wednesdays.

1. Quizzes are very short (one question). You have 10 minutes to complete it in class, but it takes 5 minutes on average to complete it.
2. The question will be directly related to the reading exercises and labs.
3. Quizzes help you prepare for exams.

Office Hours Protocol

Office hours are a key component of success. They permit flexible one-on-one interaction not possible in class. The instructor and TAs encourage you to visit.

General Rules

• Check the office hours calendar before attending – this will show when the office hours are, where they are being held (or if they are digital office hours) These details can change over the semester, so please check every time.
• Check for announcements on slack – last second issues around office hours are often announced first on slack. Check there in case of issues.
• Be aware that office hours tend to be busy before major deadlines. This is unavoidable in a class this large. Try to be patient with the course staff if this happens and remember that we’re doing everything we can to fairly help everyone we can as much as possible.
  • Unfortunately, this sometimes means providing everyone a little help rather than providing a smaller number of people a larger amount of help.
  • For this reason: we recommend planning your questions in advance so you can make the most of a limited amount of time with the teaching staff.
  • Be aware that “busy office hours” is not an accepted reason for late or incomplete assignments.
• You are welcome to go to any of the TA office hours. That is, you are not restricted to the office hours of the TAs in your lab section.
• You do not need a specific question to come to office hours - we are people too and don’t mind if you just drop by to say “Hi”, or want a more general review of a specific topics.
• Remember, our goal is to help you become a good programmer, so our focus will be on your learning not your grade. As such, come to labs with reasonable expectations and reasonable preparation
  • Be prepared to explain to the TA what topic you would like assistance with.
  • If you’re going to request code-specific-advice, have the code ready and be ready to explain in detail the code and the problem.
  • More specifically, if you’re requesting debugging advice, be prepared to explain to TAs what debugging steps you’ve already taken. Not only does this avoid duplicating steps, it helps us know if we can help recommend debugging steps you could have tried. This is a key part of improving your debugging
  • Make sure you’re asking something we can actually help with – we can’t do the homework for you, but we can offer helpful advice or useful practices you can do to better resolve the issue at hand. Sometimes this can 100% be a question of how you word your question (for example “How do I pass this test” is a question I can’t answer, “can you help me understand why my code fails this test” is something we can help with)
• Be mindful of how much you use office hours. If you’re using a lot of office hours time on each assignment, you may be learning some bad habits and failing to address your actual conceptual issues. In case like this it’s better to schedule a 1-on-1 with the professor to address your higher-level issues.

Online Office hour rules

Online office hours are organized on slack, and hosted on zoom. You will be unable to participate in online office hours without access to both tools. To attend:

1. Open slack and log into zoom
2. Open the “online-office-hours” channel. There should be a queue widget.
3. Join the queue.
4. Stay at your computer while you wait – sometimes the queue jumps pretty quick and you don’t want to miss your turn.
5. When you’re at the top of the queue (#1) you are up next, it’s not your turn yet, but it will be soon, message the TA if you need to step away for a minute in case it’s your turn before you’re back.
6. When a TA can help you they will remove you from the queue and then message you directly.
7. Meetings will often have a time-limit around 10 minutes unless there is no one waiting. This is to ensure everyone gets a turn.
8. You don’t have to use video on zoom if you don’t want to. You can also opt to have a text-conversation in slack only, or to voice chat without opening a camera.
9. Do not pre-queue (join the queue before the TA is ready) or “hope” queue (join the queue when you want help without checking if anyone is available) Both can prevent others from fairly accessing the queue, and both can result in you not getting a meeting at all.

In Person office hours

• Remember that in-person office hours are hosted in a specific place (not online) therefore you need to look up where the office hour actually is. Since the TA will be helping people they may not see a question posted to slack about this.
• Remember to check in-person office hours in the calendar beforehand – If a TA falls ill they may take the office hour online with relatively short notice to protect the health of others.
• Remember that in-person office hours are typically not private.

by-request meeting rules

Anyone can email course staff and request a 1-on-1 meeting. Typically this will be with the professor directly, but some TAs make themselves available for this as well. These meetings run typically about 15 minutes, but that’s negotiable, and can be online or in-person. Make sure to contact us in advance of when you want to meet, and try to offer multiple meeting times so we can best find a time that works for both of our schedules. Ideally, you should aim 4-8 days out when scheduling these.

Communication Rules

There are a few ways to communicate in this class.

1. Your first place to think about posting a question should be Slack. Slack has channels for specific questions. Be aware, anything you post in slack should be seen as “publicly posted” Therefore the general rule is “no assignment code” in slack. Treat slack Q&A exactly like you might treat a question asked in lecture.
2. If you need to ask a question pertaining to specific code for specific assignments – please use email.
3. Please email the all course staff mailing list csci1913f25-staff@umn.edu instead of the professor directly whenever reasonable/possible.

Regrade Policy

Most assignments will be graded through gradescope. if you have a regrade request please use the gradescope built-in regrade request tool. Remember that we do not regularly overturn the autograder unless the autograder itself actually failed. Simply not producing the same output (even if the difference is a minor one such as a difference of a space or newlines) is not enough to warrant a regrade. Any regrade requests must be made within one week of when the graded work is returned. If you don’t want a regrade but you do want an explanation, you should generally use email instead – the gradescope regrade tool does not allow back-and-forth conversations.

Exceptions

This is a large class, and in order to be fair, we will apply these rules in a consistent manner to all students in the class. Our goal with these rules is to make them structurally fair and flexible enough to cover a wide range of circumstances. If you have a situation that is not covered by these rules, or that might merit an exception, please contact the course professor or head TA. However, exceptions will not be routinely given, but rather will be given only in truly exceptional circumstances. When exceptions are given they will generally be designed in such a way that we have a procedure to follow in the future which might be fair to al