Plan final projects

[adamblanchard]

After we have a clear content outline for all the courses, we need to rework the final projects in each course to be more appropriate.

This is a bit of a chicken and egg task. Things I think we should align on first:

1. Overall strategy for final projects (purpose, difficulty, team vs individual, organisational details)
2. Where final projects should fit into the courses
3. High level ideas for the final projects (ie. examples of types of possible projects)

This could be as simple as a discussion and summary for now.

Waiting on this task until we have a clearer outline of the modules for js/node, since lots of the learnings in there will need to be built on top of.

We should prioritise finishing the final project for foundation first, since that course starts first (and we have a bit more time to finalise content for the other courses).

[adamblanchard]

Decisions here will have a knock on effect to other tasks:

• How we design the assignments throughout the courses, since ideally they "build up" to the final project
• How we approach deployment of assignments throughout the courses. Whatever we decide as our approach, it should be consistent throughout the whole course ie. with assignments and final projects. (discussion here)

I think we should just increase the scope of this task to include a plan for the "js projects" too, so we can discuss it all together. Following that we can have separate tasks to update relevant parts.

[adamblanchard]

Meeting planned for Thursday with mentors who've previously ran the final projects.

[adamblanchard]

Summary from meeting:

Attendees:
Adam, Saloumeh, Mechii
Natalia, Pankaj, Rohit

Current final projects process described here.

Organisational feedback

1. What is the role of mentors? It's been a mix of consulting, project managing, or filling in as a developer. Teams have lacked a lot of structure (e.g. deadlines, sprint organisation, clear tasks) which mentors often have filled in. In Aarhus, trainees take on "extra" team roles, to reduce reliance on mentors to e.g. test things. We should write clear roles and expectations for mentors.
2. The biggest challenges came from setting up the project and collaborating (both using git/github but also communication wise, splitting up tasks etc.). Not (as much) the technical implementation.
3. Helping trainees understand that in the process of making software, it's not just about writing code. There are all these other roles and skills that make it successful (note: see roles they used in aarhus to explain this).

Actions:

1. Clearly define role and expectations of mentor.
2. Define a clear "framework" for trainees collaborating on a project (e.g. a guide to using a board, tasks, "deadlines" etc.)
3. A major and top priority learning goal is "collaboration" (softer skills like: planning, creating prs, merging stuff, breaking problems down, communication), not only implementing the technical details

Foundation final project

1. Should still be a "group" project, but not as intense as specialisms. Maybe just in pairs.
2. Would be great to have exercises throughout the course build up in a modular way to be used as part of the final project (move this idea to the next iteration of improvements).

Actions:

1. Re-use js mini projects as a basis for approaching foundation final project. Simplify where needed and clear up expectations (i.e. it's not just a list of instructions to follow, but for trainees to come up with their own requirements too).
2. We could set some up as a skeleton with placeholders (e.g. missing functions, apis, frontend design) to fill out.

Specialism final projects

1. People need to be able to build stuff from scratch at this point (ie. avoid skeletons)

Frontend

1. Use real apis (create a big list of public APIs that can be used to design a project
2. Focus on design/frontend only
3. Regarding storage, could use client based solutions (e.g. localstorage) or an "easy" platform like firebase (to also get auth etc. for "free"). In that case, we'd need to introduce it throughout frontend course as well.

Backend

1. Take a design of an app/feature, and build a backend to service it. It should be evaluated against these designs in the end.
2. Could use e.g. swagger to document as a requirement
3. Some kind of tests (or a collection on postman?) to showcase the api without having to build a frontend?

Additional suggestions

1. Could already practice pair programming/pair collaboration before final projects so people are more practiced collaborating
2. If we use visual git app in foundation, it might be easier to resolve merge issues, rather than trainees getting super stuck in final project

Outstanding questions

1. Which process do we use in specialism final projects (e.g. mentor designed, trainee designed, or client based)? While it's fine to have different approaches, we should probably agree on the default.
2. Deployment and database approach/technologies used across each (should be consistent and hopefully be based/iterated on hyf-project-template)

Next steps

1. Propose a list of learning goals and requirements for each course (like this, but one for each).