Doing Class Projects In Redux

All class projects that require working with the online, interactive, knowledge base of canonical CS problems, Redux, have as a subset the following similar objectives and requirements.

Objectives

1. Gain experience with formal definition, implementation, and algorithmic solution of computer science problems
2. Gain experience contributing to an existing, real-world code base using git
3. (For group projects) Gain experience working in a group

Teams (for group projects)

This will be a group project on which you will all work in teams of 2-3 students. You will hand in assignments as a group. Teams will receive the same base grade. Team members are always welcome (but are not required) to e-mail me with concerns about disproportionate contributions from team members (including themselves) on any assignment and especially on midterm or final projects and presentations. When doing so, please always include a score from 1 to 10 indicating your evaluation of each team member's work (10 meaning they were a valuable member of the team that made significant contributions to the project and were good to work with, 1 meaning they contributed nothing and were difficult to work with). Then, include any clarifying comments, etc. (especially for low scores). If a person receives consistently low evaluations from peers, then their grades on affected assignments will be proportionally decreased.

Framework

Information is available on the Redux site for how to get started and how to contribute to the project. In short, you will fork any repos that you plan on contributing to (likely only the backend repo) and clone any repos you don't need to change (likely only the frontend repo). Then you can run a local version of Redux that will reflect your changes and allow you to develop and debug. When your contributions are ready, you will submit them as a pull request to the appropriate repository.

Redux Consent Form

1. Complete the Redux Consent Form indicating your decision as to whether you give your permission for contributions on this project to be incorporated into the live Redux website. (If you do not want your contributions incorporated, please follow the special instructions below to submit your work.)

How to submit your work without including it in Redux

While contributing your work to Redux has some potential benefits to you (e.g., showing prospective employers examples of your work on a real-world, full-stack development project), there may be some who do not want their work to be made public. As a general rule, FERPA prohibits requiring students to post work in a public space without providing a private alternative or a signed waiver. I want to respect this right, and you will not be penalized if you do not want to contribute your work to Redux. If you do not want your work included in Redux, you need to take the following steps:

1. After forking the Redux repository, detach your forked repo from the parent repo
2. Make your repo private
3. Add the TA as a contributor on your repository
4. Before making any changes, create a new branch on your repository
5. After you have made your changes, submit a pull request to your private branch which the TA will then review

Implementing Verifiers

As a general rule, if you are the first to implement a problem and its solver in Redux, you should also ensure that a verifier is also implemented for the problem. A verifier takes in a proposed solution and verifies that it, in fact, solves the problem instance. For P-time problems, this can be implemented simply as a call to your solver and then a check to see if the proposed solution and the solver's solution are equivalent (be sure to account for problems having multiple correct solutions , e.g., Shortest Path). For NP-complete problems, a polynomial-time verifier may not use a solution algorithm because polynomial-time solutions do not exist (but typically have very simple implementations all the same).

Grading

Grades on Redux projects will be determined from submitted pull requests based on the following criteria:

1. Proper naming
2. Proper definition and descriptions in the respective information dialog boxes
3. Proper sourcing
4. Proper contributor attributor information provided in dialog boxes and on 'About Us' page
5. Accuracy of programmatic implementations is correct
6. Inclusion in comments accompanying pull requests that specify the names and specific contributions of each team member (so we can follow up with questions later if necessary)
7. Thorough unit tests are implemented