Team Meeting: Project Preparation

In your Interpreter teams, complete the following steps:

1. Introduce yourselves by sharing:
• your background and how you are doing in general this semester
• your motivation/interest in this course
• choose a time for the next team meeting
2. Discuss each person's team experiences and expectations:
   • share good and bad past team experiences and what you learned from them
   • share preferences and styles regarding expectations, communication, and debating/conflict
   • go over the Team Contract (which each person will submit individually)
3. Read the assignment overview and share:
   • your knowledge/interest in using Turtle Graphics (in any way) or the assignment's different applications
   • your knowledge/interest in interpreters or the workings of programming languages
   • areas of the project you interested/concerned about
4. High-level project design
• discuss the different applications and which two you would prefer to work on beyond the required application
• discuss what part of the project each person wants to start on this week(end)
• summarize your discussion in the Markdown file PLANNING.md
5. Project Planning
• clone the shared team repository to each person's computer and import the project into your preferred IDE
• agree on a programming language, graphics visualization library, and desktop or web app
• summarize your discussion in the Markdown file PLANNING.md

For shared editing, you can work within Google Docs or within your project repository's Wiki.

High Level Design

Each person should examine two of the applications and describe each in turn to their partner, then discuss collectively what might be common and what might vary across them:

• Logo: a programming language with commands for drawing
• L-Systems: a programming language for drawing growth processes, such as in plants, fractals, or tiles
• Darwin: a programming language for modeling different creature species
• Karel: a programming language for controlling robots

Without any coding or requiring any specific implementation, explore trade-offs between several designs to determine the best one to explore in detail.

Project Planning

Plan your project by breaking the work into small tasks that are:

• less than 4 hours in duration to complete
• assigned a weight (the task's Story Point estimate (complexity), not its time)
• assigned to a team member (based on the number of hours they can commit to the Phase)
  • note if the same or similar tasks need to be done by multiple people on the team, create one Issue per person for that task
• one of the following (or others if needed), each of which should have its own Definition of Done that the team agrees on:
  • coding. Described using either a Connextra (user story) or Gherkin (Cucumber test) template — note, testing should be included in your estimate for each task
  • bug. Found after basic feature implementation using this template provided in your repository — note, new tests should be written to verify the bug exists and is fixed
  • spike. Used to find out more about an upcoming feature that has a high degree of uncertainty — note, this should be time-boxed to avoid becoming a time sink
  • non-technical. Described using either a Connextra (user story) (with some examples given in this discussion) or some other way that clarifies its value to the project

Use Gitlab directly to manage your project's tasks by:

• creating each task as an Issue assigned to a specific team member
• creating a Milestone (Phase) to prioritize them
• adding the initial set of Issues to complete to the first Milestone
• monitoring your project's progress with its Burndown Chart

The result of this should be a Milestone in Gitlab, populated with Issues, that accurately reflect each team member's expected velocity this week.

Submitting your Work

As a team, push your team's PLANNING.md file to the doc folder of your provided, shared, interpreter_teamNN repository

Individually, submit the Team Contract Google form.