Untapped-Island

Authors

• Robert Shepley
• Junyoung Son
• Timothee Odushina
• Keelen Fisher
• Daniel Frey

Cooperation Plan

Every person on your team is an asset. This is your chance to discover the hidden strengths and areas for growth for each team member.

Describe at least

What are the key strengths of each person on the team?

• Robert Shepley: Finding answers to technical problems (Google-fu), documentation, breaking problems down into smaller features.

• Junyoung Son: Has great ideas, easy going and fast typer good understanding of how to navigate github.

• Timothee Odushina: Very flexible to changes, and good searching ressources to resolves issues.

• Keelen Fisher: API Implementation, Route creation and file structure

• Daniel Frey: Trouble-shooting and refactoring code, Architecture

How can you best utilize these strengths in the execution of your project?

• Robert Shepley: Help others find answers to their questions. Aid in designing the structure of the application as a whole and in crafting solutions to specific problems.

• Junyoung Son: Help the team get on track and stay organized by keeping documentation of things.

• Timothee Odushina: Help my team for debugging issues and stay organize.

• Keelen Fisher: Handle some of the feature tasks that require routing and structure of the application.

• Daniel Frey: Help track down the cause of problems. Help integrate different people's work when there are conflicts.

In which professional competencies do you each want to develop greater strength?

• Robert Shepley: I'd like to be better at organization and time-tracking, so I hope to be a bit more strict with myself on those aspects during this project build.

• Junyoung Son: Understanding the use of APIs better. I never got my weather app in 301 to work.

• Timothee Odushina: Self-confidence and public speaking.

• Keelen Fisher: Communication, Self-Awareness, Social-Awareness, and Decision-Making

• Daniel Frey: Communication and documentation

Knowing that every person in your team needs to understand all aspects of the project, how do you plan to approach the day-to-day work?

Arrange the feature tasks to each member based on the member's strength (ie. member of the group who's strength is to implement 0Auth effectively can recieve that task for the project).

Conflict Plan

Your team should agree on a process for handing disagreements, should they arise. It is better to have a plan in place ahead of time so you can all refer back to it when necessary.

How we resolve conflict

• Open Communication, and if we still have some conflicts we can then vote for arbitration with the team first then get another codefellows TA or Instructor to help mediate the issue.to help resolve the issue at hand.

• Each team member should be open to new ideas. If there are two opposing ideas, we should strive to work through those ideas together and come up with a unified solution.

• Since time is a limiting factor in this project, coming up with solutions quickly is paramount. We should remember that reaching MVP is our main focus, and keeping that in mind as we talk through our ideas will be important.

• If we notice that someone is "steamrolling" or taking on too much of the project, we will remind them that this is a team project, and attempt to break down their assumed tasks into smaller feature tasks.

How will you approach each other and the challenges of the project knowing that it is impossible for all members to be at the exact same place in understanding and skill level?

Mob programming will be utilized for skill-sharing opportunities, and we will attempt to cultivate an environment where asking questions is not only okay, but expected.

How will you raise concerns to members who are not adequately contributing?

Talk to them. Break down feature tasks into smaller ones to let others contribute to the project, especially if they understand some parts better then others.

How and when will you escalate the conflict if your resolution attempts are unsuccessful?

Talk to the instructor about it if we cannot resolve conflict on our own.

Communication Plan

Before beginning to tackle the project, determine how your group will communicate with each other. This is not an individual effort. Make sure everyone feels comfortable with the identified methods of speaking up.

Communication Hours

9:00AM-6:00PM

Communication Platforms

Slack, Github, Phone, Remo

How often will you take breaks?

Hourly - 10 minute breaks

What is your plan if you start to fall behind?

Mob Coding sessions could help. If we notice that our MVP is out of reach, we will reevaluate the MVP in an Agile manner.

How will you communicate after hours and on the weekend?

Slack / Phone will be our main source of communication after horus.

What is your strategy for ensuring everyon'ss voice is heard?

Morning stand-up meetings and evening close outs

How will you ensure that you are creating a safe environment where everyone feels comfortable speaking up?

Open communication, reassure this is a safe environment

Work Plan

Explain your work plan to track whether everyone is contributing equally to all parts of the project, and that each person is working o "mmeat" problems. This should prevent"llone wol" effort.

NOTE: While researching and experimentation is always encouraged, writing and/or committing code to the project on your own during non-working hours or over the weekend is never acceptable. This puts the entire project at risk. Be explicit in calling out your work hours and the distribution of tasks.

How you will identify tasks, assign tasks, know when they are complete, and manage work in general?

Goal setting in the morning - Establish/assign feature tasks every day for each person. Check off goals and accomplishments every evening and readjust goals for tomorrow if need be.

What project management tool will be used?

Github Projects

Presentation Deck

Git Process

Plan out what your tea'ss Git workflow looks like for coding tasks.

Repository Rules

• Commit and push changes to a feature branch. When the feature is complete or in a usable state, create a PR to the staging branch.
• Try to use the GitHub issues feature whenever possible. For example, if you have a stretch goal you'd like the team to consider, create an issue and tag it as enhancement. If you notice a bug, submit an issue and tag is as bug.
• Every repository should have branch protection on both staging and main. The staging branch should be open for pull requests from any contributing member, but require at least one other member's approval. The main branch should only allow changes from the designated Code Owner/workflow.
• Pulling code into the main / production branch
  • Option 1: Create a scheduled GitHub Action to merge the staging branch into main at a certain time daily.
  • Option 2: Designate a single person as the Code Owner with permissions to merge staging into main.
• Each team member has access to the repositories through the overall organization.
• In most cases, changes into staging should be showcased to the rest of the group. This ensures that code gets reviewed and that each member of the team understands what is happening in the codebase.

What components of your project will live on GitHub?

The project repo, Terminal Client Repo, and all the code that is not within the database.

What is your Git flow?

The repo will be live for all members to edit the code. In addition, members can pull the repo into their local machine and work on seperate branches. We will also acp when necessary, or when we have completed our designated feature tasks.