Dev

.vscode/settings.json

@@ -1,3 +1,4 @@
 {
-    "restructuredtext.confPath": ""
+    "restructuredtext.confPath": "",
+    "restructuredtext.languageServer.disabled": true
 }

README.rst

@@ -2,6 +2,38 @@
 The Qubinode Project
 ********************
 
+The Qubinode documentation page uses sphinx_rtd_theme to create a web browser for the http://qubinode.io  project.
 
-Configuring documentation page
-==============================
+Building the Qubinode documentation page
+=========================================
+
+To build the Qubinode documentation page use the following information
+
+Required applications to build and configure qubinode documentation
+--------------------------------------------------------------------
+* https://pandoc.org
+* https://sphinx-rtd-theme.readthedocs.io
+* https://purduecam2project.github.io/CAM2WebUI/basicSetup/sphinx.html
+
+Notable files and directories
+------------------------------
+ * The docsource folder is the build directory 
+ * The docs folder is the publish directory 
+ * the conf.py is the configuration file for sphinx
+ * the MAKE file is the build file for sphinx 
+
+Building Qubionde web page
+--------------------------
+.. highlight:: python
+
+1. Under the docsource directory
+.. :: 
+   make github
+
+2. Test the build by running
+.. :: 
+   open ../docs/index.html   
+
+3. To convert .md files to .rst:
+.. ::
+   pandoc example.md --from markdown --to rst -s -o example.rst

docs/.buildinfo

@@ -1,4 +1,4 @@
 # Sphinx build info version 1
 # This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
-config: 0142de1d02fda9b001af6b68285781aa
+config: d4aad98f01e6453428bce1cf2bc18cc3
 tags: 645f666f9bcd5a90fca523b33c5a78b7

docs/_sources/documents/code_of_conduct.rst.txt

@@ -0,0 +1,87 @@
+Contributor Covenant Code of Conduct
+====================================
+
+Our Pledge
+----------
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our
+project and our community a harassment-free experience for everyone,
+regardless of age, body size, disability, ethnicity, sex
+characteristics, gender identity and expression, level of experience,
+education, socio-economic status, nationality, personal appearance,
+race, religion, or sexual identity and orientation.
+
+Our Standards
+-------------
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+-  Using welcoming and inclusive language
+-  Being respectful of differing viewpoints and experiences
+-  Gracefully accepting constructive criticism
+-  Focusing on what is best for the community
+-  Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+-  The use of sexualized language or imagery and unwelcome sexual
+   attention or advances
+-  Trolling, insulting/derogatory comments, and personal or political
+   attacks
+-  Public or private harassment
+-  Publishing others’ private information, such as a physical or
+   electronic address, without explicit permission
+-  Other conduct which could reasonably be considered inappropriate in a
+   professional setting
+
+Our Responsibilities
+--------------------
+
+Project maintainers are responsible for clarifying the standards of
+acceptable behavior and are expected to take appropriate and fair
+corrective action in response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit,
+or reject comments, commits, code, wiki edits, issues, and other
+contributions that are not aligned to this Code of Conduct, or to ban
+temporarily or permanently any contributor for other behaviors that they
+deem inappropriate, threatening, offensive, or harmful.
+
+Scope
+-----
+
+This Code of Conduct applies both within project spaces and in public
+spaces when an individual is representing the project or its community.
+Examples of representing a project or community include using an
+official project e-mail address, posting via an official social media
+account, or acting as an appointed representative at an online or
+offline event. Representation of a project may be further defined and
+clarified by project maintainers.
+
+Enforcement
+-----------
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may
+be reported by contacting the project team at [email protected].
+All complaints will be reviewed and investigated and will result in a
+response that is deemed necessary and appropriate to the circumstances.
+The project team is obligated to maintain confidentiality with regard to
+the reporter of an incident. Further details of specific enforcement
+policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in
+good faith may face temporary or permanent repercussions as determined
+by other members of the project’s leadership.
+
+Attribution
+-----------
+
+This Code of Conduct is adapted from the `Contributor
+Covenant <https://www.contributor-covenant.org>`__, version 1.4,
+available at
+https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+For answers to common questions about this code of conduct, see
+https://www.contributor-covenant.org/faq

docs/_sources/documents/contributing_guide.rst.txt

@@ -0,0 +1,245 @@
+Qubinode Git branching strategy
+===============================
+
+Introduction
+------------
+
+*This guide contains all the information needed to become a contributor
+on the Qubinode project#### Please follow our git branching model so
+that everyone will have a pleasant experience contributing to this
+project.*
+
+Branching and releasing
+-----------------------
+
+Qubinode project Branches
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following are the only branches that will exists on the official
+Qubinode project (https://github.com/Qubinode):
+
+-  *main* holds the latest production ready code
+
+-  Rules: \*\* Should be the same for every Git user
+
+-  *develop* holds latest changes for next release
+
+-  Rules: \*\* Merge to *main* branch when all codes are stable \*\* Tag
+   *main* branch with new release number after merging from *develop*
+   branch
+
+Qubinode supporting branches
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The supporting branches will only exist on the developer’s
+repository#### Once the code is ready to be pushed to either the main or
+develop branch#### Once the merge request is accepted, the developer can
+delete the supporting branch.
+
+-  *feature* holds code for developed new features that will be merged
+   in the next or future Qubinode release
+
+-  Rules: \*\* May branch off from the *develop* branch \*\* Must merge
+   back to the *develop* branch \*\* Exists on developer’s repository
+   only \*\* Discarded once all code are merged to *develop* bramch
+
+-  *release* support preparation of a new production release#### Use for
+   minor changes or bugfixes
+
+-  Rules: \*\* May branch off from the *develop* branch \*\* Must merge
+   back to the *develop* and *main* branch \*\* Exists on developer’s
+   repository only \*\* Only core developers can create and push release
+   branch
+
+-  *hotfix* Use to push a fix for an error in the *main* branch
+
+-  Rules: \*\* May branch off from *main* branch \*\* Must be merged
+   back into *main* and *develop* branch
+
+Scenerios
+---------
+
+Adding a new feature
+~~~~~~~~~~~~~~~~~~~~
+
+switch to the develop branch:
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+   $ git checkout develop
+
+Fetch the latest code from the develop branch code:
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+   $ git fetch develop
+
+Create new feature branch using the nomenclature feature-
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+   $ git checkout -b feature-<issue number> develop
+
+After coding, pushing new code to feature branch, checkout the develop branch
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+   $ git checkout develop
+
+Merge the new feature to the develop branch
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+   $ git merge --no-ff feature-<issue number>
+
+Delete the feature branch
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+   $ git branch -d feature-<issue number>
+
+Push changes to the develop branch
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+   $ git push origin develop
+
+Submit a merge request to the Qubinode repository
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+HotFixes
+~~~~~~~~
+
+switch to the main branch:
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+   $ git checkout main
+
+Create new hotfix branch using the nomenclature hotfix-
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+   $ git checkout -b hotfix-<issue number> main
+
+After coding, pushing new code to feature branch, checkout the main branch
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+   $ git checkout main
+
+Merge the new hotfix to the Qubinode main branch
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+   $ git merge --no-ff hotfix-<issue number>
+
+Tag the Master branch with a new minor release version(if the current version is 2.1)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+   $ git tag -a <release minor release number>
+
+Include bugfix to the develop branch, check out the develop branch
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+   $ git checkout develop
+
+Merge the new hotfix to the Qubinode develop main branch
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+   $ git merge --no-ff hotfix-<issue number>
+
+Delete the hotfix branch
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+   $ git branch -d hotfix-<issue number>
+
+Pushing out a new release
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+After coding all features, hotfixes, and meet the requirement for the
+next Qubinode release, we will create a release branch that’s tagged
+with a code name based on the next alphabetically available fruit (
+i.e#### apple, banana)
+
+Create new release branch using the fruit nomenclature
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+   $ git checkout -b release-<fruit nomenclature, i.e apple> develop
+
+Tag the release branch
+^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+   $ git tag -a <fruit nomenclature, i.e apple>
+
+Commit all changes to release branch
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+   $ git commit -a -m "next qubinode release"
+
+Merge all changes to main branch, check out the main branch
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+   $ git checkout main
+
+Merge changes to the main branch
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+   $ git merge --no-ff release-<fruit nomenclature, i.e apple>
+
+Tag the new release on the main branch
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+   $ git tag -a <next release version i.e 2.2>
+
+Update the develop branch with the new relase, checkout the develop branch
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+   $ git checkout develop
+
+Merge changes to develop branch
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+   $ git merge --no-ff <next release version i.e 2.2>
+
+Delete the release branch
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+::
+
+   $ git branch -d release-<fruit nomenclature, i.e apple>