Merge pull request '(DOC) Updated onboarding documentation' (#1) from feature/onboarding into main

Reviewed-on: azpect/MarkdownToHtmlCompiler#1

README.md

@@ -1,31 +1,115 @@
 # MarkdownToHtmlCompiler
 
-This compiler will convert a Markdown file into an HTML output.
+### Project Overview 
+
+The goal is to create a program that reads a file containing text formatted in a simple version of 
+Markdown and converts it into a valid HTML file. The program will need to identify and translate 
+specific syntax (e.g., `# Heading` to `<h1>Heading</h1>`, `*text*` to `<em>text</em>`).
 
 
+### Implementation Requirements (Generated by Gemini)
 
-### Notes
+Class Hierarchy: Design a class hierarchy to represent the components of your Markdown document. An 
+abstract base class, Element, can define common behavior. Derived classes would then represent specific 
+types of elements, such as Heading, Paragraph, BoldText, and ListItem. This is a perfect example of 
+inheritance and polymorphism.
+
+Object Composition: A Document class can be composed of multiple Element objects, representing the 
+entire file. A Parser class would be composed of helper methods to break down the input string and 
+build the Document object. This shows how you can build a complex system from smaller, self-contained
+objects.
+
+File I/O and Exceptions: You will need to use ifstream to read the Markdown file and ofstream to write
+the generated HTML file. Your code should use exceptions to gracefully handle potential errors, such 
+as a file not being found.
+
+Operator Overloading: Overload the << stream insertion operator for your Element and Document classes.
+This would allow you to easily print the generated HTML to the console or write it to a file, making 
+your code cleaner and more readable.
+
+UML Diagram: The complexity of the class relationships makes a UML diagram an essential part of the 
+project. It will help you plan your design and will be a key component of your submission.
 
 Recursive Descent Parser: This is the primary algorithm you'll use. It's a top-down parsing technique
-where a set of recursive functions "descend" through the grammar of your simple Markdown language. 
+where a set of recursive functions "descend" through the grammar of your simple Markdown language. For
-For example, a parse_document() function would call parse_line(), which in turn might call parse_bold_text()
+example, a parse_document() function would call parse_line(), which in turn might call parse_bold_text()
 or parse_italic_text(). This method is intuitive and easy to implement for a simple grammar.
 
 Stack: A stack is essential for handling nested elements. For instance, if you allow bold text inside
 italic text (_This is *bold and italic* text_), you can push the _ token onto the stack and then push
 the * token. When you encounter the closing *, you check if the top of the stack matches. This ensures
-that all tags are correctly opened and closed. Your presentation can visually demonstrate this process 
+that all tags are correctly opened and closed. Your presentation can visually demonstrate this process
 with a stack diagram.
 
 Hash Map or Map: A hash map (std::unordered_map) or a map (std::map) can be used to efficiently store
-and retrieve the HTML equivalent for each Markdown tag. For example, you could map `#` to `<h1>` or "_"
+and retrieve the HTML equivalent for each Markdown tag. For example, you could map `#` to `<h1>`or `*`
 to `<em>`. This provides O(1) average-case lookup time.
 
-### Targets
 
-- [-] Convert a .md file to an .html output
+### Contribution Policy
 
-### Reaches
+###### Branching
-- [ ] Hot reload?
+When working on this project, please use a feature branch (i.e. `feature/parser`) with a descriptive name.
+`feature/a` is not a descriptive name. These branches should be branched off the most recent `main` branch,
+we will not make use of a `dev` or `staging` branch since the project is small in scale as well as time.
+**However, if the project becomes larger or out-of-control, a dev/staging branch will be implemented.**
 
+###### Commits
 
+When working, it is best practice to commit code as much as possible, without being over zealous. For 
+example, when a feature or bug is complete, its time to commit. But when you have to make a new function,
+that does not mean its time. Each team member should use their best judgment.
+
+Commit messages a little bit more important, when working in a team, it is important to provide strong,
+clear and concise commit messages. In this project, the team will use a simple formula:
+
+**(SUBJECT) Title: textual description** 
+
+i.e. (FIX) Rendering completed: explain what changed in short.
+
+###### Pushing
+
+When working in a feature branch, pushing and pulling has no restrictions. Feel free to do as much 
+(or as little) as possible. However, you **CANNOT** push directly to `main`, the VCS will not allow you
+to do so, but do not make that mistake. When you are ready to merge a feature, you will create a PR
+and once it has been reviewed and approved it will be automatically merged in.
+
+###### Pull Requests (PR)
+
+Once a feature is complete, you will create a pull request. Before a request can be merged into `main`,
+one approval is required (which cannot be the author). This practice is to promote team work and encourage
+code reviews. Each team member is expected to check in frequently and review as often as they are able to,
+however, there is no defined time requirement. Personal communication is totally acceptable as a means to 
+request approval, since I am unsure if this platform will notify members.
+
+###### Issues
+
+If a bug, issue, or otherwise concern is noticed the first thing the team member should do is create an 
+issue. An issue should be descriptive and contain everything another team member needs to understand the 
+issue and its context. This way, a new team member can tackle the issue without contextual gaps.
+
+If a member would like to work on the issue themself, the `assignee` field is where this should be defined.
+If a member would like help from another member, they should assign the other team member to the issue, and 
+leave a comment in the issue itself describing what help is needed. 
+
+**Labels** are important for understanding what type of issues/bugs exist in the application. When a bug is 
+created, make sure the proper labels are applied. These labels will be abstract, such as: `bug`, `fix` or `feature`
+and they will also be specific, such as: `parser`, `i/o` or `processer`. A combination of both styles of labels
+allows other team members to understand what is going on. If a member feels an issue is missing, they are free
+to create new ones, but there is a such thing as **too many labels** a few per issue is totally fine. They are
+not meant to replace the description.
+
+**Priority** is the final important factor to consider. In this project, priority will be defined using labels
+as well. The policy defined above will apply here to priority labels as well. However, these labels are 
+**mutually exclusive**.
+
+###### Projects (Sprints)
+
+The use of the `projects` tab in the VCS will allow the team to remain organized as create notes and action 
+items that should be completed before one another. These resemble `sprints` from the `AGILE` development life cycle.
+A new "project" should be created when a large piece of functionality needs to be created. Issues can **and should**
+be attached to the projects they are related too. This will continue to encourage teamwork and organization.
+
+Projects should have defined criteria, such as input and outputs, expectations and a semi-defined timeline. 
+Once a description and is defined, tasks can be added and moved around as needed. The team will use **Kanban**
+project types, as they are simple and easy to understand for new team members.