- James Ian Solima
- Darran Holmes
- Tyler Huntley
- Dutch Foy
- Mandela Steele-Dadzie
What hours will you be available to communicate?
- M-F 9am-6pm PST (We'll keep in contact)
- Weekends, on discretion
What platform will you use to communicate (ie. Slack, phone …)?
- Slack
How often will you take breaks?
- breaks as needed, Hourly
What is your plan if you start to fall behind?
- We'll decide to take a little extra time and plan out what needs to be done. Before or after class with a fresh mind Potentially reevaluate goals and features, and complete what needs to be done for a working MVP.
How will you communicate after hours and on the weekend?
- Slack, Remo
What is your strategy for ensuring everyone’s voice is heard?
- We will do a daily meet to check on progress with each member, where we address issues, code challenges and set goals for the day.
How will you ensure that you are creating a safe environment where everyone feels comfortable speaking up?
- We will keep open communication and an inclusive and non hostile environment
Make a list of each parson’s strengths.
- James: Decent at algorithms and learning new concepts, usually flexible and available
- Tyler: Communication, Time management, Growth mindset
- Darran: Diligent, Patient
- Dutch: Communication visionary
- Mandela: API setup
How can you best utilize these strengths in the execution of your project?
- We will help each other through the process using our different strengths to cover another's possible weaknesses and learn from each other wherever possible.
In which professional competencies do you each want to develop greater strength?
- James: Understanding documentation and being better at coding in general
- Tyler: Craft and quality competencies
- Darran: Problem-solving
- Dutch: Inflexibility, impulsive
- Mandela: Communication
Knowing that every person in your team needs to understand the code, how do you plan to approach the day-to-day development?
- We will do our best to write idiomatic and meaningful code, so it is understandable by everyone on the group
What will be your group’s process to resolve conflict, when it arises?
- We will write out our conflicts and get a third party involved to give advice on how to move forward. We will also talk out our issue first before the become a problem.
What will your team do if one person is pulling all the weight while the other person is not contributing?
- Give that person driver responsibility or otherwise have them help the team. We can also have them in a navigator role to help another member who is not a strong learn.
What will your team do if one person is taking over the project and not letting the other member contribute?
- Have a meeting and separate the tasks so it doesn't belong to one person.
How will you approach each other and the challenge of building an application knowing that it is impossible for two people to be at the exact same place in understanding and skill level?
- Be patient and have a more confident person navigate while the person who may not be at the same skill drives.
How will you raise concerns to members who are not adequately contributing?
- We will raise these concerns in a meeting and task them appropriately.
How and when will you escalate the conflict if your resolution attempts are unsuccessful?
- Get a third party involved when it becomes detrimental to the progress of the project
- How you will identify tasks, assign tasks, know when they are complete, and manage work in general?
Through daily morning standups, we'll go over what needs to be accomplished and assign tasks based on what we feel comfortable doing and break for the day.
- What project management tool will be used?
Trello
- What components of your project will live on GitHub?
Our code
- How will you share the repository with your teammates?
All members of the group will be assigned collaborator roles on the github repo
- What is your Git flow?
We will have a developer branch -> Each person creates a new branch from developer branch -> works on a feature -> pushes to developer branch -> other teammate reviews and approves -> Merge into developer branch -> delete feature of the day branch -> merge into main branch
- Will you be using a PR review workflow? If so, consider:
Yes
- How many people must review a PR?
1 other teammate
- Who merges PRs?
Reviewer
- How often will you merge?
At least once a day, or when a feature is complete
- How will you communicate that it’s time to merge?
We will communicate through Slack and Remo