[#4342] Add Support page in the Styleguide)

* Initial commit for Sales and Support pages
* Additions and rearranging pages
* Add more details for Sales/Marketing, add more details Support
* Changes after review
* Minor updates to the Sales/Support content
* Update with additional notes about release
* Take out unecessary Sales intro list
* Update release meeting notes, change bugfix to defect
* Delete Sales Page
* Revert the changes made to the Documentation page concerning Sales info
* Only add semantic newline
* Add two new points for release process
* After Support review
* Add changes to Onboarding page after review

content/support.rst

@@ -0,0 +1,145 @@
+Support
+#######
+
+:menu_order: 009
+
+.. contents::
+
+
+Introduction
+============
+
+This page describes the guidelines for the support activities together with
+best practices that were extracted based on our past experience with support
+related activities.
+
+The main point of contact for Support and liaising with customers
+is via the Google Group email.
+
+
+Template: Obtaining the installation detail
+-------------------------------------------
+
+The following is a template to obtain the installation detail.
+Please modify the template below to suit.
+
+.. sourcecode:: rst
+
+	Can you please provide us with the following details about the system
+	used for running the product:
+
+	* Product version?
+
+	* Operating system name and version?
+
+	* File transfer protocol(s) used?
+
+	* Please send through a time-stamped version of the server-side log, and
+	   if relevant, the corresponding client-side log.
+
+	* Other information (if known).
+
+	* Please advise brief details of any: integration, software, resilience / redundancy /
+	high availability architecture, security or other technologies that interact with the
+	product.
+	e.g. Firewalls, Proxy, LDAP, Active Directory, Single Sign On, Management software etc.
+
+	Before releasing a new version, we run an automated test suite to validate new features
+	and check for regressions.
+
+	By knowing details about your installations, we can configure the test suite to run
+	against a similar setup.
+
+	This information will not be shared with any other third party and will be used
+	solely for improving further support for you and development of the product.
+
+
+Using the installation details
+------------------------------
+
+Once the installation details are provided, recreate the issue in a similar
+environment.
+
+This should be created via a dedicated VM for testing / support activities.
+
+
+Chat
+====
+
+`Olark <https://www.olark.com>`_ is currently used for chat with our customers
+or possible customers.
+
+Each chat transcript is automatically forwarded to the Support email list.
+
+A chat can be transferred and other actions can be taken with the chat via
+Olark `commands <https://www.olark.com/help/commands>`_.
+
+
+Licenses and support contract
+=============================
+
+See the `Support options page <https://www.sftpplus.com/support/options.html>`_
+which describes the options available.
+
+If a support case goes beyond the standard option (such as a new
+product feature), the Sales team will determine the quote.
+
+See the `Life cycle page <https://www.sftpplus.com/product/life-cycle.html>`_ 
+for details about the product life cycle.
+
+If a feature request is obtained, check that it is included in the
+`Product roadmap <https://www.sftpplus.com/product/roadmap.html>`_ 
+
+
+Support Case Management
+=======================
+
+
+Working on a support case
+-------------------------
+
+Support cases can be received either through the online contact form,
+direct email or phone call.
+
+Email and support forms are the preferred methods.
+For call, request the customer at the beginning to do a follow up over email
+and confirm in writing as the first preference.
+As second preference, follow up with a summary of the call and request the
+customer to confirm the details.
+
+When a support case is started, obtain and collate as much information as
+possible.
+This will help in potential follow-up with the rest of the Support team.
+
+
+Troubleshooting a Support Case
+------------------------------
+
+The `troubleshooting theory from CompTIA <http://certmag.com/guide-troubleshooting-theory-comptia-perspective/>`_ is a good overview when
+troubleshooting a support case:
+
+1. Identify the problem
+2. Establish a theory of probable cause (question the obvious)
+3. Test the theory to determine cause
+4. Establish a plan
+5. Determine system status
+6. Make a record
+
+
+Escalating a Support Case due to defects
+----------------------------------------
+
+If the support case leads to finding a defect or it needs to be escalated,
+a Trac ticket should be created with details of the customer.
+
+For the defect, create a Trac ticket with priority High and notify the
+customer of the Trac ticket ID so that they can follow up with Support on the
+issue.
+
+
+Holding a screenshare session
+-----------------------------
+
+GoToMeeting can be used to conduct a screenshare or meeting session with the
+customer if the issue is best resolved via screenshare.
+

docs/office/leave.rst

@@ -1,6 +1,11 @@
 Leave / Holiday
 ###############
 
+<<<<<<< HEAD:content/leave.rst
+:menu_order: 020
+
+=======
+>>>>>>> master:docs/office/leave.rst
 General
 =======
 

docs/office/onboarding.rst

@@ -1,6 +1,13 @@
 Onboarding
 ##########
 
+<<<<<<< HEAD:content/onboarding.rst
+:menu_order: 018
+:url: /onboarding.html
+:save_as: onboarding.html
+
+=======
+>>>>>>> master:docs/office/onboarding.rst
 This page is used to organize tasks and track the onboarding process for new members.
 You can see past/active tasks in the `onboarding repo <hhttps://github.com/chevah/onboarding/>`_.
 
@@ -40,7 +47,7 @@ When submitting repo changes based on your feedback:
 
 - Use the `Github PR template <https://github.com/chevah/styleguide/blob/463556d4e9219e28fd030759ba7af9c0a3ec89e6/.github/PULL_REQUEST_TEMPLATE>`_ and @ mention the oboarding supervisor for review.
 
-**Review and provide feedback for the SFTPPlus server/client products**
+**Review and provide feedback for the software**
 
 - Obtain the trial version of the server and client.
 
@@ -51,15 +58,15 @@ When submitting repo changes based on your feedback:
 - Any issues or comments can be mentioned in the Milestone tickets.
 
 
-**Review and provide feedback for the SFTPPlus.com website.**
+**Review and provide feedback for the website.**
 
-- Review the SFTPPlus.com website excluding the documentation.
+- Review the website excluding the documentation.
 
 - Comment in the Milestone your feedback.
 
 When submitting repo changes based on your feedback:
 
-- Clone the repository chevah/sftpplus.com and create PRs to the chevah/sftpplus.com repo.
+- Clone the repository and create PRs to the right repo.
 
 - Follow the README requirements and development to run the site locally.
 
@@ -79,19 +86,27 @@ Ask the tech lead for any questions.
 
 * Take note of the `coding conventions <http://styleguide.chevah.com>`_ applied for this project. These general coding conventions are for all 'texts' (code, documentation, etc). 
 
+<<<<<<< HEAD:content/onboarding.rst
+* There are specific rules that apply to programming languages.
+Begin by reading the general `coding conventions <http://styleguide.chevah.com>`_.
+=======
 * There are specific rules that apply to programming languages. Begin by reading the general `coding conventions <http://styleguide.chevah.com>`_.
+>>>>>>> master:docs/office/onboarding.rst
   Then review each language specific convention as you will be writing in that language.
 
-* While you are in IRC on #chevah "in the office", set to auto-away to let others know that you are not at the computer. Set the away status to "busy" (/away busy) if you are working at something and don't want to be disturbed.
+* While you are in IRC on #chevah "in the office", set to auto-away to let others know that you are not at the computer.
+Set the away status to "busy" (/away busy) if you are working at something and don't want to be disturbed.
 
 * You will use your own hardware for work tasks.
   To compensate for this usage of your hardware we will cover hardware expenses for your home computer.
   If you need a hardware component or peripheral that will help your work related tasks, ask and we can cover those expenses.
   Ask tech lead for details.
 
-* Each task that you are working on should have a ticket in Trac/Github. If there is no ticket, create one and start the `Ticket Work Flow <http://styleguide.chevah.com/tickets.html>`_. 
+* Each task that you are working on should have a ticket in Trac/Github.
+If there is no ticket, create one and start the `Ticket Work Flow <http://styleguide.chevah.com/tickets.html>`_. 
 
-* While some tasks are on Github, there is a Trac/Github integration. See `Overview of the GitHub and Trac integration <http://styleguide.chevah.com/review.html#overview-of-the-github-and-trac-integration>`_.
+* While some tasks are on Github, there is a Trac/Github integration.
+See `Overview of the GitHub and Trac integration <http://styleguide.chevah.com/review.html#overview-of-the-github-and-trac-integration>`_.
 
 * Tickets corresponding to you that you are currently working should have the 'owner' value set to your Trac username.
 
@@ -101,10 +116,15 @@ Ask the tech lead for any questions.
 
 * From time to time, check the Trac timeline to stay up to date with latest changes in the project.
 
+<<<<<<< HEAD:content/onboarding.rst
+* When starting a support ticket, request the OS version architecture used and version of the products.
+=======
 * When starting a support ticket, request the OS version architecture used and version of the SFTPPlus products.
   Further details in Trac.
+>>>>>>> master:docs/office/onboarding.rst
 
-* Before a Pull Request is closed, it must be reviewed by at least one other team member. Further info of the `Review process <http://styleguide.chevah.com/review.html>`_.
+* Before a Pull Request is closed, it must be reviewed by at least one other team member.
+Further info of the `Review process <http://styleguide.chevah.com/review.html>`_.
 
 * Leave days can be requested at any time.
   Check the dedicated page in Trac.
@@ -125,10 +145,8 @@ The initial stage is over when all the Onboarding tickets from the milestone ded
 
 We are far from single-sign-on and while working on this project you will have many different accounts.
 
-For GitHub you can create a new account or use your current account and ask to be part of our GitHub organisations (Chevah and ProAtria) and our core team. Ensure that in git-config, your user.email is the Pro:Atria email when working in the Chevah project repositories.
-
 We use Skype for phone calls.
-Use the dedicated ProAtria Skype account as the official tools to collaborate with the team and to make phone calls.
+Use the dedicated Skype account as the official tools to collaborate with the team and to make phone calls.
 
 **Ask our system administrators for all of the followings:**
 
@@ -143,6 +161,8 @@ Use the dedicated ProAtria Skype account as the official tools to collaborate wi
 * You will need a Trac account setup.
   Trac tickets are used for managing work items since there is no support with the web-based GitHub issue/task/defect management
   Trac also contains wiki pages to other documentation.
+<<<<<<< HEAD:content/onboarding.rst
+=======
   Get to know the team by checking the dedicated page in our private wiki.
 
 
@@ -162,9 +182,6 @@ Users_Files
 In the build folder are example folders of a test user which can be used to help test various features of SFTPPlus.
 
 Below is an example of using users_files / the test user to access the HTTPS feature:
+>>>>>>> master:docs/office/onboarding.rst
 
-1. Navigate to the server folder
-2. ./paver.sh run and log in to https://localhost:10020
-3. Under Status in the Local Manager edit the https status configuration and add app-uuid. This is so that application accounts are enabled for this service.
-4. Save the configuration and selected Start
-5. Go to https://localhost:10443 and log in using the test data credentials. If you go to test-server.ini in the test-data folder you can see the credentials to log in as the test user.  After authenticating, you should see the test folders and files.
+* Get to know the team by checking the dedicated page in our private wiki.

docs/office/security.rst

@@ -1,6 +1,11 @@
 Security
 ########
 
+<<<<<<< HEAD:content/security.rst
+:menu_order: 010
+
+=======
+>>>>>>> master:docs/office/security.rst
 .. contents::
 
 

docs/office/work.rst

@@ -1,6 +1,11 @@
 Work
 ####
 
+<<<<<<< HEAD:content/work.rst
+:menu_order: 019
+
+=======
+>>>>>>> master:docs/office/work.rst
 .. contents::
 
 General

docs/product/documentation.rst

@@ -517,7 +517,7 @@ product as long as there is also a workaround provided in the Known Issues
 page.
 
 Known Issues will include a reference to the internal bug ID which provided
-further details about that issues
+further details about those issues.
 
 
 Mock ups and designs for the website

docs/product/release.rst

@@ -44,7 +44,7 @@ the next release.
 Tickets that must be in the 'next-release' are set with priority 'High'.
 
 The general timeframe between each release is 30 to 45 days.
-However, bugfixes are worked on and released as soon as it is feasible by the
+However, defects are worked on and released as soon as it is feasible by the
 development team.
 
 
@@ -84,23 +84,28 @@ Some functions of the **release manager** are:
   to make sure no regressions were introduced on the tests executed post-merge.
 * Creating high priority tickets in case the tests are failing on master.
 * Coordinating story tickets for the milestone.
-
+* After sending the release branch to RQM, check that the Downloads page is updated.
+* Check that a tag is created for the release, and that the tag points to the release branch and   not the release merge.
+* Check that RQM has closed the release PR and associated Trac.
+* After the Downloads page is updated, ensure that the release branch is merged
+  with the master branch.
+* Sends the newsletter to the relevant list/s.
 
 Release Manager should look into obtaining access to the following:
 
-* Write access to sftpplus.com production (from infrastructure team) to
+* Write access to production website (from infrastructure team) to
   the news release to the website.
 * Ability to stage a release branch to staging server then to production
   server.
 * Access to Mailchimp to send the release newsletter.
 * Access to the Support helpdesk or emails to know which customers should be
   contacted directly if the release is awaiting upon them.
 
-
 When the release is out, the Release Manager organizes the team release
 meeting (times and dates), initiates the call and holds the meeting including
 a distributed agenda.
-A template of the release meeting, including past notes is `located here <https://drive.google.com/drive/folders/0B91muor_IWXBaHp1eExRbGcyZ28?usp=sharing>`_
+Release meeting notes are `located here <https://drive.google.com/drive/u/3/folders/0BwQo7116Iy2tZ2M2bDhadFV4R0E>`_
+
 
 The Release Branch
 ==================
@@ -160,10 +165,6 @@ These are the extra steps for checking a release in production:
 
 Future improvements for the automated release process:
 
-* Create a release notification list and send an email to everyone who cares
-  about new releases.
-  The email should include a changelog for the latest version.
-  Trac ticket #525.
 * Add a news article to our website
 * Trigger a website crawler to check broken links for download pages and
   documentation.
@@ -189,7 +190,7 @@ Here are some categories::
 
 * Major changes (only for major releases)
 * New features
-* Bug fixes with internal bug ID (this is the only section for bugfix releases)
+* Bug fixes with internal bug ID (this is the only section for defect releases)
 * Deprecation and Removals
 * Documentation changes
 * Other changes
@@ -504,13 +505,13 @@ While working on a product, we have the following types of branches::
 * task-branch - multiple ephemeral branches where a new feature or fix has a task-branch
 
 Each released version has a dedicated tag.
-When you need to create a bugfix release or a maintenance release for a previous version, you will
+When you need to create a defect release or a maintenance release for a previous version, you will
 create the release branch based on the desired tag.
 
 The **master** branch should be kept in good shape so that we can release it at
 any time.
-Especially if a security bugfix is found, we will make a new release as soon
-as the bug is fixed.
+Especially if a security defect is found, we will make a new release
+as soon as the defect is fixed.
 
 Releases may include fixes for defects observed by customers or new product
 features requested by customers.