From 0620cdf06a548568699a30a115f286d9ad88b3cc Mon Sep 17 00:00:00 2001 From: Sampfluger88 <108141731+Sampfluger88@users.noreply.github.com> Date: Wed, 20 Sep 2023 00:37:32 -0500 Subject: [PATCH] Manage intake (#14016) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Added manage g-ceo intake to CEO page - Added ritual manage g-ceo intake - Add Manage intake to communications - Update "👑Crown jewels" to "🎐Why Fleet?" - Deleted extra space in why this way ... --- handbook/ceo.md | 6 +- handbook/company/ceo.rituals.yml | 7 + handbook/company/communications.md | 223 +++++++++++++++-------------- handbook/company/why-this-way.md | 14 -- 4 files changed, 126 insertions(+), 124 deletions(-) diff --git a/handbook/ceo.md b/handbook/ceo.md index d9c0ee09a9..20e60fd2fd 100644 --- a/handbook/ceo.md +++ b/handbook/ceo.md @@ -102,10 +102,12 @@ When the final signature is added to an envelope in DocuSign, it is marked as co ``` - - ## Responsibilities +### Manage g-ceo intake +The Apprentice to the CEO is the DRI for the [#g-ceo kanban board](https://app.zenhub.com/workspaces/g-ceo-645b0eab68a4d40c0795ff61/board?sprints=none) and responsible for [managing all intake](https://fleetdm.com/handbook/company/communications#manage-intake) including issues and PRs. + + ### Schedule CEO interview From time to time, you will need to schedule an interview between a candidate and the CEO: 1. [Make a copy of the "¶¶ CEO interview template"](https://docs.google.com/document/d/1yARlH6iZY-cP9cQbmL3z6TbMy-Ii7lO64RbuolpWQzI/copy) (private Google doc) diff --git a/handbook/company/ceo.rituals.yml b/handbook/company/ceo.rituals.yml index 749f826150..90cd790ab8 100644 --- a/handbook/company/ceo.rituals.yml +++ b/handbook/company/ceo.rituals.yml @@ -18,6 +18,13 @@ description: "Process the CEO's inbox" moreInfoUrl: "https://fleetdm.com/handbook/company/ceo#process-the-ceos-email" dri: "sampfluger88" +- + task: "Manage g-ceo intake" + startedOn: "2023-07-29" + frequency: "Daily ⏰" + description: "Process the CEO's inbox" + moreInfoUrl: "https://fleetdm.com/handbook/company/communications#manage-intake" + dri: "sampfluger88" - task: "Process the CEO's calendar" startedOn: "2023-07-29" diff --git a/handbook/company/communications.md b/handbook/company/communications.md index 2671202d25..fef66ef139 100644 --- a/handbook/company/communications.md +++ b/handbook/company/communications.md @@ -5,7 +5,7 @@ This page covers the things every team member needs to know to effectively contr ## Strategy -You can read about the company's positioning and product strategy in ["👑 Crown jewels" (private google doc)](https://docs.google.com/document/d/1E0VU4AcB6UTVRd4JKD45Saxh9Gz-mkO3LnGSTBDLEZo/edit#). +You can read about the company's positioning and product strategy in ["🎐 Why Fleet?" (private google doc)](https://docs.google.com/document/d/1E0VU4AcB6UTVRd4JKD45Saxh9Gz-mkO3LnGSTBDLEZo/edit#). To see the evolution over time or catch up with the latest happenings, review [decks](https://drive.google.com/drive/folders/1cw_lL3_Xu9ZOXKGPghh8F4tc0ND9kQeY) and [recordings](https://us-65885.app.gong.io/conversations?workspace-id=9148397688380544352&callSearch=%7B%22search%22%3A%7B%22type%22%3A%22And%22%2C%22filters%22%3A%5B%7B%22type%22%3A%22CallTitle%22%2C%22phrase%22%3A%22all%20hands%22%7D%5D%7D%7D) from recent company-wide ["All hands" meetings](https://fleetdm.com/handbook/business-operations#all-hands). @@ -69,16 +69,127 @@ We use these prefixes to organize the Fleet Slack: - In consideration of our team, Fleet avoids using global tags in channels (i.e. @here, @channel, etc.) (What about polls? Good question, Fleeties are asked to post their poll in the channel and @mention the teammates they would like to hear from.) +## Github +Fleet uses Github as the [source of truth](https://fleetdm.com/handbook/company/why-this-way#why-do-we-use-one-repo) for our product and documentation; a platfrom to allow community members to interact with Fleet, [contribute and provide feedback](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/Committing-Changes.md#committing-changes). + +### GitHub labels +We use special characters to define different types of GitHub labels. By combining labels, we +organize and categorize GitHub issues. This reduces the total number of labels required while +maintaining an expressive labeling system. For example, instead of a label called +`platform-dev-backend`, we use `#platform :dev ~backend`. + +| Special character | Label type | Examples | +|:------------------|:------------|:------------------------------------| +| `#` | Noun | `#g-marketing`, `#g-ceo`, `#agent` +| `:` | Verb | `:dev`, `:research`, `:design` +| `~` | Adjective | `~blocked`, `~frontend`, `~backend` + +### Manage intake +Team members [process their department's kanban boards](https://fleetdm.com/handbook/company/why-this-way#why-lean-software-development) daily, prioritizing all new intake within 24hrs from when it was submitted. + +To process intake team members will: +- Inspect each item in the "📨 New requests" column and understand the next steps needed to complete the task. +- Indicate to the requestor when they can expect the task to be completed by placing each item in the appropriate column (e.g. Not yet, Planned, In progress) and estimate if necessary. +- If the goal/user story is unclear, assign the issue to the requestor and at-mention them in an issue comment asking to clarify the intended action. +- If the task is to be backlogged (e.g. Not yet), place the issue in the "Not yet" column and at-mention the requestor in an issue comment. Explain why the task is unable to be prioritized and provide a tentative ETA on when the task will be completed. + + +### Making a pull request +Our handbook and docs pages are written in Markdown and are editable from our website (via GitHub). Follow the instructions below to propose an edit to the handbook or docs. +1. Click the _"Edit page"_ button from the relevant handbook or docs page on [fleetdm.com](https://www.fleetdm.com) (this will take you to the GitHub browser). +2. Make your suggested edits in the GitHub. +3. Click _"Commit changes...."_ +4. Give your proposed change a title or _["Commit message"](https://about.gitlab.com/topics/version-control/version-control-best-practices/#write-descriptive-commit-messages)_ and optional _"Extended description"_ (good commit messages help page maintainers quickly understand the proposed changes). + - **Note:** _Keep commit messages short and clear. (e.g. "Add DRI automation")_ +4. Click _"Propose changes"_ +5. Request a review from the page maintainer, and finally, press “Create pull request.” +6. GitHub will run a series of automated checks and notify the reviewer. At this point, you are done and can safely close the browser page at any time. +8. Check the “Files changed” section on the Open a pull request page to double-check your proposed changes. + +### Merging changes +When merging a PR to the master branch of the [Fleet repo](https://github.com/fleetdm/fleet), remember that whatever you merge gets deployed live immediately. Ensure that the appropriate quality checks have been completed before merging. [Learn about the website QA process](#quality). + +When merging changes to the [docs](https://fleetdm.com/docs), [handbook](https://fleetdm.com/handbook), and articles, make sure that the PR’s changes do not contain inappropriate content (goes without saying) or confidential information, and that the content represents our [brand](#brand) accordingly. When in doubt reach out to the product manager of the [website group](https://fleetdm.com/handbook/company/product-groups#website-group) in the [#g-website](https://fleetdm.slack.com/archives/C058S8PFSK0) channel on Slack. + +### Editing a merged pull requests +We approach editing retrospectively for pull requests (PRs) to handbook pages. Remember our goal above about moving quickly and reducing time to value for our contributors? We avoid the editor becoming a bottleneck for merging quickly by editing for typos and grammatical errors after-the-fact. Here's how to do it: + +1. Check that the previous day's edits are formatted correctly on the website (more on this in the note below.) +2. Use the [Handbook history](https://github.com/fleetdm/fleet/commits/main/handbook) feed in GitHub to see a list of changes made to the handbook. +3. From the list of recently merged PRs, look at the files changed for each and then: + - Scan for typos and grammatical errors. + - Check that the tone aligns with our [Communicating as Fleet](https://fleetdm.com/handbook/brand#communicating-as-fleet) guidelines and that Grammarly's tone detector is on-brand. + - Check that Markdown is formatted correctly. + - **Remember**, Do not make edits to this page. It's already merged. +4. Instead, navigate to the page in question on the website and submit a new PR to make edits - making sure to request a review from the maintainer of that page. +5. Comment on the original PR to keep track of your progress. Comments made will show up on the history feed. E.g., `"Edited, PR incoming"` or `"LGTM, no edits required."` +6. Watch [this short video](https://www.loom.com/share/95d4525a7aae482b9f9a9470d446ce9c) to see this process in action. + +> **Note:** The Fleet website may render Markdown differently from GitHub's rich text preview. It's essential to check that PRs merged by the editor are displaying as expected on the site. It can take a few minutes for merged PRs to appear on the live site, and therefore easy to move on and forget. It's good to start the ritual by looking at the site to check that the previous day's edits are displaying as they should. + + +### Linking to a location on GitHub +When adding a link to any text in the docs, handbook, or website always be sure to use the canonical form of the URL (e.g. _"https//www.fleetdm.com/ +handbook/..."_). +Navigate to the file's location on GitHub, and press "y" to transform the URL into its canonical form. + +#### Fixing a broken link +For instance when a broken link is discovered on fleetdm.com, always check if the link is a relative link to a location outside of `/docs`. + +An example of a link that lives outside of `/docs` is: + +``` +../../tools/app/prometheus +``` + +If the link lives outside `/docs`, head to the file's location (in this case, [https://github.com/fleetdm/fleet/blob/main/tools/app/prometheus.yml)](https://github.com/fleetdm/fleet/blob/main/tools/app/prometheus.yml)), and copy the full URL into its canonical form (a version of the link that will always point to the same location) ([https://github.com/fleetdm/fleet/blob/194ad5963b0d55bdf976aa93f3de6cabd590c97a/tools/app/prometheus.yml](https://github.com/fleetdm/fleet/blob/194ad5963b0d55bdf976aa93f3de6cabd590c97a/tools/app/prometheus.yml)). Replace the relative link with full URL. + + +### Meta tags + +#### Page order +The order we display documentation pages on fleetdm.com is determined by `pageOrderInSection` meta tags. These pages are sorted in their respective sections in **ascending** order by the `pageOrderInSection` value. Every Markdown file (except readme and faq pages) in the `docs/` folder must have a meta tag with a positive 'pageOrderInSection' value. + +We leave large gaps between values to make future changes easier. For example, the first page in the "Using Fleet" section of the docs has a `pageOrderInSection` value of 100, and the next page has a value of 200. The significant difference between values allows us to add, remove and reorder pages without changing the value of multiple pages at a time. + +When adding or reordering a page, try to leave as much room between values as possible. If you were adding a new page that would go between the two pages from the example above, you would add `` to the page. + +#### Page description +TODO: Document. + +### Images +Try to keep images in the docs at a minimum. Images can be a quick way to help users understand a concept or direct them towards a specific user interface(UI) element. Still, too many can make the documentation feel cluttered and more difficult to maintain. + +When adding images to the Fleet repo, follow these guidelines: + +- UI screenshots should be a 4:3 aspect ratio (1280x960). This is an optimal size for the container width of the docs and ensures that content in screenshots is as clear as possible to view in the docs (and especially on mobile devices). +- You can set up a custom preset in the Google Chrome device toolbar (in Developer Tools) to quickly adjust your browser to the correct size for taking a screenshot. +- Keep the images as simple as possible to maintain. Screenshots can get out of date quickly as UIs change. +- Exclude unnecessary images. Images should be used to help emphasize information in the docs, not replace it. +- Minimize images per doc page. For doc maintainers and users, more than one or two per page can get overwhelming. +- The goal is for the docs to look good on every form factor, from 320px window width all the way up to infinity. Full window screenshots and images with too much padding on the sides will be less than the width of the user's screen. When adding a large image, make sure it is easily readable at all widths. + +Images can be added to the docs using the Markdown image link format, e.g., `![Schedule Query Sidebar](https://raw.githubusercontent.com/fleetdm/fleet/main/docs/images/add-new-host-modal.png)` +The images used in the docs live in `docs/images/`. Note that you must provide the URL of the image in the Fleet GitHub repo for it to display properly on both GitHub and the Fleet website. + +> Note that the instructions above also apply to adding images in the Fleet handbook. + +### Audit logs +The [Audit logs doc page](https://fleetdm.com/docs/Using%20Fleet/Audit-logs.md) has a page generator that is used to speed up doc writing when Fleet adds new activity types. + +- If you're making a copy change to an exiting activity type, edit the `activities.go` file [here](https://github.com/fleetdm/fleet/blob/main/server/fleet/activities.go). +- If you're making a change to the top section or meta tags, edit the `gen_activity_doc.go` file [here](https://github.com/fleetdm/fleet/blob/main/server/fleet/gen_activity_doc.go). +- If you're adding a new activity type, add the activity to the `ActivityDetailsList` list in the `activities.go` file. + +After making your changes, save them and run `make generate-doc`. This will generate a new `Audit-logs.md` file. Make sure you run the command in the top level folder of your cloned, Fleet repo. + ## Figma We use Figma for virtually all our design work. This includes the Fleet product, our website, and our marketing collateral. - **Fleet product:** All product design work is done in the [Fleet product](https://www.figma.com/files/project/17318630/%F0%9F%94%9C%F0%9F%93%A6-Fleet-EE%C2%AE-(product)?fuid=1234929285759903870) Figma project. See [📖Product#Working with Figma](https://fleetdm.com/handbook/product#working-with-figma) for more details. - - **Fleet website:** All website design work is done in the [fleetdm.com (current, dev-ready)](https://www.figma.com/file/yLP0vJ8Ms4GbCoofLwptwS/%E2%9C%85-fleetdm.com-(current%2C-dev-ready)?node-id=794%3A373) Figma file. - - **Design system:** Shared logos, typography styles, and UI components can be found in [Design system](https://www.figma.com/files/project/15701210). - - **NOTE:** The Figma docs in Design System contain the master components that are referenced throughout all other Figma files. Use caution when modifying these components, as changes will be reflected in the master Fleet EE (scratchpad) and fleetdm.com (current, dev-ready) Figma docs. **Marketing assets:** Product screenshots and artwork for social media, articles, and other marketing assets can be found in [Collateral](https://www.figma.com/files/project/20798819). @@ -490,111 +601,7 @@ Older equipment results in lost productivity of Fleeties and should be considere > If your Apple device is less than 3 years old, has normal battery condition, but is experiencing operating difficulties, you should first contact Apple support and troubleshoot performance issues before requesting a new device. -## Github -### Making a pull request -Our handbook and docs pages are written in Markdown and are editable from our website (via GitHub). Follow the instructions below to propose an edit to the handbook or docs. -1. Click the _"Edit page"_ button from the relevant handbook or docs page on [fleetdm.com](https://www.fleetdm.com) (this will take you to the GitHub browser). -2. Make your suggested edits in the GitHub. -3. Click _"Commit changes...."_ -4. Give your proposed change a title or _["Commit message"](https://about.gitlab.com/topics/version-control/version-control-best-practices/#write-descriptive-commit-messages)_ and optional _"Extended description"_ (good commit messages help page maintainers quickly understand the proposed changes). - - **Note:** _Keep commit messages short and clear. (e.g. "Add DRI automation")_ -4. Click _"Propose changes"_ -5. Request a review from the page maintainer, and finally, press “Create pull request.” -6. GitHub will run a series of automated checks and notify the reviewer. At this point, you are done and can safely close the browser page at any time. -8. Check the “Files changed” section on the Open a pull request page to double-check your proposed changes. - -### Merging changes -When merging a PR to the master branch of the [Fleet repo](https://github.com/fleetdm/fleet), remember that whatever you merge gets deployed live immediately. Ensure that the appropriate quality checks have been completed before merging. [Learn about the website QA process](#quality). - -When merging changes to the [docs](https://fleetdm.com/docs), [handbook](https://fleetdm.com/handbook), and articles, make sure that the PR’s changes do not contain inappropriate content (goes without saying) or confidential information, and that the content represents our [brand](#brand) accordingly. When in doubt reach out to the product manager of the [website group](https://fleetdm.com/handbook/company/product-groups#website-group) in the [#g-website](https://fleetdm.slack.com/archives/C058S8PFSK0) channel on Slack. - -### Editing a merged pull requests -We approach editing retrospectively for pull requests (PRs) to handbook pages. Remember our goal above about moving quickly and reducing time to value for our contributors? We avoid the editor becoming a bottleneck for merging quickly by editing for typos and grammatical errors after-the-fact. Here's how to do it: - -1. Check that the previous day's edits are formatted correctly on the website (more on this in the note below.) -2. Use the [Handbook history](https://github.com/fleetdm/fleet/commits/main/handbook) feed in GitHub to see a list of changes made to the handbook. -3. From the list of recently merged PRs, look at the files changed for each and then: - - Scan for typos and grammatical errors. - - Check that the tone aligns with our [Communicating as Fleet](https://fleetdm.com/handbook/brand#communicating-as-fleet) guidelines and that Grammarly's tone detector is on-brand. - - Check that Markdown is formatted correctly. - - **Remember**, Do not make edits to this page. It's already merged. -4. Instead, navigate to the page in question on the website and submit a new PR to make edits - making sure to request a review from the maintainer of that page. -5. Comment on the original PR to keep track of your progress. Comments made will show up on the history feed. E.g., `"Edited, PR incoming"` or `"LGTM, no edits required."` -6. Watch [this short video](https://www.loom.com/share/95d4525a7aae482b9f9a9470d446ce9c) to see this process in action. - -> **Note:** The Fleet website may render Markdown differently from GitHub's rich text preview. It's essential to check that PRs merged by the editor are displaying as expected on the site. It can take a few minutes for merged PRs to appear on the live site, and therefore easy to move on and forget. It's good to start the ritual by looking at the site to check that the previous day's edits are displaying as they should. - - -### Linking to a location on GitHub -When adding a link to any text in the docs, handbook, or website always be sure to use the canonical form of the URL (e.g. _"https//www.fleetdm.com/handbook/..."_). - -Navigate to the file's location on GitHub, and press "y" to transform the URL into its canonical form. - -#### Fixing a broken link -For instance when a broken link is discovered on fleetdm.com, always check if the link is a relative link to a location outside of `/docs`. - -An example of a link that lives outside of `/docs` is: - -``` -../../tools/app/prometheus -``` - -If the link lives outside `/docs`, head to the file's location (in this case, [https://github.com/fleetdm/fleet/blob/main/tools/app/prometheus.yml)](https://github.com/fleetdm/fleet/blob/main/tools/app/prometheus.yml)), and copy the full URL into its canonical form (a version of the link that will always point to the same location) ([https://github.com/fleetdm/fleet/blob/194ad5963b0d55bdf976aa93f3de6cabd590c97a/tools/app/prometheus.yml](https://github.com/fleetdm/fleet/blob/194ad5963b0d55bdf976aa93f3de6cabd590c97a/tools/app/prometheus.yml)). Replace the relative link with full URL. - - -### Meta tags - -#### Page order -The order we display documentation pages on fleetdm.com is determined by `pageOrderInSection` meta tags. These pages are sorted in their respective sections in **ascending** order by the `pageOrderInSection` value. Every Markdown file (except readme and faq pages) in the `docs/` folder must have a meta tag with a positive 'pageOrderInSection' value. - -We leave large gaps between values to make future changes easier. For example, the first page in the "Using Fleet" section of the docs has a `pageOrderInSection` value of 100, and the next page has a value of 200. The significant difference between values allows us to add, remove and reorder pages without changing the value of multiple pages at a time. - -When adding or reordering a page, try to leave as much room between values as possible. If you were adding a new page that would go between the two pages from the example above, you would add `` to the page. - -#### Page description -TODO: Document. - -### Images -Try to keep images in the docs at a minimum. Images can be a quick way to help users understand a concept or direct them towards a specific user interface(UI) element. Still, too many can make the documentation feel cluttered and more difficult to maintain. - -When adding images to the Fleet repo, follow these guidelines: - -- UI screenshots should be a 4:3 aspect ratio (1280x960). This is an optimal size for the container width of the docs and ensures that content in screenshots is as clear as possible to view in the docs (and especially on mobile devices). -- You can set up a custom preset in the Google Chrome device toolbar (in Developer Tools) to quickly adjust your browser to the correct size for taking a screenshot. -- Keep the images as simple as possible to maintain. Screenshots can get out of date quickly as UIs change. -- Exclude unnecessary images. Images should be used to help emphasize information in the docs, not replace it. -- Minimize images per doc page. For doc maintainers and users, more than one or two per page can get overwhelming. -- The goal is for the docs to look good on every form factor, from 320px window width all the way up to infinity. Full window screenshots and images with too much padding on the sides will be less than the width of the user's screen. When adding a large image, make sure it is easily readable at all widths. - -Images can be added to the docs using the Markdown image link format, e.g., `![Schedule Query Sidebar](https://raw.githubusercontent.com/fleetdm/fleet/main/docs/images/add-new-host-modal.png)` -The images used in the docs live in `docs/images/`. Note that you must provide the URL of the image in the Fleet GitHub repo for it to display properly on both GitHub and the Fleet website. - -> Note that the instructions above also apply to adding images in the Fleet handbook. - -### Audit logs - -The [Audit logs doc page](https://fleetdm.com/docs/Using%20Fleet/Audit-logs.md) has a page generator that is used to speed up doc writing when Fleet adds new activity types. - -- If you're making a copy change to an exiting activity type, edit the `activities.go` file [here](https://github.com/fleetdm/fleet/blob/main/server/fleet/activities.go). - -- If you're making a change to the top section or meta tags, edit the `gen_activity_doc.go` file [here](https://github.com/fleetdm/fleet/blob/main/server/fleet/gen_activity_doc.go). - -- If you're adding a new activity type, add the activity to the `ActivityDetailsList` list in the `activities.go` file. - -After making your changes, save them and run `make generate-doc`. This will generate a new `Audit-logs.md` file. Make sure you run the command in the top level folder of your cloned, Fleet repo. - -### GitHub labels -We use special characters to define different types of GitHub labels. By combining labels, we -organize and categorize GitHub issues. This reduces the total number of labels required while -maintaining an expressive labeling system. For example, instead of a label called -`platform-dev-backend`, we use `#platform :dev ~backend`. - -| Special character | Label type | Examples | -|:------------------|:------------|:------------------------------------| -| `#` | Noun | `#platform`, `#interface`, `#agent` -| `:` | Verb | `:dev`, `:research`, `:design` -| `~` | Adjective | `~blocked`, `~frontend`, `~backend` ## Writing Learn how to communicate as Fleet with guidelines for tone of voice, our approach, grammar and mechanics, and more. diff --git a/handbook/company/why-this-way.md b/handbook/company/why-this-way.md index 8077d45e4a..962c707227 100644 --- a/handbook/company/why-this-way.md +++ b/handbook/company/why-this-way.md @@ -9,7 +9,6 @@ Any past decision is open to questioning in a future iteration, as long as you a Here are some of Fleet's decisions about the best way to work, and the reasoning for them. ## Why open source? - Fleet's source code, website, documentation, company handbook, and internal tools are [public](https://github.com/fleetdm/fleet) and accessible to everyone, including engineers, executives, and end users. (Even [paid features](https://fleetdm.com/pricing) are source-available.) Meanwhile, the [company behind Fleet](https://twitter.com/fleetctl) is built on the [open-core](https://www.heavybit.com/library/video/commercial-open-source-business-strategies) business model. Openness is one of our core [values](https://fleetdm.com/handbook/company#values), and everything we do is [public by default](https://handbook.gitlab.com/handbook/values/#public-by-default). Even the [company handbook](https://fleetdm.com/handbook) is open to the world. @@ -29,7 +28,6 @@ Here are some of the reasons we build in the open: ## Why handbook-first strategy? - The Fleet handbook provides team members with up-to-date information about how to do things in the company. At Fleet, we make changes to the handbook first. That means, before any change to how we run the business is "live" or "official", it is first changed in the relevant [handbook pages](https://fleetdm.com/handbook) and [issue templates](https://github.com/fleetdm/confidential/tree/main/.github/ISSUE_TEMPLATE). @@ -42,7 +40,6 @@ To contribute to the handbook, click "Edit this page" and make your [edits in Ma ## Why read documentation? - There are three reasons for visiting [the docs](https://fleetdm.com/docs): - **Tire-kicking**: "I think this is cool, now is it something that I could ACTUALLY use? Does it ACTUALLY work? What all's in it? What links can I share with my colleagues to help them see what I'm seeing?" - **Committed learning**: "I've decided to learn this. I need a curriculum to get me there; with content that makes it as easy as possible, surface-level as possible. I want to learn how Fleet works and how to do all the things." @@ -83,7 +80,6 @@ DRIs help us collaborate efficiently by knowing exactly who is responsible and c ## Why do we use a wireframe-first approach? - Wireframing (usually as part of what Fleet calls ["drafting"](https://fleetdm.com/handbook/company/development-groups#making-changes)) provides a clear overview of page layout, information architecture, user flow, and functionality. The [wireframe-first approach](https://speakerdeck.com/mikermcneil/i-love-apis?slide=28) extends beyond what users see on their screens. Wireframe-first is also excellent for drafting APIs, config settings, CLI options, and even business processes. It's design thinking, applied to software development. @@ -153,7 +149,6 @@ Every group at Fleet maintains their own Slack channel, which all group members ## Why make work visible? - Work is tracked in [GitHub issues](https://github.com/issues?q=archived%3Afalse+org%3Afleetdm+is%3Aissue+is%3Aopen+). Every department organizes their work into [team-based kanban boards](https://app.zenhub.com/workspaces/-g-business-operations-63f3dc3cc931f6247fcf55a9/board?sprints=none). This provides a consistent framework for how every team works, plans, and requests things from each other. @@ -208,7 +203,6 @@ The Fleet product is released every three weeks. By syncing the whole company to - Align project planning and milestones across all teams, which helps us schedule our content calendar and manage company-wide goals. ## Why spend so much energy responding to every potential production incident? - At Fleet, every 5xx response, timed-out request, and failed scheduled job is a P1 outage. As soon as the outage is detected in any production environment (including fleetdm.com, Fleet Sandbox, hosted customer environments, TUF, and others), we create an outage issue _immediately_: before we know for sure whether any real users are affected, and even before we know what the error message says. @@ -225,7 +219,6 @@ Why bother with all that? And why do it in this particular order? - **It helps us prevent future outages.** By finding outages sooner, we incentivize ourselves to fix the root cause sooner. And by fixing bugs sooner, we prevent them from stacking and bleeding into one another, and we prevent ourselves from implementing future fixes and improvements on top of shaky foundations. This makes contributions less risky and reduces the number of outages. ## Why make it obvious when stuff breaks? - At Fleet, we detect and fix bugs as quickly as possible. Breaking loudly means we can fix the break sooner and improve how fast and certain we are about making future changes. Especially in an all-remote environment, this provides contributors with discipline around quality and stability of the main branch. This is ["good annoying"](https://agilehope.blogspot.com/2014/12/diy-build-light-indicator.html). @@ -248,7 +241,6 @@ For example, here is the [philosophy behind Fleet's bug report template](https:/ ## Why spend less? - - **Default to efficiency. Reward richly.** At Fleet, we celebrate success and reward hard work. But we do everyday things cheap. And that is very important, because it shapes the kind of people we hire, and the kind of expectations we set for the team about what "comfortable" feels like. - **Offsites are not rewards.** Day to day, Fleet does not look rich. Rich !== welcoming. The company is open, not closed. Work here means flexible collaboration, accessible people, and clear expectations. And a rich, exciting future worth working for. Not a rich, complacent baseline worth coasting for. - **Minimally viable comfort.** We stay at La Quintas by the train tracks every single time unless customers are coming into the room and we need more space. Even then, we accommodate in the spirit of _hospitality_, not to show off how well Fleet is doing. They'll know how well we're doing by how great the product is, how great the support is, and [how that makes them feel](https://fleetdm.com/handbook/company#purpose). They'll remember openness, flexibility, accessibility, and clarity in all of their interactions with the brand. Not the view from our hotel rooms. @@ -256,7 +248,6 @@ For example, here is the [philosophy behind Fleet's bug report template](https:/ ## Why don't we sell like everyone else? - Many companies encourage salespeople to "spray and pray" email blasts, and to do whatever it takes to close deals. This can sometimes be temporarily effective. But Fleet takes a [🟠longer-term](https://fleetdm.com/handbook/company#ownership) approach: - **No spam.** Fleet is deliberate and thoughtful in the way we do outreach, whether that's for community-building, education, or [🧊 conversation-starting](https://github.com/fleetdm/confidential/blob/main/cold-outbound-strategy.md). - **Be a helper.** We focus on [🔴being helpers](https://fleetdm.com/handbook/company#empathy). Always be depositing value. This is how we create a virtuous cycle. (That doesn't mean sharing a random article; it means genuinely hearing, doing whatever it takes to fully understand, and offering only advice or links that we would actually want.) We are genuinely curious and desperate to help, because creating real value for people is the way we win. @@ -268,7 +259,6 @@ Many companies encourage salespeople to "spray and pray" email blasts, and to do ## Why don't we track leads differently? - There are about as many "MQL" definitions as there are sales orgs in the world. Exaggerating here, but only somewhat. Fleet documents all KPI's with clear definitions that are simple to evaluate, easy to track, and highly iterable. @@ -301,7 +291,6 @@ Fleet documents all KPI's with clear definitions that are simple to evaluate, ea ## Why does Fleet support query packs? - As originally envisioned by Zach Wasserman and the team when creating osquery, packs are a way to import and export queries into (and out of!) any platform that speaks osquery, whether that's Fleet, [Security Onion](https://securityonionsolutions.com/), an EDR, or even Rapid7. Queries [should be portable](https://github.com/fleetdm/fleet/blob/f711e60de47c69ab8be5bc13cf73fedf88adc338/README.md#lighter-than-air) to minimize lock-in to particular tools. The "Packs" section of the UI that began in `kolide/fleet` c. 2017 was an early attempt to segment and target formations of hosts that share certain characteristics. This came with some difficulties with debugging and collaboration, since it could be hard to tell which queries were running on which hosts. It also made it harder to understand what performance impact running all those queries might cause. @@ -313,7 +302,6 @@ The first step was to add a simpler way to schedule queries, and tuck away the l Packs will always be supported in Fleet. ## Why does Fleet use sentence case? - Fleet uses sentence case capitalization for all headings, subheadings, button text in the Fleet product, fleetdm.com, the documentation, the handbook, marketing material, direct emails, in Slack, and in every other conceivable situation. In sentence case, we write and capitalize words as if they were in sentences: @@ -325,7 +313,6 @@ As we use sentence case, only the first word is capitalized. But, if a word woul The reason for sentence case at Fleet is that everyone capitalizes differently in English, and capitalization conventions have not been taught very consistently in schools. Sentence case simplifies capitalization rules so that contributors can deliver more natural, even-looking content with a voice that feels similar no matter where you're reading it. ## Why not use superlatives? - A superlative is an adjective or adverb that expresses the degree of a quality, such as "best," "worst," or "most beautiful." A superlative is a judgment or evaluation, [which only the customer can decide](https://twitter.com/mikermcneil/status/1686837625187930112). @@ -344,7 +331,6 @@ Avoid using too many unnecessary words or superlatives, so your writing is short ## Why does Fleet use "MDM on/off" instead of "MDM enrolled/unenrolled"? - Fleet is more than an MDM (mobile device management) solution. With Fleet, you can secure and investigate Macs, Windows servers, Chromebooks, and more by installing the fleetd agent (or chrome extension for Chromebooks). When we use the word "enroll" in Fleet, we want this to mean anytime one of these hosts shows up in Fleet and the user can see that sweet telemetry.