Full Stack Development Course User’s Manual v1

gistfile1.txt

# Full Stack Development Course User’s Manual

Welcome to the Full Stack Development Course! This course is designed to equip you with the knowledge and skills to build comprehensive full stack software projects. You'll learn how to make informed decisions, work effectively in teams, and explore new territories of knowledge. This manual lays out what to expect from the course and how the final score is determined. If anything is unclear, please ask!

# Course Principles

These principles guide class decisions and evaluations.

**Process: **Focus on _how_ decisions are made to improve the decisions themselves. 

**Intellectual Risk and Exploration: **Reward bold, thoughtful mistakes over timid, bland successes.

**Empathy:_ _**Employ empathy in decision-making for better outcomes in general, and better software specifically.

**Principle of Charity:**. Assume the most favorable interpretation wherever there is ambiguity.

**Reduce bias**: Bias leads to poor decisions. Through transparency and fearlessness, we will expose and reduce our unconscious biases in order to make better decisions.

We invite you to discuss the principles themselves, and openly raise questions when you see a disconnect between the guiding principles and the incentives encouraged by class policy or evaluation criteria.

Optional further reading:

Edmondson, A. (2018). [The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth.](https://www.wiley.com/en-us/The+Fearless+Organization:+Creating+Psychological+Safety+in+the+Workplace+for+Learning,+Innovation,+and+Growth-p-9781119477266) John Wiley & Sons.

Kim, G., Humble, J., Debois, P., & Willis, J. (2016). [The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations](https://itrevolution.com/product/the-devops-handbook-second-edition/). IT Revolution Press. \
 \
Abrashoff, D. M. (2012). [It's Your Ship: Management Techniques from the Best Damn Ship in the Navy.](https://archive.org/details/itsyourshipmanag00abra) Grand Central Publishing.


# Resources and Support

If you're struggling with any aspect of the course, there are several resources available to support you. This includes office hours with the instructor, online resources, and peer support groups. Don't hesitate to ask for help when you need it - we're all here to learn and grow together!


# Process

In this class, the term 'process' refers to the meta-decisions that guide how choices are made, particularly in the context of building the semester project. This includes the timing and necessity of meetings, conventions for pull requests and code reviews, policies for conducting root cause analyses (RCA) and postmortem reports, protocols for breaking down features into tasks and assigning those tasks, whether to use Agile methodologies, and other similar decisions.

A discussion about 'process' is a discussion about how the team's choice of technologies or approaches influences developer decision-making and productivity. Therefore, 'process' is not just about what we do, but also about how and why we do it, and how we adapt and improve over time.

Teams can largely develop their own processes but there are some mandatory constraints:



* The source code of the project must be hosted on GitHub
* The project repository must be available for review to the entire class at all times. 
* The project must have a production branch, usually referred to as `master` or `main`, that represents the current state of the project.
* Proposed changes to this branch must be described in pull requests (PR)
* The code in the PR must be reviewed and approved by at least one member of the team or coalition before it is merged or rebased onto the production branch
* There must be a README file in the root of the project that
    * Names the project
    * Describes the project
    * Describes how to install and run the project locally (if applicable)
    * Contains or links to a user manual
    * Contains or links to a developer manual
* Weekly team meetings are mandatory

Strongly recommended, but not required: 



* Automate testing on PR, 
* Implement continuous integration, 
* Two members of the team must review and approve PRs,
* Promote one team member to be the team lead who guides and arbitrates technical decisions
    * consider a rotation schedule in advance for sharing the lead role
* Learn and employ _Agile_ methodologies.


# Teams

Students can decide to work on their own or to build a team to collaborate on the semester project. Teams must register their membership roll and project by the end of the second week.

Teams of larger than 5 tend to be unwieldy, but any proposed team of 7 or more  members must discuss their reasoning with the instructors.

Solo projects are possible (“teams” of size 1) for those students who would like to build a project by themselves. _Teammate peer evaluations are not part of a solo project’s final grade_. The compensating disadvantage is that the semester project will be evaluated against projects that have more developers and resources. In any case, solo developers must form _coalitions_ with other solo- or low-sized teams for support and to attend weekly meetings, and each must submit weekly progress reports.

Some students may know _who_ they want to work with, but may not have a clear idea for a project. Conversely, some students might have a clear idea for a project, but not have a team. To bridge this gap, the first few classes will facilitate lighthearted, informal pitching sessions. Students looking for teammates can describe their proposed project and unaffiliated students can ask questions and discuss it with them.

Prospective team members should prepare to be honest about their strengths, weaknesses and commitment level. As well, teams can consider being flexible about roles. Enthusiastic coders can code, enthusiastic managers can manage, enthusiastic architects can architect. 

Note that the project does not necessarily have to be a _new_ project, as long as: a) it conforms to the constraints of the semester project, b) the team will be the only contributors, and c) the project is not already unduly mature. Teams who propose an ongoing project as their semester project should propose fair evaluation criteria, considering that other projects will start from scratch.

**Coalitions**

A _coalition_ refers to a group of solo and low-size teams who are not working on the same project but nevertheless share weekly meetings, code reviews and daily standups. They are not required to evaluate each other.


## Team meetings

The team must meet every week. The length and format of this meeting can be determined by the teams, but will generally be 1-1.5 hours and alternate in format between **project planning meetings** and **team retrospective meetings**. Attendance at each weekly meeting is mandatory and forms part of the final evaluation.

Note that meetings _must_ serve as the _primary vehicle_ by which team members share feedback with each other _particularly if that feedback is negative_. Despite being anonymous, the peer evaluation must hold no major surprises that were not communicated explicitly in meetings. If it does, the team's trust and psychological safety is compromised.

Solo developers also must participate in weekly meetings with other low-size or solo teams, or with an accommodating larger team. However, this coalition necessarily must modify the format of the meetings to suit their own circumstances. The key is to support each other and offer advice and help.

**Project planning meetings**

Otherwise known as sprint planning, iteration planning, cycle planning, milestone planning or kanban planning. This is where the team evaluates technical decisions, discusses how to proceed in future and how to evaluate success. Specific, actionable tasks are evaluated and assigned.

Getting these meetings right is vital, and adopting a specific framework for conducting them is extremely helpful to successful projects. If a team member is familiar with this topic, lean on them for help. If you’re looking for more guidance, please refer to the articles and books listed below. Consider asking ChatGPT or similar to help develop a framework for conducting project planning meetings. If you are struggling, raise the issue in class for brainstorming.

This course could easily be overwhelmed by exploring this topic. It is, alas, a Full Stack Development Course and not an Agile Methodologies course, and so we instructors must rely on each team to learn and develop a _process_ that works for them. That said, we are here for you, so please ask for help!

Optional further reading:



*  [The Agile Coach: Atlassian's no-nonsense guide to agile development](https://www.atlassian.com/agile)
* [What is a Daily Scrum?](https://www.scrum.org/resources/what-is-a-daily-scrum)
* Sutherland, J. (2014). [Scrum: The Art of Doing Twice the Work in Half the Time.](https://archive.org/details/scrumartofdoingt0000suth) Crown Business.
* Anderson, D. J. (2010). [Kanban: Successful Evolutionary Change for Your Technology Business.](https://archive.org/details/kanbansuccessful0000ande) Blue Hole Press.

**Team retrospective meetings**

After a milestone or sprint, the team should hold a _retrospective_ in which the team or coalition collectively discusses what went well and what could have gone better. Often the retrospective leader role is rotated among the members, and this leader is expected to set the agenda and maintain momentum. Usually the retrospective requires about 15 minutes of preparation by the lead. \
 \
Further instructions: [https://www.atlassian.com/team-playbook/plays/retrospective](https://www.atlassian.com/team-playbook/plays/retrospective)

A team retrospective serves several integrated purposes: 



* To foster empathy, trust and psychological safety
    * Build team morale
    * If the retrospective is virtual, cameras should ordinarily be _on_
* To discuss and evaluate the project’s progress
* Exchange technical information and ideas
* To evaluate and assign tasks over the coming week
* Anything else in support of the project’s completion
    * Creating and meeting milestones

Filling out the weekly progress report can be a focus of the retrospective.

**Team daily standup**

While not required for the course, teams should consider holding a regular meeting 3-5 days per week called a _daily standup_. The daily standup is lifted from the _Scrum_ methodology and has become standard industry practice even in organizations that do not otherwise use Scrum. The  daily standup is a short meeting, no more than 15 minutes. Each participant in turn tells the group what they worked on the previous day (if anything), what they plan to work on today (if anything), and whether there are any _blockers_ on the day’s work. A blocker is anything that prevents the developer from doing work. It could be technical (“The API endpoint is not ready”), or personal (“I am swamped with classes all day”). If possible, the participants might discuss together how to remove the blocker. Likewise _solo developers_ should consider forming a daily standup coalition with other developers. \
 \
More information: [https://www.atlassian.com/agile/scrum/standups](https://www.atlassian.com/agile/scrum/standups)

Consider also creating a Slack or Discord channel (or other chat app) for your team, and to keep it open by default, particularly when coding.

**Weekly project progress reports**

Each team must submit to the instructors a weekly progress report on their project, which takes the form of the questionnaire below. These are intended as the main vehicle for teams to assess and communicate the health of their project to themselves and to the instructors. All team members’ perspectives must be represented in each report.

At the end of the course these reports will be evaluated in aggregate as an overall reflection of honest appraisals of the status of the project. Assuming there is no huge divergence between the state of the project and the status reports, this should be an easy way to receive high marks. The focus here is transparency and self reflection: a team that submits bad reports when the project is floundering will receive high marks, while a team that hides mistakes in falsely positive reports will receive poor scores.

The weekly report consists of this questionnaire:


    Project name:


    Week # / date:


    Weekly meeting roll call (list who attended):


    Link each PR that was pushed to production this week:


    Briefly list and describe major technical decisions or pivots this week:


    Briefly list and describe any other major changes, if any (e.g. process, personnel, etc):


    Is there anything the instructors should be aware of?


    (To be filled in after team retrospectives):


    Briefly describe the team’s morale:


    What went well since the last retrospective?


    What could be improved?


    What is the plan for improvement?


    Were decisions from the last retrospective implemented? How did that work out?


# Semester Project

Building a semester project is the main focus of the course. Each student decides at the beginning of the course on a project they would like to build with a self-selected team (or solo).  \
 \
The semester project must:



* Have a singular, interesting, well-defined purpose, able to be stated in one or two sentences. In other words, it should do one thing and do that one thing well.
* The purpose must not be trivial or a “toy” in scope.
* Project features and technical decisions should contribute towards fulfilling the app’s singular purpose.
* The only major constraint on _technology_ is that it be _full stack_, consisting of a front-end client and a back-end remote server.
* The only major constraint on _scope_ is that its purpose must be interesting and well-defined.
* The project must be approved and registered, with the development team selected, by the end of the 2nd week at the latest.
* It should ultimately be accessible and usable to members of the public.

The semester project is a vehicle to learn and understand the _process_ of building full stack software, which is at least as important as the project itself. This is your opportunity to use and explore technologies that you are curious about.

(Optional) see the section “Project ideas and examples” below if you would like  ideas and examples.


## Semester Project Registration

Register a project by submitting this questionnaire to the instructor. All projects must be registered by the end of the second week, and all students must have one project.


    Project name:


    Summary (singular purpose):


    Detailed description (optional):


    Git Repo URL:


    Team members (if anyone has a distinct role or job, please note it):


    The following questions are optional at initial registration, but eventually should be discussed thoroughly among the team members with the decisions documented. A great topic for the first team meeting! Individual members could get a head start by having proposals ready.


    For each category, write several paragraphs, touching on any in the list of questions that are relevant. Be sure to ask and answer any question that is relevant but unasked. If the category does not apply to the project for some reason, please indicate that. \
 \
Front end:



* What will the front end do?
* What will users see?
* How does this support the app’s purpose?
* What technologies will be used to implement the front end?
* How do these choices support the purpose of the app?
* Are there other choices that could do the same?
* Why not use these other choices?
* Are there any wireframes or diagrams guiding these choices?
* Are there any design frameworks that could be used?

    Back end:

* What is the primary role of the back end in this project?
* How does the back end support the app’s purpose?
* What technologies will be used to implement the back end?
* How do these choices support the purpose of the app?
* Are there other choices that could do the same?
* Why not use these other choices?
* What platform will be used? Where will it be hosted?
* In what language will the back end be written?
* How will the back end handle security and data privacy?

    Database:

* What type of data will the app be storing?
* How does the choice of database support the app’s purpose?
* What database management system will be used?
* How do these choices support the purpose of the app?
* Are there other choices that could do the same?
* Why not use these other choices?
* How will the database handle security and data privacy?

    API schema:

* What type of data will the API be handling?
* How does the choice of API schema support the app’s purpose?
* What technologies will be used to implement the API schema?]
* How do these choices support the purpose of the app?
* Are there other choices that could do the same?
* Why not use these other choices?

    Third-party APIs:

* What third-party APIs will the app be using?
* How do these APIs support the app’s purpose?
* What technologies will be used to implement these APIs?
* How do these choices support the purpose of the app?
* Are there other choices that could do the same?
* Why not use these other choices?

    Architecture:

* What is the overall architecture of the app? How are the separate components organized to work together?
* How does this architecture support the app’s purpose?
* What technologies will be used to implement this architecture?
* How do these choices support the purpose of the app?
* Are there other choices that could do the same?
* Why not use these other choices?

    Definition of success (e.g. “The project will be successful when a user can…”)


    Describe in detail the anticipated team dynamic.

* Are there specialized roles? 
* Who will be the lead, if any? 
* When is the weekly meeting? 
* How will feedback be communicated? 
* Will there be a daily standup and when? 
* How much effort is each member expected to contribute each week? 
* Is it the same for each member? 

Describe in detail decisions about _process_ that will be employed, if known.



* What development methodology will be used (e.g., Agile, Scrum, Kanban)? How does this methodology support the app's purpose?
* How will tasks be assigned and tracked? What tools will be used for this purpose?
* How will the team handle code reviews and pull requests? What guidelines will be put in place to ensure quality and consistency?
* How will the team handle testing? What types of tests will be used (e.g., unit tests, integration tests, end-to-end tests)? How does this testing strategy support the app's purpose?
* How will the team handle deployment and continuous integration? What tools will be used for this purpose?
* How will the team handle communication and collaboration? What tools will be used for this purpose?
* How will the team handle documentation? What guidelines will be put in place to ensure quality and consistency?
* How will the team handle feedback and iterations? What processes will be put in place to ensure continuous improvement?
* Are there other process decisions that could be made? Why were these other options not chosen?


# Course evaluation

In keeping with the course principles, the course itself makes transparent the entire evaluation criteria. You are invited to review the course evaluation criteria and raise questions about how well and whether it incentivizes or suppresses the class guiding principles. Your discussion may prompt a class consensus to change the evaluation criteria.

Other than setting the evaluation criteria in advance, your instructors are almost entirely removed from determining your final grade. We thereby hope to encourage you to engage with your instructors as guides and mentors, rather than as arbiters of your success. In this way, we hope to create a space where you feel empowered to explore, take risks, and fully engage in the learning process.

Please do raise questions or concerns in class or with the instructors.


## Overview

Here is a general overview of how your final grade will be determined. A more detailed deep dive for each section follows below.


### 
    Semester Project (25%)


    Your team's project will be evaluated by a committee of your peers who are not involved with the project and ideally have never seen it before. The evaluation will be based on the project's functionality, documentation, design, and adherence to the project requirements. Note that the weighting is relatively low for a semester project. The intent here is to encourage risk-taking and exploration, and emphasize the process of building the project. Below is the exact questionnaire that the evaluators will use to guide their evaluation and is worth reviewing, but the breakdown of the semester project evaluation criteria is roughly: \




    * **Documentation (20% relative / 5% overall)**:  This includes the clarity and thoroughness of the project documentation, the project description, and the installation instructions. It also includes a subjective evaluation of the project's ambition and creativity as expressed in its description. \

    * **User Experience (20% / 5%)**: This includes the application's ability to fulfill its purpose, the pleasantness of the user experience, the project's robustness, and the user experience with respect to errors and error messages. \

    * **Architecture (20% / 5%)**: This includes the evaluation of choices of front end, back end, database, API architecture, and 3rd party integrations. It also includes the evaluation of the overall technical decision-making and the project's ability to support its purpose. Note that this weighting is set relatively low in order to encourage intellectual risk-taking and exploration. \

    * **Process (40% / 10%)**: This includes the evaluation of the project's pull requests, commit history, branching model, continuous integration procedures, and testing procedures. It also includes the evaluation of the overall effectiveness of the process of moving source code from the developer into production. \


### 
    **Peer Evaluations (20%)**: 


    You will be required to evaluate the performance of your project’s team members at three points during the course: after 4 weeks, after 8 weeks, and at the end of the course. This is not the primary vehicle to communicate feedback, but should be the culmination and summary of ongoing communication. This report is anonymous, but your peers should not be surprised or confused by their evaluation. Note that team peer review is not part of a solo project, and so for solo teams, the weighting of the other criteria increases proportionately.


### 
    **Self Evaluations (5%)**: 


    You will be required to evaluate your own performance after 4 weeks, after 8 weeks, and at the end of the course. This will be graded by the instructor. Self-reflection, honesty and a frank appraisal of one’s performance will receive high marks.


### 
    **Weekly Project Progress Reports (10%)**: 


    Each week, your team will submit a brief report on your project's progress, including technical decisions made and the reasoning behind those decisions. A transparent and accurate record is the goal with these.


### 
    **Presentation (10%)**: 


    Each student will be required to give a presentation on a topic of their choice related to full stack development. The presentation should be informative, engaging, and include a quiz to encourage audience participation. The actual format of the presentation is open, whether in-class, video, informative website, podcast. Peer and self-evaluation are the main vehicles of evaluating the presentation.


### 
    **Participation (30%)**: 


    This term as used here is specific and measurable, comprising the following. Do not be fooled by the low percentages here! Missing class or retrospective has negative knock-on effects reflected in the semester project and peer evaluations. This is the breakdown of the participation criteria: \


    * **Completing Peer- and Self-Evaluations (21%):** Providing thoughtful evaluations to your fellow students is a crucial part of both their learning journey and yours. However, we understand that writing can be challenging without clear direction. To make this process more manageable, we've streamlined it with a structured form in each case. This way, you can focus on providing valuable feedback without the stress of figuring out how to structure your thoughts. Remember, your input significantly contributes to the educational experience in this course, but it doesn't require an excessive amount of creative effort. \

    * **Class Attendance (3%):** Simply being present for each class session. Partial credit for previous or timely acknowledgment of a missed class. \

    * **Standup Participation (3%)**: Giving your in-class standup. Note that attending class is necessary for standup participation, so missing class will also mean missing the standup. \

    * **Team Meeting Attendance (3%)**: Simple attendance at mandatory team meetings. Note that while actual qualitative engagement in the retrospective is not evaluated here, honest, active participation is a component of your team peer evaluation. \

    * **Class discussion (0%)**: Please note that class discussion is not a requirement. We understand that everyone has different learning styles and comfort levels when it comes to group discussions. Some students may prefer to listen and absorb information, and that's perfectly fine. The most important thing is that you are engaged with the material and learning in a way that works best for you. Other elements of engagement, such as self evaluations, will provide ample opportunities for you to demonstrate your understanding and involvement in the course. That said, participation in class discussion is deeply appreciated and your thoughts may at times be solicited! Class discussions allow opportunities for clarification, exploration of ideas, and collaborative problem-solving.


## Semester Project Evaluation

Two weeks before the end of the semester, at least 3 students will be randomly assigned to evaluate each project. These students will comprise the project’s _evaluation committee_. Each member must complete the evaluation questionnaire alone. When all members complete their evaluation, their final scores are compared. If the scores are the same, this is the final score for the project. If the scores are very different, the committee must arrive at consensus. Generally, of two close scores, take the higher score.

When all members have completed their evaluations and consensus is reached, any evaluator who changed their score should note this on the questionnaire and briefly indicate why. Each member must then send their questionnaire to the instructor. The instructor will collate the evaluations and send a copy to the team members.

In order to reduce the possibility of bias, favoritism or influence, committee business and membership is to be treated as _confidential_ until the evaluation is complete. Do not ask, volunteer or discuss which projects anyone is evaluating. Please let the instructors know if anyone is violating this stricture.

Below is the  project evaluation questionnaire.


# Appendix


## Fibonacci Scale

You will use the Fibonacci scale in this class, both for estimating task complexity and for student evaluations.

The Fibonacci sequence is a numerical sequence in which each number is the sum of the two preceding ones, usually starting with 0 and 1. The sequence goes: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, and so on. It's named after Leonardo of Pisa, who was known as Fibonacci, an Italian mathematician who introduced it to the Western world in his 1202 book "Liber Abaci."

As a scale, the Fibonacci sequence is used in project management for estimating the effort, complexity, or size of tasks. The reason for using the Fibonacci sequence is that it reflects the inherent uncertainty in estimating larger items. As tasks get larger, our ability to estimate them accurately decreases, so the Fibonacci sequence accounts for this uncertainty by increasing the gaps between numbers as the numbers increase.

In a project planning session, team members assign Fibonacci numbers to tasks during the planning or estimation phase. Smaller, less complex tasks might be assigned a 1 or 2, while larger, more complex tasks might be assigned a 13 or 21. The goal is not to correlate these numbers directly to a measure of time (like hours or days), but rather to use them as relative measures of effort or complexity.

For example, if a task is assigned a 5, it's considered more complex or effort-intensive than a task assigned a 2. If another task is assigned an 8, it's considered more complex than the task assigned a 5. This way, the team can prioritize tasks and manage their workload more effectively. Usually tasks of complexity 21 are considered “too complex” and should be broken down into less complex components.

It's important to note that these numbers are not set in stone. As the team gains more information or if the scope of a task changes, they can re-estimate and change the Fibonacci number assigned to that task. This flexibility is one of the strengths of using the Fibonacci scale in project management.


### Fibonacci Scale in Evaluation Ratings

In peer- self- and semester project evaluations, please use the Fibonacci scale rather than the traditional 0-10 or 0-100. Specifically, whenever you are asked for a numerical rating, apply one of the following values: 

**0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, **or **144**

Apply **0** if the task is “not even started”

Apply **1** if the task is “minimally started”

Apply **34** if the task rating is “good”

Apply **55** if the task rating is “very good”

Apply **89** if the task rating is “truly excellent”. This is the highest score that anyone should ever ordinarily be able to acheive through extreme dedication and hard work.

**144** shall be reserved for extraordinary evaluations when “excellent” is simply not adequate to describe the triumph. Assigning this value is likely a mistake in inflation or bias. It should only ever be seen once per decade, and you will need an interview with the instructors and a committee of classmates to certify it.

By using a non-linear scale, we emphasize that the difference between good and great (or poor and mediocre) is not just a small incremental step, but a significant leap. This encourages evaluators to focus more on the qualitative differences in performance. The Fibonacci scale also acknowledges that evaluations are inherently subjective and that it's more important to distinguish between broad categories of performance (e.g., poor, satisfactory, good, excellent) than to try to pinpoint an exact numerical score.

Alas, at the end of the course, aggregated Fibonacci scores will be converted to traditional grading scores. Note that, generally speaking, a Fibonacci score of 89 is intended to convert ultimately to a grade of 10.


## Evaluation formulas

Presented for transparency, these are the formulas by which each student’s final score is determined. _You do not have to read this_, especially if you are overwhelmed. 

**Semester project** (sp): `sp = p / 89 `where p is the consensus score of the evaluation committee.

**Peer evaluations score** (`pe`): `pe = (e1 * 0.2 + e2 * 0.4 + e3 * 0.4) / 267 `where `e1`, `e2` and `e3` are the scores on the three peer evaluations respectively. e1, e2 and e3 are calculated as the mean of each member’s evaluation. The weight of the first evaluation is lower than the others in order to allow a team to become accustomed to working together.

**Self evaluations score **(`se`): `se = (s1 + s2 + s3) / 267` where `s1`, `s2` and `s3` are the scores on the three self evaluations respectively

**Weekly project progress reports score** (wr): `wr = (n/12) * 89 * p` where n is the number of completed reports and p is an instructor-determined “quality” factor. This will almost certainly be 1 except in egregious cases where there was a clear attempt to mislead.

**Presentation score** (pr): pr is the _mode_ of all of the submitted evaluations / 89. Mode is used here to smooth outlier scores.

**Participation score** (pa): 

Completing peer and self-evaluations:

ce = (c / e) where e is the total number of peer and self-evaluations expected and c is the number completed.

Class attendance:

ca = (n / c) + 0.5( a / c ) where c is the total number of class sessions, n is the number of class sessions attended and a is the number of missed classes that were acknowledged by the student. Acknowledged here means that the student gave previous notification or timely subsequent acknowledgment that the class was missed. The reason for missing the class is truly not necessary to state, and is not at all part of this score.

Standup participation

sa = (s / c) where c is the total number of class sessions and s is the number of standups participated in.

Team meeting  attendance

tm = (a / t) where t is the total number of team meetings held and a is the number attended

The overall participation score is:

pa = 0.7ce + 0.1ca + 0.1sa + 0.1tm 

Final score (fs):

fs = 0.25sp + 0.2pe + 0.05se + 0.1wr + 0.1pr + 0.3pa

A different formula applies to solo developers, given that peer evaluations (pe) do not factor into their evaluations. The other score weights are raised like so:

(solo) fs = 0.3sp + 0.05se + 0.15wr + 0.15pr + 0.35pa

fs will be a number from 0 to 1 which is multiplied to convert to the class grade


## Semester Project Evaluation Questionnaire

Please read the entire evaluation questionnaire once entirely _before beginning_, and review it once again for each project.

You are peer evaluating a semester project, just as your own is being evaluated. You are one of an evaluation committee for this project, and you are likely on several evaluation committees. Ideally, this is the first time you are seeing the project. When scoring, consider only the project itself and not your personal knowledge of or relationship with members of the development team. _Please treat this process with confidentiality until the evaluation is completed!_ \
 \
Note that this process requires a significant time commitment. You will be installing and using an unfamiliar application, reading its documentation and source code, grasping the architecture, reviewing pull requests and commit history, fairly scoring the project, describing your reasoning and giving qualitative feedback. You may at times need to meet with your fellow committee members. Please set aside _at least_ 3.5 hours to complete the evaluation. \
 \
This questionnaire will be used as the basis for calculating a final score for the project. Your work here will influence the final grade for one or more of your fellow students, so please be conscientious, diligent, accurate, unbiased and empathetic. Wherever there is ambiguity or lack of clarity, apply the Principle of Charity and use the best, most favorable interpretation available. If there is a toss-up between two similar scores, select the higher one. Note that the project’s developers will receive the feedback you write here, so be kind and constructive as well as complete and thorough. \
 \
This stage of the evaluation must be done without input from any other student, particularly neither the other committee members nor the project’s developers. This isolation is to reduce _conformity bias_ and _social influence_. If the final evaluation scores diverge widely from one another, the committee is expected to discuss their evaluations and arrive at a consensus score. \
 \
Please follow the instructions below and answer the given questions. The term “briefly” here means 1 or 2 sentences. You should already be familiar with the Fibonacci scale (0..21) as we have applied it in class, but remember that a Fibonacci score is one of 0, 1, 2, 3, 5, 8, 13 or 21. In numerical evaluations, 0 should be reserved only for “not even attempted/left blank” and 21 should be reserved for “flawless”. 

Your name:

What is the name of the project?

What is the repository URL?

Date the project started (date of first commit):

Describe any previous familiarity with the project:

Please locate the project’s README (or equivalent) and read it thoroughly.

**_Project Description_**

Briefly describe the project according to its documentation. What is it intended to do? \
 \
Does the project have a singular, well-defined purpose (Y/N)? If not, please clarify. \
 \
Compare the documented description to the team’s initial description. Have there been significant pivots or changes to the scope or description of the project over the semester?  If so, please describe them:

Rate the project’s **ambition** 0..21 and describe your score. This should be based solely on the project’s description in its documentation. Award high marks if the project has above-average scope and risk-taking. \
 \
Rate the project’s **creativity** 0..21 and briefly describe your score. Again, based solely on the project’s description, award high marks for an unusual project.

**_Project documentation_**

Rate the **clarity** of the documentation (0..21), and explain your score. How understandable is the documentation? Does it accurately describe the project? If helpful, quote an excerpt to illustrate your explanation.

Rate the **thoroughness** of the documentation (0..21), and explain your score. Is the documentation full and complete? If helpful, quote an excerpt to illustrate your explanation.

What did you like about the documentation?

**Installation**

Please follow the documented instructions for installing and running the project locally, even if the project is a website in production.

Does the installation succeed? (Yes/No) _If no, please contact the developers directly and give them one reasonable chance to give you technical support. If it still fails, please contact the instructors immediately._ \
 \
Does the project run? _This is a minimal smoke-test yes/no. If the project even simply prints Hello World, this is yes._ \
 \
Is there a testing suite, unit tests, or similar? (Yes/No) \
 \
If yes, please run it. Do all tests pass? (Yes/No)  If no, please describe. \
 \
**User experience (UX)** \
 \
This section evaluates the project’s UX, both as the developers intend it to be used, and otherwise.

Please read the user manual, walk-through or other similar documentation. After becoming familiar with it, interact with the project on that basis, then answer the following questions: \
 \
Describe application and its user interface (UI) in straight-forward, neutral terms. In other words, describe what you see and experience:

Does the app fully do what it purports to do? More? Less? Different?

What do you like about the user experience? \
 \
Does the project seem finished from the perspective of the user? (Yes/No) If not, what would it take to finish the project? \
 \
Rate how well the **application behavior corresponds to its description** (0..21). In other words, how well does it do what it is supposed to do?

Rate and describe the **user experience / UX **(0..21). How pleasant is the application to use?

_Stress test._ Use the project as it is _not_ intended. Try to break the application by entering input that is unexpected. If it is a web-based application, try SQL injection. If it displays user input, try an XSS attack. Enter unusual emails, very long messages, unusual characters, whatever else you can think of. \
 \
Does the application “break” with **fatal errors or bugs**? (Y/N) If yes or not applicable, please describe.

What did you like about the error handling? \
 \
Given the above, rate and describe the project’s **robustness**, ability to withstand and respond to the user behaving unexpectedly (0..21): \
 \
Rate and describe the user experience with respect to errors and **error messages** (0..21): \
 \
**Full stack architecture**

This section evaluates the project’s tech stack: each component considered separately, and then how well these components integrate with each other. Avoid personal preference against (or for) any particular technology or approach: you’re evaluating only how well the technical decisions of this project support the purpose of the application.

Please thoroughly review the source code along with any developer documentation to form a clear idea of how the project is structured (in a word, its “stack”). If any of the following does not apply (e.g. for a primarily No Code project), please indicate.

_Front end / client_: Describe in neutral terms the front end architecture and apparent technical decisions. List the frameworks, language(s) and major libraries used to build it (e.g React, Svelte, JQuery, TypeScript, Elm). \
 \
What is notable about the front end architecture? \
 \
_Back end / server-side_: Describe in neutral terms the back-end architecture, apparent technical decisions and list the platform(s), language(s) and approaches used to create the backend (e.g. AWS, Heroku, Netlify, Java).

What is notable about the back end? \
 \
_Database:_ If the project used a database, what is it? What are major tables or document schema? Was an ORM used to interact with the database? \
 \
_API_ architecture: Describe in neutral terms the schema that the project uses to communicate data between the front end and the back end? (e.g. REST, RESTlike, GraphQL, gRPC, SOAP; XML, JSON; custom) \
 \
What is notable about the API architecture? \
 \
3rd party integrations: What 3rd-party APIs if any are used with the project? (e.g. Contentful, OpenAI, Google API) \
 \
Describe generally your previous familiarity with these specific technologies. If you have strong opinions about them, good or bad, describe them and why. This section is for qualitative feedback but should not influence the final score.

Describe in neutral terms how these components of the stack integrate and interoperate. \
 \
In your opinion, has the architecture and other technical choices supported the project’s purpose? Why or why not? In what way?

Discuss security and privacy implications of the project, if any. Does the project handle sensitive data, for instance?

If there is an _egregious _security issue, please describe it in detail. Does it store passwords in plaintext, ask for credit card information, collect and track user information without explicit consent, or anything similar?

Are there any obvious examples of “over engineering”? That is, unnecessary complexity when simpler solutions would have sufficed?  Please describe each instance in as much detail as reasonable.

Does the developer documentation accurately describe the application architecture? Why or why not? \
 \
What are notable good decisions? \
 \
Citing your evaluation above, rate the overall technical decision-making and describe your reasoning  (0..21):

**Process**

This section evaluates the project’s _process_ of moving written code from a developer’s keyboard into production. Note that even solo projects should generally have clear PRs, commit history, CI/CD procedures, and testing. However, some unusual projects may not have the need for one or more of these elements. In that case, describe how the project avoided its necessity and leave the rating blank.

_Pull requests_

Please review the project’s pull requests (PRs) and their related discussions, with an eye towards understanding the overall history and progress of the project. Give higher weight to recent PRs, and_ disregard any PRs from before 1.9_ (if any).

Describe your overall impression, citing specific PRs to illustrate what leads you to that impression. Are the PR descriptions generally cohesive, with a clear and well-defined scope? Are discussions constructive and focused? Anything else notable about the pull requests?

Rate the project’s PRs, given your review, above (0..21)

_Commit history_

Please review the project’s git commits and commit history (`git log --name-only` might help). _Entirely disregard commits from before 1.9.2023._  \
 \
Give feedback and impressions based on your review. Are commit messages clear and concise? Do they accurately describe the changes in the source code? Illustrate your impressions with citations from specific, typical commit messages.

Rate the commit history, given your review above (0..21):

_Branching model_

Review and describe in neutral terms the project’s apparent git branching model (`git log --graph --oneline` might help, here), with an eye toward the following considerations: Is the branching model explicitly documented? Is incomplete or broken code allowed on the master/main branch? Are features built in a separate branch? Is a branch merged or rebased? 

Give feedback on  the effectiveness of the branching model, given your understanding, above.. Did it support or hinder the project’s goals? Was it consistently applied? Was there anything notable about the branching model?

Rate the branching model, given your review above (0..21):

_Continuous integration_

Describe the project’s continuous integration (CI/CD) procedures. Does pushing to master/main also push to production, or is there some human intervention. Were there instances of broken production? If so, how did the developers recover?

Give feedback on whether and how the CI/CD procedures supported or hindered the goals of the project, citing specifics.

Based on your review, rate the CI/CD procedures: (0..21)

_Testing_

Describe in neutral terms the project's testing procedures. Include the types of tests (unit tests, integration tests, end-to-end tests, etc.), testing frameworks used, any automation, and when tests are run (e.g. on commit, on merge?). \
 \
Critique and evaluate the testing procedures. Are tests run automatically as part of the continuous integration process? Are there any tests that consistently fail or are there areas of the code that are not covered by tests? How thorough is the test coverage? Was testing _over engineered_ at all? If possible, provide specific examples of tests to illustrate your points.

_Overall process_

Rate the effectiveness of the process (of moving source code from the developer into production)

**Progress**

Given your review of the pull requests and commit history in the last section, do you have any observations or feedback on the apparent progress of the project?  Was it steady or erratic? Was it rushed (or “crunched”) toward the end? If so, what might this indicate about the process the team followed to build the project? \
 \
Please do not include observations about _progress_ as part of the rating. This section is simply for feedback.

**Source code**

Please view the project’s source code. The quality of code is _not to be rated_ as part of the overall project evaluation. However, if there is anything notable that could have helped the project move forward, or if you have any other observations, please note them here.

**Overall Evaluation**

In summation, what are the project’s strengths?

What are the project’s weaknesses?

What are some suggestions for the project’s improvement?

Was the project bold? Did it take risks?  If it failed in some way, was it a magnificent failure? Please _do_ award higher marks for bold, risky magnificence.

Calculate a final score (0...21) on the basis of your previous scores and evaluations. Suggested weighting is **documentation**, **uxd** and **architecture** each **20%** and **progress 40%**.

Describe the weighting used and the reasoning for your score.


## Semester project ideas and examples

Here is a collection of AI-generated ideas for a semester project. While you are welcome to implement one of these ideas, remember that creativity and ambition are part of the evaluation criteria and your evaluators are also aware of this list! Look inward. What project will sustain, nourish and excite you?

1. A weather application that provides real-time weather updates and forecasts based on the user's location.

2. A recipe finder that suggests recipes based on the ingredients the user has on hand.

3. A personal finance tracker that helps users monitor their income, expenses, and savings.

4. A book recommendation engine that suggests books based on the user's reading history and preferences.

5. A language learning app that uses spaced repetition to help users learn new vocabulary.

6. A fitness tracker that helps users log their workouts and track their progress over time.

7. A meditation app that provides guided meditations and tracks the user's meditation history.

8. A plant care app that reminds users when to water their plants based on the type of plant and local weather conditions.

9. A virtual study group platform where students can schedule study sessions and collaborate on assignments.

10. A travel planner that helps users plan their trips, including flights, accommodations, and activities.

11. A job search app that aggregates job postings from various platforms based on the user's preferences.

12. A music discovery app that recommends new music based on the user's listening history.

13. A productivity app that uses the Pomodoro Technique to help users manage their time effectively.

14. A meal planning app that helps users plan their meals for the week and generates a shopping list based on the planned meals.

15. A movie recommendation engine that suggests movies based on the user's viewing history and preferences.

16. A habit tracker that helps users build and maintain good habits.

17. A flashcard app for studying that uses spaced repetition to optimize learning.

18. A virtual closet app that helps users plan their outfits and keep track of what they wear.

19. A home inventory app that helps users keep track of their belongings for insurance purposes.

20. A pet care app that reminds users about their pet's feeding times, vet appointments, and medication schedules.

These are just ideas to get the creative juices flowing. The key is to choose a project that is interesting and challenging, but also feasible given the time constraints and skill level of the team.


## Sample Project Registration

_Project name_: Rise & Shine

_Summary_: An app designed to assist sleepy people in establishing and maintaining a consistent morning routine.

_Detailed description:_ Rise and Shine is a mobile application designed to assist individuals who struggle with waking up and starting their day. The app provides a customizable morning routine, with reminders and timers for each activity. It also includes a variety of soothing alarm tones and motivational messages to make waking up a more pleasant experience.

_Git Repo_: https://github.com/riseandshine/riseandshine

_Team members_: 



* Alice Alligator (Frontend Developer)
    * Email: alice.alligator@email.com, 
    * GitHub: @alicealligator,
* Bob Bear (Backend Developer), 
    * Email: bob.bear@email.com, 
    * GitHub: @bobbear
* Charlie Cheetah (Database Manager)
    * Email: charlie.cheetah@email.com, 
    * GitHub: @charliecheetah,
* Dave Dolphin (Project Manager
    * Email: [dave.dolphin@email.com](mailto:dave.dolphin@email.com)
    * GitHub: @davedolphin

Front end:

The front end of Rise & Shine will be the primary interface for users. It will display a user-friendly dashboard where users can customize their morning routine, set alarms, and view their progress over time. The front end will be developed using React Native, a popular framework for building cross-platform mobile applications. This choice supports the app's purpose by providing a consistent and intuitive user experience across both iOS and Android platforms. React Native was chosen over other options like Flutter or Xamarin due to the team's familiarity with JavaScript and the strong community support for React Native. \
 \
Upon opening the Rise and Shine app, users are greeted with a clean, minimalist home screen that displays the current date and time, as well as a motivational quote to start the day. There's also a weather widget in the top corner, showing the current temperature and weather conditions, and a news widget scrolling the day's top headlines.

The main feature of the home screen is a visual representation of the user's morning routine. This is displayed as a timeline or a series of cards, each representing a task in the routine. Each card displays the name of the task, the estimated duration, and a checkbox for marking the task as completed. Tasks that are due soon or currently due are highlighted.

At the bottom of the screen, there's a navigation bar with icons for the home screen, routine editor, alarm settings, and user profile. The routine editor allows users to add, remove, or reorder tasks in their morning routine. They can also set specific reminders or alarms for each task. The alarm settings screen allows users to customize their wake-up alarm, choosing from a variety of soothing sounds and setting a gradual increase in volume to gently wake up. The user profile screen shows the user's account information and provides options to log out or delete the account.

Throughout the app, the interface is designed to be intuitive and user-friendly. There's a consistent color scheme and typography that's easy on the eyes, especially in the morning. The buttons and interactive elements are large and easy to tap, and there's plenty of white space to prevent the interface from feeling cluttered. The overall design is calming and peaceful, encouraging users to start their day on a positive note.

The front-end interface will help sleepy people establish and maintain a morning routine, in several ways:



1. **Visual Representation of Routine**: By displaying the user's morning routine as a timeline or series of cards, the app provides a clear, visual representation of the tasks that need to be completed each morning. This helps users understand their routine at a glance and track their progress through it, making it easier to stick to the routine.
2. **Task Reminders and Alarms**: The ability to set specific reminders or alarms for each task ensures that users are prompted to complete each part of their routine at the right time. This is particularly helpful for sleepy users who might otherwise forget or skip tasks.
3. **Customizable Wake-Up Alarm**: The customizable wake-up alarm allows users to start their day in a way that suits them best. By choosing a soothing sound and setting a gradual increase in volume, users can wake up gently and start their routine in a positive mood.

Our team will utilize Google's Material Design as our design framework for the front end. This decision supports the app's purpose by providing a visually appealing, intuitive, and consistent user interface. Material Design's principles of modern, clean design and responsive interactions will help our users navigate the app easily, making their morning routine setup and tracking a seamless experience.

Back end:

The back end of Rise & Shine will handle user data processing, alarm scheduling, and push notifications. It will be implemented using Node.js and Express.js, hosted on a cloud platform like AWS or Google Cloud. The choice of Node.js and Express.js supports the app's purpose by providing a lightweight, efficient, and scalable solution for handling user data and notifications. These technologies were chosen over others like Django or Ruby on Rails due to their performance advantages and the team's experience with JavaScript.

Database:

Database:

The Rise & Shine app will store user data, including their morning routine tasks, alarm settings, and progress history. This data will be stored in a MongoDB database, a NoSQL database that offers flexibility and scalability. MongoDB was chosen over SQL databases like MySQL or PostgreSQL due to its flexibility and the team's experience with NoSQL databases.

The choice of MongoDB supports the app's purpose by providing a flexible data model that can easily accommodate changes or additions to the user's morning routine. MongoDB's flexible data structure can easily accommodate these differences, making it an ideal choice for storing user data for the Rise & Shine app.

Our MongoDB database will be structured into three main collections: Users, Routines, and Tasks. The Users collection will store user account information, including login credentials and user settings. Each user document will include a reference to a document in the Routines collection, which will store the details of the user's morning routine. The Routines collection will contain documents for each user's routine, with each document containing a list of references to documents in the Tasks collection. The Tasks collection will store the details of each task in the user's routine, including the task name, estimated duration, and completion status.

This structure allows us to efficiently query and update the database. For example, when a user logs in, we can quickly retrieve their routine by looking up their user document and following the reference to their routine document. If a user adds, removes, or reorders tasks in their routine, we can easily update the corresponding documents in the Tasks collection.

In terms of scalability, MongoDB is designed to be scalable, both vertically and horizontally. This means that as the number of users of the Rise and Shine app grows, the database can be easily scaled to handle the increased data load. This ensures that the app can continue to provide a smooth user experience, even as it grows in popularity.

In terms of performance, MongoDB is known for its high performance. It uses indexing, which can significantly speed up data retrieval times. This means that when users interact with the Rise and Shine app, such as viewing their morning routine or checking off completed tasks, these actions can be processed quickly, providing a seamless user experience.

Finally, MongoDB supports real-time updates, which is crucial for an app like Rise and Shine where users might frequently update their routines or preferences. This ensures that users always have the most up-to-date information at their fingertips.

API schema:

The API schema for Rise & Shine will define how the front end communicates with the back end, specifying the structure of requests and responses. It will be implemented using GraphQL, a query language for APIs that offers improved performance and flexibility over traditional REST APIs.

GraphQL allows the front end to specify exactly what data it needs, reducing unnecessary data transfer and improving app performance. This is particularly beneficial for an app like Rise & Shine, where different parts of the app may require different subsets of the user's data. For example, the home screen might only need a summary of the user's morning routine, while the routine editor might need detailed information about each task.

The API schema will include queries for fetching user data, such as getting the user's morning routine or retrieving a specific task. It will also include mutations for modifying user data, such as adding a new task to the routine, updating an existing task, or marking a task as completed.

Each query and mutation will have a defined input and output structure. For example, the query for getting a user's routine might take the user's ID as input and return a list of tasks, with each task including fields like the task name, duration, and status. The mutation for adding a new task might take a task object as input, including fields like the task name and duration, and return the updated list of tasks.

The choice of GraphQL supports the app's purpose by providing a flexible and efficient API that can adapt to the app's needs. This ensures that the front end always has the data it needs to provide a smooth and responsive user experience, which is crucial for helping sleepy users establish and maintain their morning routine.

Architecture:

The overall architecture of Rise & Shine will be a standard client-server model, with the React Native front end acting as the client and the Node.js/Express.js back end acting as the server. This architecture supports the app's purpose by separating concerns between the user interface and data processing, allowing each to be developed and scaled independently.

Definition of success:

The project will be successful when a user can set up a personalized morning routine, receive reminders for their tasks, and track their progress over time.

Team dynamic:

The team will work collaboratively, with each member contributing to their area of expertise. Alice will lead the front end development, Bob will handle the back end, Charlie will manage the database, and Dave will act as the project manager, coordinating the team's efforts and ensuring that the project stays on track. The team will hold weekly meetings to discuss progress and plan for the upcoming week, and will communicate regularly through a platform like Slack or Microsoft Teams.

Process Decisions:

The team will employ an Agile development methodology, with work divided into two-week sprints. This approach allows for iterative development and continuous improvement, which aligns with the app's goal of helping users establish and maintain a consistent morning routine. At the end of each sprint, the team will hold a retrospective to review their progress, discuss any challenges or issues that arose, and plan for the next sprint. These retrospectives will be held every two weeks, immediately following the end of a sprint.

Tasks will be assigned and tracked using Trello, a project management tool that allows for clear visibility of the project's status at all times. Each team member will be responsible for updating their tasks' status on Trello, promoting accountability and ensuring everyone is aware of the project's progress.

Code reviews and pull requests will be handled through GitHub, with at least one team member required to review and approve each pull request. This process ensures that all code is reviewed for quality and consistency before it is merged into the main codebase. In the event of disagreements or conflicts during code reviews, the team will hold a meeting to discuss the issue and reach a consensus. If a consensus cannot be reached, the project manager will make the final decision.

The team will implement automated testing using Jest, a JavaScript testing framework that allows for thorough and efficient testing of the code. Automated testing supports the app's purpose by ensuring that all features work as expected and that any changes or additions to the code do not introduce bugs.

The team will use GitHub Actions for continuous integration/continuous deployment (CI/CD). This tool will automate the build and deployment process, ensuring that the app is always in a releasable state. This supports the app's purpose by allowing for frequent updates and improvements to be made available to users quickly and efficiently.

Documentation will be maintained in the GitHub repository. The team will follow a set of guidelines to ensure that all code is well-documented. These guidelines include providing a clear and concise description of the functionality of each piece of code, including comments in the code to explain complex or non-obvious sections, and updating the documentation whenever changes are made to the code. This ensures that the codebase is understandable and maintainable, supporting the long-term success of the app.

Regular communication will be facilitated through Slack. The team will hold a weekly meeting to discuss progress and plan for the upcoming week. In addition, a daily standup meeting will be held to quickly discuss what each team member is working on and any blockers they are facing. This frequent communication supports the app's purpose by ensuring that the team is always aligned and working effectively towards their common goal.