Project Requirements

Table of Contents

Details on the requirements, deliverables, and rubric for the course project (proposals and final submission).

1 Grading Weight

The project is composed of two proposals—one for Haskell, one for Prolog—and a final project. The final project extends one of the two proposals to completion. However, both proposals are required of everyone regardless of which they extend to their final project.

Grade weight for the project is broken down into:

Stage Weight
Proposal, Haskell 20%
Proposal, Prolog 20%
Final Submission 60%

For the overall weight of the project and other grading details for the course, see the Syllabus.

2 Project Requirements

A successful project must:

Note: Each proposal includes the working minimal proof-of-concept. The final project includes the working minimal viable version. It is acceptable for the projects proposed in the two proposals to be very similar, to be entirely different, or anything in between. (However, your project proposal must be your own, within the project academic conduct guidelines.)

Submission will be on PrairieLearn as the URL to a specific commit of your repository completed by the deadline. (You can open your most recent commit by clicking its name on the banner at the top of your file list in your repository’s home and then clicking the “browse files” button.)

3 Proposal

The proposals for both languages will follow the same basic structure.

3.1 Proposal Format and Submission

Your proposal is a copy of the CPSC 312 Project Template repo, which you must host on github.students.cs.ubc.ca. For now, it must be private (but after the final project deadline, you may and probably should make it public!), and you must make tsoares (Tarcisio), ejconlon (Eric), jellekr0 (Andy), and wolf (Steve) read-access collaborators. (Go to your repository’s Settings and then to the Collaborators & teams to set this up.)2

We’ve already laid out a structure in the README.md file of the repo you are copying to give us:

3.2 Proposal Rubric

We will mark your proposal according to the following rubric. Make it easy for us to assign you a good mark according to the rubric, by fulfilling these requirements and highlighting them in your README.md!

Note that we expect an entirely-satisfactory project to earn a high mark but not 100%. Earning the top mark in two rubric categories requires exceptional work.

[Satisfies basic formatting requirements]
5: All formatting requirements fully satisfied in the appropriate way and on time.
4: All formatting requirements fully satisfied by the late deadline (listed on PrairieLearn, three days after the deadline).
3: Enough basic requirements present by either deadline for us to effectively mark the project, possibly with a little annoying work on our end.
2: Insufficient basic requirements for us to effectively mark, even after the deadline. However, we can mark most things. Likely to cause 0s or low marks in other places.
0: Missing or extremely difficult to mark. Likely to cause 0s or low marks in other places.
[Plausible product pitch (“ready for awesome action”)]
5: Exciting and language-appropriate product idea tackling a problem that is clearly compelling to a significant audience. The minimal viable project clearly builds toward this meaningfully, without being nearly as much work. This goes above and beyond. (+1BP to each student)
4: Solid and language-appropriate product idea with a problem that is of real interest to the submitting team. The minimal viable project clearly builds toward this meaningfully, without being nearly as much work. We expect most good projects to earn this mark.
3: Either the product or the problem are clear and of interest to the team. The minimal viable project relates to one or both and can be adapted fairly easily to be doable and build toward the full project.
2: Clear attempt to convey a product or problem of interest.
0: Missing or cannot follow the description.
[Language elements]
5: The minimal viable project (MVP) builds on the strengths and power of the language in exciting ways that will clearly lead to excellent learning for students. This goes above and beyond. (+1BP)
4: The MVP clearly builds significantly on the language and will lead in interesting and natural ways to learning for the students. We expect most good projects to earn this mark.
3: The MVP will give the students significant implementation practice, although it may not be especially suitable for learning in the language.
2: The students have identified some ways that they will learn more in the language, though it’s not really clear how/why the MVP supports it.
0: Missing or cannot follow the description.
[Proof-of-concept]
5: Fully functional proof-of-concept is easy to use and review, and it clearly demonstrates a key element necessary for the overall project. This need not go above-and-beyond, but we will have high expectations for this mark. (I.e., we mean it when we say “fully functional”, easy-to-use/-review, and clear.)
4: The proof-of-concept works (or mostly works) and we can see how it illustrates a key element (involving the new learning).
3: We can see that significant learning and practical application went into producing the proof-of-concept, though it may not work or be well-documented/-illustrated.
2: The proof-of-concept clearly attempts to do something substantive with the language.
0: Missing or cannot understand how it meaningfully demonstrates learning/exploration.

Finally be aware that our grading feedback may require you to adapt your proposal when extending it to a final project (regardless of whether you have already made substantial progress beyond the basic proposal requirements). We may also demand reasonable changes shortly after you declare which proposal you will extend to the final project.

4 Final Project

You must first declare which proposal you want to extend well in advance of the project submission deadline! See PrairieLearn for the deadline.

4.1 Final Project Format and Submission

The final project submission on PrairieLearn is just a link to a specific commit in your github.students.cs.ubc.ca repo.

Your final project is a natural extension of one of your proposals. (So, e.g., it will be based on the CPSC 312 Project Template repo, hosted at github.students.cs.ubc.ca, and the staff will have access: tsoares (Tarcisio), ejconlon (Eric), jellekr0 (Andy), and wolf (Steve).)

Your key additions will be to include and document your MVP and to include (a link to) a demo video of maximum length 3 minutes 59 seconds that demonstrates the functionality of your MVP.

Update your README.md file so it includes:

Your video should include:

A caution on code links: Github code links can include various ways to identify which commit to link to. You’re submitting a particular commit. So, ideally, your links will be to that commit.. which can be pretty tricky to accomplish! Just be sure you don’t accidentally link us to stale code that doesn’t represent your submitted work. You may find Github’s file link documentation helpful.

4.2 Final Project Rubric

We will mark your project according to the following rubric. Make it easy for us to assign you a good mark according to the rubric, by fulfilling these requirements and highlighting them in your submission!

Note that we expect an entirely-satisfactory project to earn a high mark but not 100%. Earning the top mark in two rubric categories requires exceptional work.

The core contribution for the final project is the “minimum viable version of the project” or MVP, and the rubric reflects that with a focus on the MVP.

[Satisfies formatting requirements]
10: All basic requirements fully satisfied in the appropriate way and on time.
8: All basic requirements fully satisfied by the late deadline.
6: Enough basic requirements present by the late deadline for us to effectively mark the project, possibly with a little annoying work on our end.
4: Insufficient basic requirements for us to effectively mark, even after the deadline. However, we can mark most things.
0: Missing or extremely difficult to mark. (Likely to cause 0s or low marks in other places.)
[Fulfills the proposal]
25: The MVP takes a significant step beyond the (core) proposed MVP. The core functionality and that extra step are clearly called out and well documented. Moreover, the documentation includes how the MVP embodies at least one (and ideally multiple) of: the importance of the problem the project addresses, the team’s language learning, or the progress toward a fully polished product. Otherwise, it fulfills all requirements of the next rubric level. (This goes above and beyond.)
20: The documentation highlights how the MVP fulfills the (core) proposed MVP, including how and why the final project varies in limited and reasonable ways from the proposal (if it does vary). It also includes a clear explanation and links into a handful of key elements of the code that successfully illustrate the proposal requirements. (We expect a solid project to earn this mark.)
15: The documentation does not provide a clear explanation of how the MVP fulfills the core proposed MVP (e.g., not providing reasonable explanations of how and why the final project varies from the proposal). However, it does show meaningful progress towards it.
10: The documentation clearly shows that the MVP does not deliver what was proposed and substantial work is required.
0: Missing or completely unrelated to the proposal.
[Application of new learning]
10: The documentation highlights how the new learning is essential for the project, it points out parts of the code where the new learning was employed. Furthermore, it shows how the MVP goes beyond and explores the new learning in exciting ways. (This goes above and beyond.)
8: The documentation highlights how the new learning is essential for the project, it points out parts of the code where the new learning was employed and provides some explanation on how the project benefits from its strength. (We expect a solid project to earn this mark.)
6: The documentation points out parts of the code where the new learning was employed, however, it fails to demonstrate how the new learning is essential to the project.
4: The documentation does not provide enough elements to show the use of the new learning in the MVP.
0: Missing or cannot follow description.
[Quality of code]
5: The code itself (both in the highlighted areas and in areas the staff chooses to explore) is sufficiently clear to understand how the work addresses the project requirements and it makes good use of the concepts seen in class.
4: The code itself (both in the highlighted areas and in areas the staff chooses to explore) is somewhat clear but requires modest effort to see how it addresses the project requirements and makes use of concepts from class.
3: The code itself (both in the highlighted areas and in areas the staff chooses to explore) is unclear and hard to understand.
1: The code itself (both in the highlighted areas and in areas the staff chooses to explore) is sufficiently difficult to understand that it is not possible in limited grading time to explore how it addresses the project requirements and makes use of concepts from class.
0: Missing.

5 Caveats, Exceptions, and FAQ

We’ll try to address key questions/issues that come up with the project here.

5.1 What’s the difference between a Minimal Viable Project and a Proof-of-Concept?

You’re proposing a project to build some system that somehow solves a problem people have. (That problem may be “what would be something fun to do with my time for the next hour?” or it may be “how do I reduce the impact of climate change significantly?” or something radically different, but it’s some problem that matters to your users.)

Your overall awesome idea solves this problem beautifully with a fully functional and full-featured system that is easily usable and accessible to your broadest target audience.

Your minimal viable project still solves the problem in some sense and with a functional system. However, it may be a narrower version of the problem, “hard-coded” to the particular needs of specific users at specific times or in specific contexts, and with only the bare minimum of features. (It’s a full system, but that may still be much much smaller than the awesome complete system you envisioned.)

Your proof-of-concept “functions”. It does something. However, it almost certainly does not solve your problem. Instead, it just demonstrates that you can make some tiny but key pieces of the system you plan work.

As an example, imagine you were creating a PC game with cool 2-D graphics and keyboard control as your system.

Your awesome overall idea is probably about a great game with many many levels, a thriving and supported community of players, modding systems for them to design levels, extension mechanisms, and so on and so forth.

Your minimal viable project is still a game with 2-D graphics and keyboard control. Ideally, it should even be fun to play and illustrate the core mechanics and experience of your planned game. But, maybe it only has one small level or even part of one level. Maybe it lacks a bunch of features you plan to have in your game later. It almost certainly does not have all that cool support for the community. The assets (graphics, music, and so on) may be very rough or even missing in some cases (e.g., no music or sound effects, sorry!). It probably provides only a brief playing experience, whereas you might plan for hours of joy for your awesome idea.

Your proof-of-concept may be code that shows a blue square on the screen. If you hit a key on the keyboard, it turns red. Repeat and it turns blue again, and back and forth. That’s it. It’s not a game at all. It does function, but it doesn’t do much. It doesn’t solve the problem. It isn’t a small-but-complete version of your system. However, it does illustrate that you can do basic 2-D graphics and keyboard input in your project’s language, and that might be the key pieces you decided needed proving-out in your proof-of-concept.

Awesome idea: Grand, amazing, full-featured, and general, with a big audience.

Minimal viable product: Real solution to the problem, real system, but extremely bare-bones and specialized. Probably not usable yet for most of your audience, at least without your help.

Proof-of-concept: Not a solution to the problem at all; not a real system at all. Does function and demonstrate some tiny use of the key pieces of your planned project.

5.2 Do I have to work with the same team at each stage?

We would greatly prefer that you maintain your team through all stages. However, it is not a requirement.

5.3 Do I have to build on one of my proposals?

Your final project must be based on one of your team’s proposals (respecting any feedback the course staff gives you). While we expect you’ll need to make adjustments as you work through the project, you should document those and keep them within the general scope of the proposal.

(If your team composition changes, a proposals is considered “one of your team’s” if at least one team member submitted the proposal. We strongly prefer, however, that the proposal chosen was submitted by at least half of the students on the team.)

5.4 Do I really have to submit both proposals, I know that it’s {Haskell, Prolog} that I love?

Yes, you really do. The course is Functional and Logic Programming, not Function or Logic Programming.

We acknowledge and respect your love, however!

5.5 Can my final project build on both languages?

Um.. I guess so? That could be a way to go “above and beyond”? But be absolutely sure you fully satisfy the requirements in one language or the other and that it will be easy for us to mark.

5.6 How do I go “above and beyond”?

First, you don’t have to. You’ll achieve a very good grade by simply fulfilling the requirements as listed.

If you do go above and beyond, how you do so is up to you to decide and to document. Review the requirements and find specific ways your team can do exceptional work. Then very clearly and specifically call out those ways your project was exceptional. However, bear in mind that we won’t attend to any supposedly exceptional work as long as the relevant basic requirements are not fully satisfied.

  1. In rare cases, we may allow use of alternate languages besides Haskell or Prolog. In any such case, you must post privately on Piazza at least 1 week in advance of the proposal deadline with your proposed alternate language, a fairly complete draft proposal (though it may omit the implemented proof-of-concept), and justification both for why the proposed project/language fulfills the requirements and how we can straightforwardly assess your work. Your selected language must embody most of the same principles as the corresponding language it replaces. We as the course staff must be able, without any special study of your chosen language, to effectively assess your proposal and final project’s fulfillment of the requirements above, including easily running your code.↩︎

  2. Unfortunately, forking our repo won’t work because your repository cannot then be private. We do not anticipate substantive changes during the course of the project to our repo except ones that would be easy to copy (e.g., new information about the final project). So, please do simply make a copy rather than forking.↩︎