CSCI 265 Phase 1: team charter, project proposal

Phase 1 is focused on establishing and organizing your team and coming up with a project proposal and team charter, with presentations and documents due on Friday September 26th (presentations in-lab, documents due by midnight). In your team labs of Friday September 12th you'll also be expected to give a short informal team presentation introducing your team and project and outlining your team's plan of attack for having all the phase 1 deliverables ready on time.

The core deliverables for phase 1:

giving
writing and submitting a team charter (due by 11:59pm Friday September 26th)
writing and submitting a project proposal (also due by 11:59pm Friday September 26th)
giving a 15-minute team presentation on your proposal/charter in your team's lab section (September 26th at 10 or 11am, depending on your lab section)

*The individual contribution assessments are due by 5pm Monday September 29th.

Sample versions of most project documents can be found here, based on a fictional team and project (and following a slightly different SDLC).

Forming the teams

Teams were tentatively formed during the lab session of Friday September 5th, but can be altered up until your planning presentation on the 12th as long as it still leaves each team with at least 4 and at most 6 team members.

Coming up with a project idea

The project idea should be based on the interests of the team: find something that you'll all be interested in working on. This could be a game or a software tool or application, the only limitations are:

it has to be sufficiently challenging to represent a term's worth of work for your team,
it has to be feasible to complete in the term,
you have to be able to demonstrate your final product in our lab at the end of the semester,
it cannot violate any university rules/policies.

The first two points can be difficult to assess in the early days of a project, especially given that most of your team is likely to be relatively inexperienced so far. To help with this, it is recommended you come up with ideas on how the project can be scaled up/down if it turns out to be too simple or too complex (E.g. at the very least we hope to accomplish a,b,c, hopefully we can also accomplish d,e,f, and if things go well then we'll also include g,h,i.)

This could involve how simple or complex the features will be, or how simple or advanced the visuals will be (e.g. a text-based version vs a full graphical version), or how deep/detailed the plot/levels will be (for a game).

Depending on your team skills, background, and willingness to learn new tech, you may consider trying things like

C++ or python and command line interfaces
C++/gtk or python/turtle for windows/graphics
javascript/nodejs/html/css/webgl for a web-focused tool/game
incorporating database components (mysql, postgres, etc)
using engines or tools like Unreal, Unity, GameMaker, etc

Getting and submitting the first team deliverables

In phase 2 we'll be setting up team repositories to contain the joint project work, and discussing mechanisms for coordinating access to these repositories, but for phase 1 each person will be getting and submitting their own copies of two deliverables, the team charter and the project proposal.

To get their individual repos, each student must sign in to their linux account and fork/clone the csci265 project repo:

The git fetch/clone/submit cycle:

To obtain a repository initially (e.g. project here)
   ssh  csci  fork  csci265/project  csci265/$USER/project
   git  clone  csci:csci265/$USER/project

Change directory into the repo
   cd project

Edit the proposal.md and charter.md files as needed, e.g.
   vi proposal.md
   vi charter.md

Add the changes (apologies everyone, left this rather crucial part out earlier!)
   git add proposal.md
   git add charter.md

Create a commit for the submission with a suitably informative message, e.g.
   git commit -m "team charter/project proposal submission"

Push the repo
   git push

For phase1 each student on the team must submit identical copies of the team proposal and charter. This is how the instructor can be sure that everyone on the team has agreed to the charter and the proposed project.

(In subsequent phases the team will have set up a team github or gitlab repo, rather than individuals submitting their own copies.)

Detailed discussion of the expectations for the two files is provided further below.

About markdown (.md) files

This semester, all of the documentation files for the project (both individual and team documents) will be submitted as markdown (.md) files. This is the only acceptable file format for documentation in the projects - if anything else is submitted you'll be required to resubmit using this format.

It's important we have an agreed file format for sharing content across the team and across the course, and a text-based format like markdown is much more suitable for tracking with version control systems (like git) than other formats (word, pdfs etc).

A discussion of basic and extended .md syntax can be found at these URLs:
- markdownguide.org/basic-syntax
- markdownguide.org/extended-syntax

Merlin's guide on how to configure your browser to display .md files can be found at URL
- csci.viu.ca/~wesselsd/technotes.html#markdown

The team charter (charter.md)

More of the expected content in the team charter can be seen by examining the skeletal version provided in your project repos, but here is a summary of expected content:

A brief outline of the product your team will be creating (this needn't be detailed, it's primarily to provide some initial context for your team's purpose).
A discussion of the philosophies, priorities, and goals that are central to your team.
A discussion of how workloads, roles, and responsibilities will be divided amongst the team members, a preliminary assignment of roles/responsibilities, and discussion of how those will be evaluated and reassigned as needed later.
An outline of the team's plans for meetings and communication: weekly meeting time(s), how you plan to prepare for, run, and report on meetings.
Plans for how you'll ensure the team is coordinated to safely meet all project deadlines.
Plans for how your team will handle potential conflicts as the project progresses (e.g. personality clashes, disagreements in the design or implementation of the project, disagreements over task/workload assignments).
An agreement on how/where the team will permit the use of AI (Are all team members OK with using AI-generated content? are they OK with other team members plugging their code or content into an AI? It's important to ensure the whole team is on the same page from the start.)
From the perspective of trying to successfully complete this project, include discussion of what the team sees as their collective strengths and weaknesses based on the skills and interests the individual team members bring to the table.

A sample team charter is available here to give students an idea of the depth/nature of the project aspects to be covered, but teams are expected to think about and write their own charters from the perspective of their team and their project - do not simply cut and paste sections from the sample.

The project proposal (proposal.md)

As with the charter, a slightly more detailed outline of the expected content in the project proposal can be seen by examining the skeletal version provided in your project repos, but the shorthand expectations are that it include:

the team name and project name
the name and contact email for the primary contact for this document
an overview/introduction to the product you plan to create
a description of who the product is targeting and why they and your team should find this product of interest
a more extensive discussion of the planned features/components/behaviour of the product
preliminary sketches of the user interface for the product (key screens and menus)
plans for how the project can be scaled up (if it's looking too easy as the term goes along) or scaled down (if it's looking too challenging)
an assessment of the technical risks involved in trying to build the product (handling of personality/team risks will be covered in the team charter)

As with the team charter (and with the same caveats), a sample proposal is available here.

The in-lab team planning presentations at the start of phase 1

In the team's lab section on September 12th, each team is to introduce their team and project to the other teams in the lab. This does not have to be a terribly formal presentation, but needs to at least include

introducing each team member,
introducing the team and project name,
giving a short overview of the planned product (what it is, who the target audience is, and why the team chose this product), and
giving a short outline on how the team plans on having the charter and proposal completed by Sept. 26th.

The in-lab team presentations for phase 1

In the team's lab section on September 26th each team will have up to 10-15 minutes to present their project proposal and team organization to the instructor and the other teams.

This is expected to be a reasonably formal presentation: have prepared slides and a structured plan for the presentation, and be sure to try a dry-run ahead of time to be sure your presentation length is about right. (Also be sure to test out your presentation with the projector in the lab to make sure you've got compatible connectors, software, etc.)

The presentations aren't expected to capture all the details from your proposal and charter documents, but rather to give the audience the overall picture along with any highlights and particularly interesting aspects.

Sample presentations for the proposal and charter can be found here: proposal, and charter.

Assessment and marks

Be sure all team members have read the contributions assessment page, and complete and submit their assessments by 5pm Monday Sept 29th. (These are the phase1.md files in your individual contributions repos.)

A sample contributions assessment can be found here.