Adding introduction to the Development Plan

Doc/DevelopmentPlan/DevelopmentPlan.tex

@@ -13,31 +13,25 @@
 \begin{document}
 
 \begin{table}[hp] \caption{Revision History} \label{TblRevisionHistory}
-\begin{tabularx}{\textwidth}{llX} \toprule \textbf{Date} & \textbf{Developer(s)}
-& \textbf{Change}\\ \midrule Sept. 26 & Pavle Arezina & Added Team Meeting,
+\begin{tabularx}{\textwidth}{llX} \toprule \textbf{Date} & \textbf{Developer(s)}& \textbf{Change}\\ \midrule Sept. 26 & Pavle Arezina & Added Team Meeting,
 Communication, Member Roles\\ Sept. 26 & Nicolai Kozel & Added project schedule
-section\\ \\ Sept. 26 & Riley McGee & Added Proof of Concept Demonstration Plan,
-Technology, \& Git Workflow sections \\ ... & ... & ...\\ \bottomrule
+section\\ \\ Sept. 26 & Riley McGee & Added Proof of Concept Demonstration Plan,Technology, \& Git Workflow sections \\ Sept.29 & Pavle Arezina & Updated Introduction and Formatting\\ \bottomrule
 \end{tabularx} \end{table}
 
 \newpage
 
 \maketitle
 
-Put your introductory blurb here.
+The Development Plan for Gifitti is created to to clearly state how the project will be created. With the team plan and communication plan we will be able 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 guidlines 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 Thode. While
-all three of the group members will contribute during the team meetings, Nick is
-acting as the Team Leader and Riley will scribe the meetings. The agenda will
+periods. Tuesday meetings will happen once a day on the first floor Thode. Whileall three of the group members will contribute during the team meetings, Nick isacting 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 post errors in the
-documentation or code, GitLab issue tracking will help communicate these errors.
-Combination of texting and calling will be used to contact a group member when
+simple questions about the project to other group members. To post errors in thedocumentation or code, GitLab issue tracking will help communicate these errors.Combination of texting and calling will be used to contact a group member when
 they cannot be reached through Facebook messaging. Utilizing Skype to conduct
 calls for team meetings when physically meeting is infeasible. To contact T.A.
 or Professor due to questions or issues with the project, e-mail will be
@@ -63,40 +57,33 @@ 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 (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
+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
 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 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 feature
-branch 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 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
 changes. \end{itemize}
 
-\subsection{Brief List of Commands for the Workflow} \subsubsection{Make a new
+\subsection{Brief List of Commands for the Workflow} \subsubsection*{Make a new
 feature} git checkout “’-”b $<$Category$>$/$<$Brief$>$ master
-\subsubsection{Backup Local Feature Branch} git push “’-”u origin
-$<$Category$>$/$<$Brief$>$ \subsubsection{Publish Feature into Master} git
+\subsubsection*{Backup Local Feature Branch} git push “’-”u origin
+$<$Category$>$/$<$Brief$>$ \subsubsection*{Publish Feature into Master} git
 checkout master git pull git pull $<$Category$>$/$<$Brief$>$ git push
 
-\subsubsection{Committing} All commits are done to the feature branch for code,
+\subsubsection*{Committing} All commits are done to the feature branch for code,
 and master for documentation
 
 \subsection{Tags} \begin{itemize} \item All deliverables should be tagged
 appropriately to mark that it is complete. \item All code releases should be
-tagged with a version, x.y.z where x is a major update, y is a minor update, and
-z is a bug fix. \end{itemize}
+tagged with a version, x.y.z where x is a major update, y is a minor update, andz is a bug fix. \end{itemize}
 
 \subsection {Milestones} \begin{itemize} \item Mark deliverables and their due
-dates. \item All milestones are found in the project schedule \item Deliverables
-are considered major updates to the project. \end{itemize}
+dates. \item All milestones are found in the project schedule \item Deliverablesare considered major updates to the project. \end{itemize}
 
 \section{Proof of Concept Demonstration Plan}
 
-\subsubsection*{Risk 1} Reading in GIFs. GIF files must be read into Gifitti and
-parsed.
+\subsubsection*{Risk 1} Reading in GIFs. GIF files must be read into Gifitti andparsed.
 
 \subsubsection*{Plan for demonstrate risk 1's feasibility} By the project demo
 an open source library that provides this functionality will be chosen and
@@ -139,8 +126,8 @@ documentation. \item Visual Studio for any post code software model generation
 \href{https://msdn.microsoft.com/en-us/library/hh156542(v=vs.110).aspx}{.NET
 Framework Development Guide}.
 
-\section{Project Schedule} The Gantt Chart outlining the project schedule can be 
-found \href{https://gitlab.cas.mcmaster.ca/kozeln/Gifitti/tree/master/ProjectSchedule}{here.}
+\section{Project Schedule} The Gantt Chart outlining the project schedule can befound
+\href{https://gitlab.cas.mcmaster.ca/kozeln/Gifitti/tree/master/ProjectSchedule}{here.}
 
 \section{Project Review}