Fix the doc

m4system · Dec 18, 2019 · 50070ce · 50070ce
1 parent c411195
commit 50070ce
Show file tree

Hide file tree

Showing 15 changed files with 97 additions and 45 deletions.
diff --git a/config.toml b/config.toml
@@ -11,7 +11,6 @@ enableGitInfo = true
 
 #publishDir = "docs"
 
-
 # Language settings
 contentDir = "content/en"
 defaultContentLanguage = "en"

diff --git a/content/en/docs/Contribution guidelines/_index.md b/content/en/docs/Contribution guidelines/_index.md
@@ -7,14 +7,12 @@ description: >
 ---
 
 {{% pageinfo %}}
-These basic sample guidelines assume that your Docsy site is deployed using Netlify and your files are stored in GitHub. You can use the guidelines "as is" or adapt them with your own instructions: for example, other deployment options, information about your doc project's file structure, project-specific review guidelines, versioning guidelines, or any other information your users might find useful when updating your site. [Kubeflow](https://github.com/kubeflow/website/blob/master/README.md) has a great example.
-
-Don't forget to link to your own doc repo rather than our example site! Also make sure users can find these guidelines from your doc repo README: either add them there and link to them from this page, add them here and link to them from the README, or include them in both locations.
+Work in Progress.  Feel free to contribute with a [Pull Request](https://github.com/m4system/m4system.ca/pulls)!
 {{% /pageinfo %}}
 
 We use [Hugo](https://gohugo.io/) to format and generate our website, the
 [Docsy](https://github.com/google/docsy) theme for styling and site structure, 
-and [Netlify](https://www.netlify.com/) to manage the deployment of the site. 
+and [GitHub Actions](https://help.github.com/en/actions/automating-your-workflow-with-github-actions) to manage the deployment of the site. 
 Hugo is an open-source static site generator that provides us with templates, 
 content organisation in a standard directory structure, and a website generation 
 engine. You write the pages in Markdown (or HTML if you want), and Hugo wraps them up into a website.
@@ -24,22 +22,18 @@ use GitHub pull requests for this purpose. Consult
 [GitHub Help](https://help.github.com/articles/about-pull-requests/) for more
 information on using pull requests.
 
-## Quick start with Netlify
+## Quick start on GitHub
 
 Here's a quick guide to updating the docs. It assumes you're familiar with the
 GitHub workflow and you're happy to use the automated preview of your doc
 updates:
 
-1. Fork the [Goldydocs repo](https://github.com/google/docsy-example) on GitHub.
+1. Fork the [m4system.ca repo](https://github.com/m4system/m4system.ca) on GitHub.
 1. Make your changes and send a pull request (PR).
 1. If you're not yet ready for a review, add "WIP" to the PR name to indicate 
   it's a work in progress. (**Don't** add the Hugo property 
   "draft = true" to the page front matter, because that prevents the 
   auto-deployment of the content preview described in the next point.)
-1. Wait for the automated PR workflow to do some checks. When it's ready,
-  you should see a comment like this: **deploy/netlify — Deploy preview ready!**
-1. Click **Details** to the right of "Deploy preview ready" to see a preview
-  of your updates.
 1. Continue updating your doc and pushing your changes until you're happy with 
   the content.
 1. When you're ready for a review, add a comment to the PR, and remove any
@@ -51,17 +45,17 @@ If you've just spotted something you'd like to change while using the docs, Docs
 
 1. Click **Edit this page** in the top right hand corner of the page.
 1. If you don't already have an up to date fork of the project repo, you are prompted to get one - click **Fork this repository and propose changes** or **Update your Fork** to get an up to date version of the project to edit. The appropriate page in your fork is displayed in edit mode.
-1. Follow the rest of the [Quick start with Netlify](#quick-start-with-netlify) process above to make, preview, and propose your changes.
+1. Follow the rest of the [Quick start on GitHub](#quick-start-with-github) process above to make, preview, and propose your changes.
 
 ## Previewing your changes locally
 
 If you want to run your own local Hugo server to preview your changes as you work:
 
-1. Follow the instructions in [Getting started](/docs/getting-started) to install Hugo and any other tools you need. You'll need at least **Hugo version 0.45** (we recommend using the most recent available version), and it must be the **extended** version, which supports SCSS.
-1. Fork the [Goldydocs repo](https://github.com/google/docsy-example) repo into your own project, then create a local copy using `git clone`. Don’t forget to use `--recurse-submodules` or you won’t pull down some of the code you need to generate a working site.
+1. Follow the instructions in [Getting started](https://gohugo.io/getting-started/quick-start/) to install Hugo and any other tools you need. You'll need at least **Hugo version 0.45** (we recommend using the most recent available version), and it must be the **extended** version, which supports SCSS.
+1. Fork the [m4system.ca repo](https://github.com/m4system/m4system.ca) repo into your own project, then create a local copy using `git clone`. Don’t forget to use `--recurse-submodules` or you won’t pull down some of the code you need to generate a working site.
 
     ```
-    git clone --recurse-submodules --depth 1 https://github.com/google/docsy-example.git
+    git clone --recurse-submodules --depth 1 https://github.com/m4system/m4system.ca.git
     ```
 
 1. Run `hugo server` in the site root directory. By default your site will be available at http://localhost:1313/. Now that you're serving your site locally, Hugo will watch for changes to the content and automatically refresh your site.
@@ -70,11 +64,11 @@ If you want to run your own local Hugo server to preview your changes as you wor
 
 ## Creating an issue
 
-If you've found a problem in the docs, but you're not sure how to fix it yourself, please create an issue in the [Goldydocs repo](https://github.com/google/docsy-example/issues). You can also create an issue about a specific page by clicking the **Create Issue** button in the top right hand corner of the page.
+If you've found a problem in the docs, but you're not sure how to fix it yourself, please create an issue in the [m4system.ca repo](https://github.com/m4system/m4system.ca/issues). You can also create an issue about a specific page by clicking the **Create Issue** button in the top right hand corner of the page.
 
 ## Useful resources
 
-* [Docsy user guide](wherever it goes): All about Docsy, including how it manages navigation, look and feel, and multi-language support.
+* [Docsy user guide](https://www.docsy.dev/docs/getting-started/): All about Docsy, including how it manages navigation, look and feel, and multi-language support.
 * [Hugo documentation](https://gohugo.io/documentation/): Comprehensive reference for Hugo.
 * [Github Hello World!](https://guides.github.com/activities/hello-world/): A basic introduction to GitHub concepts and workflow.
 

diff --git a/content/en/docs/Overview/_index.md b/content/en/docs/Overview/_index.md
@@ -3,36 +3,59 @@ title: "Overview"
 linkTitle: "Overview"
 weight: 1
 description: >
-  Here's where your user finds out if your project is for them.
+  Documentation for M4 System, the Modern Monitoring and Management System.
 ---
 
 {{% pageinfo %}}
-This is a placeholder page that shows you how to use this template site.
+Work in Progress.  Feel free to contribute with a [Pull Request](https://github.com/m4system/m4system.ca/pulls)!
 {{% /pageinfo %}}
 
 
-The Overview is where your users find out about your project. Depending on the size of your docset, you can have a separate overview page (like this one) or put your overview contents in the Documentation landing page (like in the Docsy User Guide). 
-
-Try answering these questions for your user in this page:
-
-## What is it?
-
-Introduce your project, including what it does or lets you do, why you would use it, and its primary goal (and how it achieves it). This should be similar to your README description, though you can go into a little more detail here if you want.
+## Features
+
+* Web-based multi-tenant SLA management system using django and python 3
+* Mysql for general storage
+* InfluxDB for historical time-series storage
+* Grafana for graphing historical data
+* Memcached for volatile cache
+* RabbitMQ as distributed queuing system
+* Djcelery as task runner
+* HTML5 responsive frontend with static asset compression
+* Per-group views
+* Backend admin panel using Jet django-admin
+* Asset list
+* Assign checks to multiple assets
+* SNMP and bash exec available (numbers, strings, booleans)
+* Assign warning and critical thresholds to checks
+* Assign SLAs to checks
+* Checks, thresholds and SLAs can be configured to fail on 1 or all hosts/checks assigned for complex scenarios like redundant pumps.
+* Email template editor in the Back-end
+* Group-based notifications.
+* Users can edit their own notification email in the frontend.
+* View check info, last 30 minutes and download historicals from the front end as a user.
+* Group-based Permission system for silencing checks, seeing info, graph and historical
+* Metadata system
+* Reports using django management commands
+* Full audit log of object modifications (django-reversion). events, errors.
+* Temporary silence checks from the front-end
+* SNMP Traps collection (for vertiv gear)
+* Easily identify threshold and SLA faults on the front-end with color transitions
 
 ## Why do I want it?
 
-Help your user know if your project will help them. Useful information can include: 
+With M4 System, you can address complex scenarios involving many hundreds of devices.  
+Manage everything from a web UI with access control and a full audit trail.
 
-* **What is it good for?**: What types of problems does your project solve? What are the benefits of using it?
+* **What is it good for?**: SNMP monitoring.
 
-* **What is it not good for?**: For example, point out situations that might intuitively seem suited for your project, but aren't for some reason. Also mention known limitations, scaling issues, or anything else that might let your users know if the project is not for them.
+* **What is it not good for?**: Network and System Monitoring.  While it is able to do such monitoring, other software will do a better job.
 
-* **What is it *not yet* good for?**: Highlight any useful features that are coming soon.
+* **What is it *not yet* good for?**: Modbus Monitoring.
 
 ## Where should I go next?
 
-Give your users next steps from the Overview. For example:
+Interested ? Keep on reading.
 
-* [Getting Started](/getting-started/): Get started with $project
-* [Examples](/examples/): Check out some example code!
+* [Getting Started]({{< relref "docs/tutorials/_index.md" >}}): Get started with M4 System
+* [Screenshots]({{< relref "docs/screenshots/_index.md" >}}): Check out some screenshots!
 
diff --git a/content/en/docs/Screenshots/_index.md b/content/en/docs/Screenshots/_index.md
@@ -0,0 +1,41 @@
+---
+title: "Screenshots from M4System"
+linkTitle: "Screenshots"
+weight: 10
+description: >
+  Some screenshots from a basic install of M4 System.
+---
+
+{{% pageinfo %}}
+Work in Progress.  Feel free to contribute with a [Pull Request](https://github.com/m4system/m4system.ca/pulls)!
+{{% /pageinfo %}}
+
+## The Screenshots
+
+### Frontend notifications of polling errors
+
+![Frontend notifications of polling errors](m4-screenshot1.png)
+
+### Tiles are red when in critical status
+
+![Tiles are red when in critical status](m4-screenshot2.png)
+
+### A Threshold fails a check which fails a SLA
+
+![A Threshold fails a check which fails a SLA](m4-screenshot3.png)
+
+### Can also be a warning, where we notify but are not yet in trouble.
+
+![Can also be a warning, where we notify but are not yet in trouble.](m4-screenshot4.png)
+
+### Mobile Friendly
+
+![Mobile Friendly](m4-screenshot5.png)
+
+### More mobile friendliness
+
+![More mobile friendliness](m4-screenshot6.png)
+
+### Comes with a backend Backend 
+
+![Comes with a backend](m4-screenshot7.png)
diff --git a/content/en/docs/Screenshots/m4-screenshot1.png b/content/en/docs/Screenshots/m4-screenshot1.png
diff --git a/content/en/docs/Screenshots/m4-screenshot2.png b/content/en/docs/Screenshots/m4-screenshot2.png
diff --git a/content/en/docs/Screenshots/m4-screenshot3.png b/content/en/docs/Screenshots/m4-screenshot3.png
diff --git a/content/en/docs/Screenshots/m4-screenshot4.png b/content/en/docs/Screenshots/m4-screenshot4.png
diff --git a/content/en/docs/Screenshots/m4-screenshot5.png b/content/en/docs/Screenshots/m4-screenshot5.png
diff --git a/content/en/docs/Screenshots/m4-screenshot6.png b/content/en/docs/Screenshots/m4-screenshot6.png
diff --git a/content/en/docs/Screenshots/m4-screenshot7.PNG b/content/en/docs/Screenshots/m4-screenshot7.PNG
diff --git a/content/en/docs/Tutorials/_index.md b/content/en/docs/Tutorials/_index.md
@@ -9,7 +9,7 @@ description: >
 ---
 
 {{% pageinfo %}}
-This is a placeholder page that shows you how to use this template site.
+Work in Progress.  Feel free to contribute with a [Pull Request](https://github.com/m4system/m4system.ca/pulls)!
 {{% /pageinfo %}}
 
 Tutorials are **complete worked examples** made up of **multiple tasks** that guide the user through a relatively simple but realistic scenario: building an application that uses some of your project’s features, for example. If you have already created some Examples for your project you can base Tutorials on them. This section is **optional**. However, remember that although you may not need this section at first, having tutorials can be useful to help your users engage with your example code, especially if there are aspects that need more explanation than you can easily provide in code comments.

diff --git a/content/en/docs/Tutorials/linux.md b/content/en/docs/Tutorials/linux.md
@@ -7,7 +7,7 @@ description: >
 ---
 
 {{% pageinfo %}}
-WIP
+Work in Progress.  Feel free to contribute with a [Pull Request](https://github.com/m4system/m4system.ca/pulls)!
 {{% /pageinfo %}}
 
 ## Install python 3.5

diff --git a/content/en/docs/Tutorials/windows.md b/content/en/docs/Tutorials/windows.md
@@ -6,7 +6,9 @@ description:
   This setup is not designed for production use.
 ---
 
-[![Actions Status](https://github.com/dgagnon/m4system/workflows/M4%20Unit%20Test/badge.svg)](https://github.com/dgagnon/m4system/actions)
+{{% pageinfo %}}
+Work in Progress.  Feel free to contribute with a [Pull Request](https://github.com/m4system/m4system.ca/pulls)!
+{{% /pageinfo %}}
 
 
 ## Install Python

diff --git a/content/en/docs/_index.md b/content/en/docs/_index.md
@@ -9,15 +9,8 @@ menu:
 ---
 
 {{% pageinfo %}}
-Work in Progress.  Feel free to contribute with a pull request!
+Work in Progress.  Feel free to contribute with a [Pull Request](https://github.com/m4system/m4system.ca/pulls)!
 {{% /pageinfo %}}
 
 
-This section is where the user documentation for your project lives - all the information your users need to understand and successfully use your project. 
-
-For large documentation sets we recommend adding content under the headings in this section, though if some or all of them don’t apply to your project feel free to remove them or add your own. You can see an example of a smaller Docsy documentation site in the [Docsy User Guide](https://docsy.dev/docs/), which lives in the [Docsy theme repo](https://github.com/google/docsy/tree/master/userguide) if you'd like to copy its docs section. 
-
-Other content such as marketing material, case studies, and community updates should live in the [About](/about/) and [Community](/community/) pages.
-
-Find out how to use the Docsy theme in the [Docsy User Guide](https://docsy.dev/docs/). You can learn more about how to organize your documentation (and how we organized this site) in [Organizing Your Content](https://docsy.dev/docs/best-practices/organizing-content/).
-
+This section is where the user documentation for this project lives - all the information users need to understand and successfully use M4 System.