Team
Team members:
- Ethan Bateman
- Role: Rulemaster & Backend Developer
- Email: ethanB@unc.edu
Email us
Team behavior rules:
- Team members are expected to exhibit professional and friendly behavior. Hurtful, rude or passive aggressive attitudes will be reported to the professor.
-
If a team member is to miss a meeting they should notify the other members ahead of time. There is no enforced minimum time warning, but each member should respect the time of others, and make the group aware as soon as they are able to.
-
Each team member is expected to limit their number of absences to a minimum throughout the semester. More than 3 absences will require a legitimate excuse (family matter, illness, etc).
-
Team members need to be in consistent communication with each other via the project group chat as frequently as necessary. Responses shouldn’t take longer than 24 hours, especially with inquiries related to project decisions.
-
If a team team member becomes unresponsive for longer that 24 hours regarding a matter that would delay progress, or prevent another member from continuing work, they will forfeit their input on the matter to the remaining team members.
-
Team members are discouraged from struggling with features or topics that they feel uncomfortable or out of their depth with for extended amounts of time. There is nothing wrong with experimenting with new resources, but if a team member gets stuck on
a task they must notify the team, so that the team can work together to find a solution.
-
If the team fails to reach a consensus on a decision, a majority vote will decide the outcome. In cases where the team becomes divided, the opinion of the mentor will break the tie and decide the best progression forward.
Team code style:
Our team has decided to use the following style guide lines when coding:
Team git style:
We will use Git Flow.
We will mostly operate on a “develop” branch. When we want to add features, we will create a feature branch like ‘feature/feature name’. When it’s ready to be merged into the develop branch, we will perform a 'pull request'. In a pull request, all of
the changes that have been made are made visible on GitHub to the rest of the team. At this point, at least one other team member should review that pull request. During this process other team members can ask questions and make comments about
any of the changes that have been made. When at least one other person approves, they can mark the pull request as approved and the author of the changes can merge them into the develop branch. When we want to publish our changes, we can create
a release branch with all of the changes included up until a choosen point.
We will use Android Studio’s built in GitHub integration.
