Arezina & Updated Introduction and Formatting\\ Sept. 29 & Nicolai Kozel & Final
Proofreading\\ Sept. 30 & Riley McGee & Final aditions to Rev 0, formatting
corrected throughout \\\bottomrule\end{tabularx}\end{table}
\newpage
\maketitle
The Development Plan for Gifitti is to clearly state how the project will be created. The team meeting and communication plan will allow us to work cohesively as a group with clearly defined team member roles. To ensure that the team can work on the project without conflicts, the git workflow plan is defined and the risks pertaining to Gifitti are stated to develop plans to avoid them. The presentation of the code and documentation has been constrained to guidelines to ensure a uniform project is produced on the schedule defined by the group members.
The Development Plan for Gifitti is to clearly state how the project will be
created. The team meeting and communication plan will allow us to work
cohesively as a group with clearly defined team member roles. To ensure that the
team can work on the project without conflicts, the git workflow plan is defined
and the risks pertaining to Gifitti are stated to develop plans to avoid them.
The presentation of the code and documentation has been constrained to
guidelines to ensure a uniform project is produced on the schedule defined by
the group members.
\section{Team Meeting Plan} Team meetings will occur on Mondays and Tuesdays.
The meetings on Monday will happen twice a day when possible during the lab
periods. Tuesday meetings will happen once a day on the first floor of Thode Library. While all three of the group members will contribute during the team meetings, Nick will act as the Team Leader and Riley will scribe the meetings. The agenda will
follow the Harvard guidelines. (See
periods. Tuesday meetings will happen once a day on the first floor of Thode
Library. While all three of the group members will contribute during the team
meetings, Nick will act as the Team Leader and Riley will scribe the meetings.
The agenda will follow the Harvard guidelines. (See
Gifitti/ReferenceMaterial/HarvardGuidlines.pdf)
\section{Team Communication Plan} Facebook messaging will be utilized to ask
simple questions about the project to other group members. To track errors in the documentation or code, GitLab issue tracking will be used to help communicate these errors. A Combination of texting and calling will be used to contact a group member when
they cannot be reached through Facebook messaging. Skype is the primary method to conduct
calls for team meetings when physically meeting is infeasible. To contact a T.A.
or Professor due to questions or issues with the project, mcmaster e-mail will be
used.
\section{Team Member Roles} Nick will be in charge and will be the Team Leader. His job is to assign
tasks and provide a clear goal on what needs to be completed. He is
knowledgeable on Gantt charts, git, image manipulation and C\#. Riley will be
responsible for scribing the team meetings and is experienced with git and C\#.
Pavles responsibility will involve the documentation because he is an expert in
git and LaTex.
simple questions about the project to other group members. To track errors in
the documentation or code, GitLab issue tracking will be used to help
communicate these errors. A Combination of texting and calling will be used to
contact a group member when they cannot be reached through Facebook messaging.
Skype is the primary method to conduct calls for team meetings when physically
meeting is infeasible. To contact a T.A. or Professor due to questions or issues
with the project, mcmaster e-mail will be used.
\section{Team Member Roles} Nick will be in charge and will be the Team Leader.
His job is to assign tasks and provide a clear goal on what needs to be
completed. He is knowledgeable on Gantt charts, git, image manipulation and C\#.
Riley will be responsible for scribing the team meetings and is experienced with
git and C\#. Pavle's responsibility will involve the documentation because he is
an expert in git and LaTex.
\section{Git Workflow Plan} The development of Gifitti is to follow the Feature
Branch git workflow.
\subsection{When and how to Create a Feature Branch}\begin{itemize}\item The
repository will have no direct code changes made on a local version of master.
However all documentation changes and additions may directly be added to master
directly. All development of code is to occur on a feature branch from master,
each branch is unique to the feature it addresses. Once a feature is completed
and has been reviewed and tested it is to be merged into master. This merge
should link the resolution of the issue on GitLab that it solves. \item Feature
branch names should follow the following naming practices:
However all documentation changes and additions may directly be added to master.
All development of code is to occur on a feature branch from master, each branch
is unique to the feature it addresses. Once a feature is completed and has been
reviewed and tested it is to be merged into master. This merge should link the
resolution of the issue on GitLab that it solves. \item Feature branch names
should follow the following naming practices:
\begin{itemize}\item Be brief in name of the branch, descriptive in the merge
into master after complete \item Keywords such as fix (for fixing bugs), ui (forview additions), feature (for general additions) followed by a brief of what thebranch addresses. i.e. ui/file-menu, fix/console-fault, feature/save-as-sprite
into master after complete \item Keywords such as fix (for fixing bugs), ui (for
view additions), feature (for general additions) followed by a brief of what the
branch addresses. i.e. ui/file-menu, fix/console-fault, feature/save-as-sprite
etc. \item As seen in the examples above follow a $<$Category$>$/$<$Brief$>$
with words separated with “’-” \end{itemize}
\item Commit and push local feature branches as a backup \item Pull requests arenot needed for this project. We will all act as admins to the repository and
will review feature branches up to date with master as a team before the featurebranch creator merges it into master. This step is only needed for major
\item Commit and push local feature branches as a backup \item Pull requests are
not needed for this project. We will all act as admins to the repository and
will review feature branches up to date with master as a team before the
featurebranch creator merges it into master. This step is only needed for major
changes. \end{itemize}
\subsection{Brief List of Commands for the Workflow}\subsubsection*{Make a new
