Collaboration in 371

Collaboration Policies & Setup

We are actively encouraging collaboration in EE/CSE 371 (everything but the quizzes) – this can help you manage the workload better and make your experience in the class more enjoyable. The main benefit of working with partners is the ability to discuss your approach and share code without worrying about violating any academic conduct rules.

Keep in mind that the goal of collaboration is to help each other learn, not to finish the assignments in the least amount of effort!

Allowed Collaboration

You are given the option of completing almost every assignment (except the quizzes) with one or more collaborators:

For lecture activities, you are highly encouraged to discuss and work through the problems with your neighbor(s). TAs will be available to answer questions or may come talk to you during the work time. Worksheets will be available in lecture to facilitate working on the problems so you should bring a writing utensil (digital or pen/pencil).
For homework, you are able to work in groups of up to 4 students and each group should make a single submission to Gradescope.
For labs, you are able to work with at most one partner (i.e., group of 2). Each group should make a single submission to Gradescope and all group members are required to be present and participate during lab demos.

You are allowed to switch group members between assignments, however, please DO NOT GHOST your old group members; be civil and let them know that you will be looking for a new group as soon as possible.

Gradescope Submission and Late Days

Homework and lab reports are submitted via .

Only submit the requested files! In particular, project build files from Quartus clutter up the grading interface and can cause your submission upload to fail. In general, you will only be submitting PDF and SV files.
One group member will submit to Gradescope and then needs to add the other group members to the submission by clicking the "+ Add Group Member" link. Note that the groups apply per submission, so if you resubmit a newer version of the exercise later, you will again need to add your partner to the submission.
Each group member will be assessed a late day individually for each day that an assignment is submitted late. Late penalties are applied to individual students who exceed the allotted late day tokens (i.e., one group member can have a homework score penalized without it affecting the other group members' scores).

Gitlab Repo Sharing

You will be given a Gitlab repo for the quarter to better enable collaboration (it beats emailing project files back and forth!). If you are less familiar with git, don't hesitate to ask a staff member or view the following resources:

Add Your Partner to Your Repo

Be careful with the group size mismatch between homework and labs! Repo sharing should be prioritized for lab partners. If you'd like a different repo for a larger (3-4 student) homework group, don't hesitate to reach out to the course staff.

Log on to the and navigate to your repo for EE/CSE 371. On the left menu, click on "Manage" and then click on "Members".
Click on the blue "Invite members" button in the upper-right corner.
In the "Username or email address" box, type in your partner's netid and then select the "Maintainer" role.
Click the "Invite" button and you should be ready to go!

Remove a Partner from Your Repo (When Switching)

Log on to the and navigate to your repo for EE/CSE 371. On the left menu, click on "Manage" and then click on "Members".
Scroll down to find your former partner's name and then click the vertical dots (⋮) on the right in their row and select "Remove member."

Collaboration Tips & Tricks

However, working with a partner does NOT automatically guarantee a smoother and easier workflow! A common misconception is that working with N groupmates means that your workload get cut by a factor of N. This won't be the case, but that's okay! If each of your workloads ends up at less than what it would have been working individually, then that's a win! Our hope is that this will benefit students particularly in the reduction of debugging time and the writing and proofreading of lab reports.

Effective collaboration ALWAYS involves frequent communication!

A common pitfall is having one partner "drive" (e.g., type, compile, submit) all the time. As you will be answering exam questions about each of your assignments, it is VERY IMPORTANT that both partners be familiar with all of the work they are submitting and also have the opportunity to practice the related skills (e.g., text editors, debugging).

Common Approaches

: This is the recommended approach (backed by research!) and means that you'll have two sets of eyes on your code at all times as you work. This does mean that both partners need to be available at the same time, but this can be accomplished remotely via Zoom screen share and git commits for switching drivers.
Independent Work with Check-ins: The key to this strategy is frequent communication about progress and issues. The communication needs to be of sufficient frequency and quality to gain the benefits of getting two sets of eyes on both of your work and the ability to brainstorm and work through issues together. This communication could happen (in order of most to least recommended) via short meetings (in person or via Zoom), via detailed git commit messages/logs, or via email.
Complete Division of Labor: Unfortunately, this is the most commonly adopted approach by students and also the least effective by far. You are putting a lot of trust in your partner to complete their part on their own without any help, but, more importantly, you are also voluntarily giving up your chance to look over their code and to understand/learn from their part of the assignment! Each individual student is responsible for the expected learning gains from every assignment in the course and choosing to skip parts will only hurt you for the quizzes and later on when those skills might be needed.

Collaboration Tools

Version control: You need to make sure that you and your groupmates are working on the most up-to-date version of your files! The recommended tool for version control is git and you can find some resources for managing a repository in the git section above. Other ways to manage files include Google Drive, OneDrive, Dropbox, and Box. We don't recommend emailing files back-and-forth.
Zoom: UW has a site license for so it is free to use and a useful application for working together remotely. Along with the ability to share your screen (or a whiteboard), you can allow your groupmates to make on-screen annotations as well as remotely control your code editor window.
Whiteboard applications: There are a variety of whiteboard applications available that are useful for drawing and sharing things like block diagrams and state diagrams. These are also useful for saving or screenshoting your drawings for reference or for your lab reports! Some applications even support concurrent collaboration such as . Other staff recommendations include and .
: This extention allows multiple users to work on the same code base. One user shares their VS Code workspace and the other users can connect to the workspace via a provided link (more detailed instructions in the Live Share link). Live share works on top of the , which will need to be installed on the host machine.
- This also includes some communication tools but we don't recommend using them – use Discord or Zoom instead.
- Live-sharing requires a significant portion of your machine's resources and a strong internet connection, meaning it may run slowly or slow down other applications, depending on your machine specs and usage.

Best Practices

Establish Expectations Early

Clear and frequent communication is vital to the success of working with your group. Part of this means establishing expectations early, which might take the form of a short conversation/discussion. Potential topics to discuss include work approach, what your schedules and priorities are for the quarter, approaches that have worked for you in the past, comfort level with topics and tools, submission handling, and late day usage. Remember that you're not trying to impress your groupmates; being realistic will allow you to formulate a plan that will work for all of you. Expectations do not need to form an exhaustive contract, but having some communication before beginning can alleviate future frustrations and misunderstandings.

Read and Discuss the Specs

The assignment specifications for this course can be quite long with lots of information, as well as design decisions that have purposefully been omitted for you to make. It is recommended to read the specs on your own first, taking notes on key aspects or areas of confusion, and then discuss with your group. This is useful for checking each other's understanding prior to drawing any diagrams and writing any code and can save time in the long run.

Always Design Before You Implement

You always want to make sure that you agree upon a design before attempting to implement anything in code. This ensures that all groupmates are on the same page regardless of the work division and also speeds up debugging since you can contrast the expected behavior against the actual behavior. Finishing design diagrams (e.g., block diagrams, state diagrams for FSMs and ASMDs) first also gives you an opportunity to get feedback from the course staff early on and makes putting together your lab reports easier. Recommended tools for creating diagrams include: (circuits), (diagrams), and (diagrams).

Be Specific in Your Tasks

When establishing tasks for a work session or dividing work among groupmates, the more specific you can be the better. As opposed to saying your task is to "finish the assignment", try identifying specific diagrams/modules/features you will work on implementing. This will avoid confusion over task distribution (e.g., no one completing a task because everyone thought someone else was going to do it) and can increase efficiency as everyone will know exactly what they want/need to accomplish.

Check In and Take Breaks

Regardless of the approach you and your group follow, taking breaks from working can increase your productivity and reduce frustration. With pair programming in particular, checking in with your partner while you work and taking breaks as needed can greatly improve the experience.

Take Notes as You Work

If you are working without groupmates present, write down any question or uncertainty that crosses your mind while working on your code so that you don't forget to get it addressed when you next communicate with your group. This could be on a physical piece of paper, in a digital document, or directly in your code comments (but don't forget to clean up unwanted comments later!).

Share Successes and Failures

Make sure to share both successes and failures with your group so that you all can learn from your individual experiences and can try to avoid running into the same issues in the future.

So instead of just saying "oh, I fixed it," take the time to explain what the problem or misconception was and how you fixed it.
Similarly, if there was a part of your solution that you found clever or interesting, make sure to share your excitement and tips with your group.

Come to Office Hours Together

We understand that student schedules are extremely busy and that sometimes it is not feasible for all group members to attend the same office hours. However, we find that groups that attend office hours together are more efficiently helped and often come out with deeper understanding.