merge master.

CONTRIBUTING.rst

@@ -1,17 +1,23 @@
 Development Notes
 ==================
 
-The Pelican blog article template is used to generate simple pages.
-This is done since we don't care about the blog part but don't want to create
-'content/pages' folder in order to automatically generate all pages...
-and also have 'pages/*' URLs.
+The pages are published using the Read The Docs online service.
 
-Run ``paver deps`` then ``paver run`` to build the project locally on
-``http://localhost:8080``
+Any changed pushed to master is automatically published online.
 
-Continuously update content with ``paver dev``.
+There is paver file to help running a few local tasks.
 
-Publish changes from current branch with ``paver publish``.
+To initiate the dev environment::
+
+    ./paver.sh deps
+
+To generate the page on your local system::
+
+    ./paver.sh generate
+
+To run a few tests::
+
+    ./paver.sh test
 
 
 Onboarding Notes
@@ -25,13 +31,13 @@ Below is a guide that you can follow to make changes to this repo:
 Create a new branch and check out to that branch so that you are working on
 your own branch and not the master branch.
 
-``git checkout -b styleguide-improvements`` with
-``styleguide-improvements`` as an example branch name.
+``git checkout -b geck-improvements`` with
+``geck-improvements`` as an example branch name.
 
 If there is a Trac ticket/ GitHub issue involved, add the ID at the
 beginning of the branch name::
 
-    1234-styleguide-improvements
+    1234-geck-improvements
 
 Once all changes are made, git push your changes out to your git branch
 (not the `master` branch) and create the first Pull Request.

docs/office/leave.rst

@@ -1,5 +1,5 @@
-Leave / Holiday
-###############
+Leave / Holiday/ Team building
+##############################
 
 .. contents::
 
@@ -74,3 +74,25 @@ Unused leaves
   up to a total of 5 days.
   Try to plan your time so that you don't end up
   with these remaining days in the first place.
+
+
+In-Person Team Building Meeting
+===============================
+
+In person interaction is important for any team.
+As all team members are working from different places and do not
+get the chance to have the coffee chit chat or the idle work breaks, 
+we try to get the team together at least once a year.
+Usually it's for a week, each time in a different location.
+
+During the team building meeting, work sessions are alternated with
+hangouts to get to know each other.
+
+
+Daily allowence
+===============
+
+While travel and accomodation expenses are covered by the
+company, a daily allowance is to be paid for each employee.
+
+Currently, the per diem is 10 euros.

docs/office/onboarding.rst

@@ -32,9 +32,9 @@ To practice your GitHub issue management skills, create your milestone as 'YOUR-
 
 Below is a list of initial issues/tasks to be added in the milestone:
 
-**Review and provide feedback for chevah/styleguide**
+**Review and provide feedback for chevah/geck**
 
-- The styleguide is at http://styleguide.chevah.com/
+- geck is at http://geck.chevah.com/
 
 - Comments/suggestions can be added in the ticket.
 
@@ -44,7 +44,7 @@ When submitting repo changes based on your feedback:
 
 - Create pull requests (PRs) with these changes. 
 
-- Use the `Github PR template <https://github.com/chevah/styleguide/blob/463556d4e9219e28fd030759ba7af9c0a3ec89e6/.github/PULL_REQUEST_TEMPLATE>`_ and @ mention the oboarding supervisor for review.
+- Use the `Github PR template <https://github.com/chevah/geck/blob/463556d4e9219e28fd030759ba7af9c0a3ec89e6/.github/PULL_REQUEST_TEMPLATE>`_ and @ mention the oboarding supervisor for review.
 
 **Review and provide feedback for the software**
 
@@ -83,25 +83,25 @@ For any of the tasks above, feel free to check existing or previous milestones f
 We have basic requirements and practices when working for the Chevah project.
 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). 
+* Take note of the `coding conventions <http://geck.chevah.com/>`_ applied for this project. These general coding conventions are for all 'texts' (code, documentation, etc). 
 
 * There are specific rules that apply to programming languages.
-  Begin by reading the general `coding conventions <http://styleguide.chevah.com>`_.
+  Begin by reading the general `styleguide <http://geck.chevah.com/en/latest/styleguide/index.html>`_.
   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.
+  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>`_. 
+  If there is no ticket, create one and start the `Ticket Work Flow <http://geck.chevah.com/en/latest/product/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>`_.
+  See `Overview of the GitHub and Trac integration <http://geck.chevah.com/en/latest/programming/review.html>`_.
 
 * Tickets corresponding to you that you are currently working should have the 'owner' value set to your Trac username.
 
@@ -111,15 +111,10 @@ See `Overview of the GitHub and Trac integration <http://styleguide.chevah.com/r
 
 * 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 approved by at least one other team member.
+  Further info of the `Review process <http://geck.chevah.com/en/latest/programming/review.html>`_.
 
 * Leave days can be requested at any time.
   Check the dedicated page in Trac.
@@ -156,9 +151,8 @@ Use the dedicated Skype account as the official tools to collaborate with the te
 * 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.
+
+* Get to know the team by checking the dedicated page in our private wiki.
 
 
 4. Exploring SFTPPlus for the first time

docs/office/work.rst

@@ -218,13 +218,16 @@ Tools
 
 Make sure all development tools are on your laptop.
 
-Buy a good headset and microphone.
-
 "Verba volant, scripta manent" (from the latin: 'spoken words fly away, written words remain')
 As the main communication is done using text, you can keep track of all past conversations. 
 Configure your instant messaging client to keep logs of all previous conversations, 
 and archive your emails instead of deleting them.
 
+Buy a good headset and microphone.
+
+Any expenses required for acquiring work related equipment (like laptop, peripherals,
+desk, etc) will be covered by the company.
+
 
 References
 ==========

docs/product/release.rst

@@ -70,42 +70,54 @@ driving the release, and that person will be the **release manager**.
 
 Some functions of the **release manager** are:
 
-* Defining the milestone description and due date
 * About 1 week before the release, creating a release milestone and moving all
   closed tickets from the 'next-release' milestone to the new release milestone.
+* Defining the milestone title (PRODUCT_NAME-MAJOR.MINOR.0), description and
+  due date.
 * Creating a dedicated ticket for the release itself, and associating it
   to the new release milestone.
 * Making sure the ticket dedicated to the release has an owner, and that the
   owner will do the required steps.
 * Organizing: Some tickets from the `next-release` milestone which are not yet 
   closed but are soon to be (like needs_merge) can also be moved to the new
   release milestone.
+* Coordinating story tickets for the milestone.
+* After sending the release branch to RQM, check that the Downloads page is updated
+  and that the trial download links (only direct links) are updated.
+* Check the documentation pages if there are formatting issues, missing images, etc.
+* When creating the release PR add the release news, staging links, direct links to
+  the trial versions, description of what the review and the reviewer names.
+* Check that a tag is created for the release, and that the tag points to the
+  release branch and not the release merge.
 * Checking post-commit BuildBot results for the master branch (about once per week) 
   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.
+* When sending branch to production via RQM, edit the protected branch status so that
+  codecov is not required.  After release, edit the branch status so that codecov
+  is back to being required.
 * 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.
+  with the master branch via RQM.
+* Update the website with the release news and send to production.
+* Creates and sends the newsletter to the relevant list/s.
+* Ensure that customers that are awaiting for the release. Support will know who
+  the customers are. The ticket can also reference which customer it is.
 
 Release Manager should look into obtaining access to the following:
 
 * 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 Mailchimp "Pro:Atria" account 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.
 Release meeting notes are `located here <https://drive.google.com/drive/u/3/folders/0BwQo7116Iy2tZ2M2bDhadFV4R0E>`_
-
+Use the version from the previous meeting, in case there were changes in the agenda document such as different numbers.
 
 The Release Branch
 ==================
@@ -115,6 +127,21 @@ A release branch starts like any other branch by creating a ticket in Trac.
 The release branch should be created from master (for latest release) or
 from a tag (for a maintenance release).
 
+Once a release is cut and the release branch is created, it should not be
+merged with master.
+
+The release branch can cherry-pick certain changes which were added to the
+release on an expectional basis.
+
+Merging with master might accidentally include changes which should not be
+released or which might need a new re-release and testing phase.
+By the time the new re-release is done there might be another new change in
+master, which if merged will trigger a new circle, and we will never do the
+release.
+
+With this approach, once the release is cut, the development can continue in
+master without having to worry about the release.
+
 To integrate with our automated process, the release branch should be named:
 `TICKET_ID-release-MAJOR.MINOR.BUGFIX`.
 

docs/programming/review.rst

@@ -120,7 +120,7 @@ For the person requesting a review
 
 * Before submitting a ticket for review, check that you have documented your
   work accordingly, for example in the affected repository documentation,
-  the ticketing system, or the Styleguide.
+  the ticketing system, or geck.
 
 * When submitting a review for changes not planned in the current milestone,
   update the milestone to the current one.
@@ -138,6 +138,9 @@ For the person requesting a review
   It will trigger the review request process and the GitHub to Trac
   synchronization.
 
+* Once the **needs-review** marker is set for a PR, no more updates should be
+  commited until a full cycle of the review process has ended.
+
 * GitHub inline comments are great, and you can add them to help with the
   initial review request.
   Just **don't abuse them**!
@@ -182,7 +185,7 @@ Review request message
 
 When submitting a ticket for review, the review request should contain the
 following message as described in `pull request template
-<https://github.com/chevah/styleguide/blob/master/.github/PULL_REQUEST_TEMPLATE>`_:
+<https://github.com/chevah/geck/blob/master/.github/PULL_REQUEST_TEMPLATE>`_:
 
 The PR title should be the merge commit message.
 The message should include the ticket ID number.
@@ -214,7 +217,7 @@ PR title as the commit message with the PR ID appended to it.
 
 If the PR title is `[#1234] What was done in this branch` the commit message
 will be `[#1234] What was done in this branch. (#4567)`
-Where 1234 is the Trac ticket id and 4567 is the GitHub PR id::
+Where 1234 is the Trac ticket id and 4567 is the GitHub PR id.
 
 When doing manual merge using git, use squash merge and don't use the
 default commit message.
@@ -294,7 +297,7 @@ Reviewer's check list - Any Role
 Reviewer's check list - Developer
 ---------------------------------
 
-* Do the **new** changes comply with latest styleguide?
+* Do the **new** changes comply with geck?
 
 * Does the code have automated tests for all the new code?