refs #187: bulk changed toggl to float. There are some additional iss…

…ues to address.

content/guides/an-effective-onboarding-structure.md

@@ -21,7 +21,7 @@ Once they are fulfilled, the next step is to set the goals and schedule check-up
 
 * Clarify the workflow of our projects for the new employee
 * Present and clarify any doubts about the tools that allow access to this workflow (git, GitLab, our branching model, etc)
-* Clarify how we track time on Toggl and how we communicate on Slack
+* Clarify how we track time on Float and how we communicate on Slack
 * Test the employee declared skills and proficiency level
 
 **For the employee:**

content/procedures/employee-onboarding.md

@@ -56,7 +56,7 @@ The employee must, with the help of an HR representative:
 * If they are a developer, log into GCP using [this procedure](/guides/local-development-environment-configuration#log-into-gcloud)
 * Activate two-factor authentication on Gitlab
 * Generate an SSH key and add it among the available keys for their Gitlab account
-* Set their profile pictures (starting with Gravatar and checking on Gitlab, Slack, Toggl, etc) with an appropriate close-up
+* Set their profile pictures (starting with Gravatar and checking on Gitlab, Slack, Float, etc) with an appropriate close-up
 * Set their e-mail signature in [the official format](#standard-mail-signature-format) (respect bolds)
 * Set the [SparkFabrik branded LinkedIn banner](#branded-linkedin-banner) on the Linkedin profile
 
@@ -86,7 +86,7 @@ The Team Leader will also make sure that:
 
 * A call with the customer is planned to introduce the new colleague
 * The colleague can:
-  * See all relevant projects on Toggl and Float (if it applies)
+  * See all relevant projects on Float
   * Access all relevant projects on Gitlab, GitHub, or any other platform that may be relevant
   * Access all relevant slack channels (or other communication platforms) pertaining to relevant projects
   * Receive emails via relevant `-team@sparkfabrik.com` groups

content/tools-and-policies/management.md

@@ -9,7 +9,7 @@ Sort: 40
 
 - [Table of Content](#table-of-content)
 - [Redmine](#redmine)
-- [Toggl](#toggl)
+- [Float](#float)
 - [Slack](#slack)
 - [Gmail](#gmail)
 - [Hangout](#hangout)
@@ -21,7 +21,7 @@ Sort: 40
 
     @todo summarize what we use Redmine for and link specific articles and recipes to help people get the info they need
 
-## Toggl
+## Float
 
     @todo same as for Redmine
 

content/tools-and-policies/tasks-and-time-tracking.md

@@ -34,7 +34,7 @@ Credentials are needed to log into our tracker and work on projects.
 
 ### Tracking time
 
-We track time on [Toggl](https://toggl.com). Each member of SparkFabrik will be provided with a Toggl business account and will be able to track time on company projects and tasks.
+We track time on [Float](https://float.com). Each member of SparkFabrik will be provided with a Float business account and will be able to track time on company projects and tasks.
 
 There are rules to keep things consistent between the tools so that we can make something out of all these data.
 
@@ -61,9 +61,9 @@ As a general rule, all time entries must contain links to specific issue codes w
 > **Forenote**: Despite we try to group tiny activities to form a _3+ working days whole_, it happens that we must deliver very small tasks to our customers, such as one-shot security upgrades or very small changes to a living product.  
 > Such small, isolated activities, must be tracked under the [Support](#support) rolling task (see below).
 
-Each task approved by a customer/for a project is tracked on Toggl as a `Task` (heh!), with the format `[Task ID] Task Name`, where `Task ID` is an internal reference code, in the format `YYYYMM[DDII]` (where `DDII` is an optional part composed by two-digits day (`DD`) and a discriminant incremental), and `Task Name` is a mnemonic description such as `Website development`, `New media gallery`, `Q3 Maintenance` etc.
+Each task approved by a customer/for a project is tracked on Float as a `Task` (heh!), with the format `[Task ID] Task Name`, where `Task ID` is an internal reference code, in the format `YYYYMM[DDII]` (where `DDII` is an optional part composed by two-digits day (`DD`) and a discriminant incremental), and `Task Name` is a mnemonic description such as `Website development`, `New media gallery`, `Q3 Maintenance` etc.
 
-Approved tasks have a time budget on Toggl and the tracked time is counted against that time budget. Should a customer extend the budget, the task will be updated/extended or a new task will be created, depending on what makes more sense in the context.
+Approved tasks have a time budget on Float and the tracked time is counted against that time budget. Should a customer extend the budget, the task will be updated/extended or a new task will be created, depending on what makes more sense in the context.
 
 Project/Customer leads should take care of keeping things consistent in terms of issue tracking, using [Gitlab's Milestones](https://docs.gitlab.com/ee/user/project/milestones/). Create a milestone with the same name as the related task (`[Agreement Code] Task Name`) and add all issues related to this task there.