The following describes how to go about publishing and editing content at Fleet.
- Instant: Content is published instantly. Content is approved by Digital Experience post-facto – see links in the table below to get the required training.
- Gated: Submit content to Digital Experience for review – see specific instructions in the table below.
- Queued: Communicate the publication date with the DRI responsible for approving this content – refer to specific instructions linked in the table below.
- Absorb: Fix and publish yourself
- Feedback: Request changes and wait
- Pairing: Jump on Zoom to finalize with the original contributor.
Consider: Absorb may be risky depending on how sure the editor is about their edits. Feedback can be forgotten. Pairing is underused but can eat up more time if not careful.
Detail the minimum time needed for new or updated content to be live (published) and brand-approved (reviewed and revised, if necessary).
|Content||To publish||To revise (for editors)||Timeframe|
|Articles||Queued – see How to submit and publish an article.||Absorb (pair or feedback as needed) – see How to edit articles, release posts, and press releases.||three business days|
|Ads||Gated. Request review from Digital Experience – see (TODO: Creating an ad campaign).||Feedback or pair||five business days|
|Docs||Gated. Request review from Chris McGillicuddy – see (TODO: Adding to the docs).||Absorb – see How to edit Markdown pull requests for the docs. For non-grammar-related revisions: Feedback or pair with contributor, and request review from the on-call engineer.||two business days|
|Docs (REST API)||Gated. Request review from Luke Heath – see (TODO: Adding to the docs (REST API)).||Absorb – see How to edit recently merged Pull Requests for the handbook and docs. For non-grammar-related revisions: Feedback or pair with contributor, and request review from Luke Heath.||two business days|
|Handbook||Gated. Request review from page DRI – see (TODO: Adding to the handbook).||Absorb and request review from page DRI – see How to edit recently merged Pull Requests for the handbook and docs.||two business days|
|Social media (Twitter, FB, LinkedIn.)||Instant – see Posting on social media as Fleet.||Pair or absorb (pair if possible otherwise, silently fix ASAP by editing or deleting the post. Consider that some or many people may have already seen the post, and decide accordingly – see How to edit social media posts.)||one business day|
|Newsletter/email blast||Gated. Request review from Digital Experience – see (TODO: Creating an email campaign).||Feedback or pair||five business days|
|Press release||Queued – see (TODO: Publishing a press release)||Feedback or pair – see How to edit articles, release posts, and press releases||three business days|
|Release post||Queued – see (TODO: Publishing release posts)||Feedback or pair – see How to edit articles, release posts, and press releases||three business days|
|Website (text change)||Gated – see (TODO: Adding content to fleetdm.com).||Feedback or pair||three business days|
|YouTube||Queued – see (TODO: Publishing on YouTube as Fleet.)||Absorb for revisions to the description. Pair or absorb for video content (pair if possible otherwise, silently fix ASAP by deleting the post. Consider that the video may also have been promoted on social media – see Social media (Twitter, FB, LinkedIn) above.||three business days|
Sound positive and assume positive intent. A positive tone helps to empower our users and encourages them to succeed with Fleet.
Be relatable, friendly, and sincere. Being relatable reminds our users that they're talking to another human that cares. Use simple words and sentences, especially in technical conversations.
Project confidence and be informative. Clearly tell users what they need to know, remembering always to stay positive so as NOT to sound overconfident.
Manage risk, not fear. Educate users about security threats positively. Risk management is wise, but focusing on fear can lead to poor decisions. We NEVER use fear as a communication and marketing tactic.
Consider the meaning of words. We never want to offend people or sound judgemental. Industry jargon that was once commonly used may now be considered offensive and should be avoided.
At Fleet, our voice and tone should be clear, simple, friendly, and inspiring, like Mr. Rogers, who deeply understood these communication values.
Consider the example tweets below. What would Mr. Rogers say?
- Distributed workforces aren’t going anywhere anytime soon. It’s past time to start engaging meaningfully with your workforce and getting them to work with your security team instead of around them.
- Distributed workforces aren’t going anywhere anytime soon, so it’s a great time to engage with your crew and help them work with your security team instead of around them.
By Mr. Rogersing our writing, we can emphasize positivity, optimism, and encourage our readers to succeed. The example above also considers sentence flow and the use of synonyms to reduce repetition.
Another example to consider is industry jargon that may now be inappropriate. While the term "responsible vulnerability disclosure" has been used for decades, it supposes that people who use a different process are irresponsible. Using coordinated disclosure is a more positive way to discuss the issue.
Writing at Fleet shares the same principles as Communicating as Fleet. Every piece of content we write should be consistent with our company and brand values. To help succeed, we encourage our writers to apply a design thinking approach to their writing by following these principles:
- Empathize - Who is the reader? Why will they read it? What do they hope to get from it?
- Define - What is the subject? What action do you want from the reader?
- Ideate and collaborate - Create an outline of what you plan to write. Interview team members or friends of Fleet to help you.
- Prototype - Write a draft and see how it goes. Draft quickly, iterate, and don't be scared to throw it out if it's not working.
- Test - Revise, edit, proofread, repeat. Revise, edit, proofread, repeat. Revise, edit... Ok, you get the idea 😵💫
Jokes above aside, testing is an integral part of the design thinking approach to writing. It ties in with the spirit of our company value, Ownership. Part of that value is to move quickly and help unblock our team members and contributors to deliver value. When writing at Fleet, our writers need to take ownership of editing and self-check their work before publishing or submitting pull requests. Having an obsession with details is helpful. So is Grammarly, to which all writers and editors (yes, we do have editors, more on them later) have access. Let's take a look at that now.
All of our writers and editors have access to Grammarly, which comes with a handy set of tools, including:
- Style guide, which helps us write consistently in the style of Fleet.
- Brand tones to keep the tone of our messaging consistent with just the right amount of confidence, optimism, and joy.
- Snippets to turn commonly used phrases, sentences, and paragraphs (such as calls to action, thank you messages, etc.) into consistent, reusable snippets to save time.
Our favorite Grammarly feature is the tone detector. It's excellent for keeping messaging on-brand and helps alleviate the doubt that often comes along for the ride during a writing assignment. Take a look at their video that sums it up better than this.
Bullet point lists are a clean and simple way to present information. But sticking to consistent rules for punctuation and capitalization can be tough. Here we lay out the dos and don’ts for writing consistent bullet points.
Do use a colon if you introduce a list with a complete sentence.
We follow the guiding principles below to secure our company-owned devices:
- Our devices should give contributors the freedom to work from anywhere.
- To allow maximum freedom in where and how we work, we assume that "Safe" networks do not exist. Contributors should be able to work on a coffee shop's Wi-Fi as if it were their home or work network.
- By using techniques such as Two-Factor Authentication (2FA), code reviews, and more, we can further empower contributors to work comfortably from any location - on any network.
Do not use a colon when combining the introduction and list items to make a complete sentence. (This is called a “fascination” and is a technique used to create engaging lists.)
This week at Fleet, we
- published new security policies.
- launched Jira and Zendesk integrations.
- drafted improvements to vulnerable software.
Note: You do not need to capitalize bullets when combining the introduction and list items to make a complete sentence.
Do not use a colon if you start a list straight after a heading.
Communicating as Fleet
- Sound positive and assume positive intent. A positive tone helps to empower our users and encourages them to succeed with Fleet.
- Be relatable, friendly, and sincere. Being relatable reminds our users that they're talking to another human that cares. Use simple words and sentences, especially in technical conversations.
Do use terminal punctuation if your bullet points are complete sentences.
- Project confidence and be informative. Clearly tell users what they need to know, remembering always to stay positive.
- Manage risk, not fear. Educate users about security threats positively. Risk management is wise, but focusing on fear can lead to poor decisions. We never use fear as a communication and marketing tactic.
Do not use terminal punctuation if your bullet points are sentence fragments, single words, or short phrases.
- Multiple teams
- Enterprise support
- Self-hosted agent auto-updates
Note: Remember to be consistent with your lists. Do not mix complete sentences with sentence fragments, single words, or short phrases.
No. For consistency, we choose not to. Although not grammatically incorrect, it’s becoming increasingly uncommon to separate list items with semicolons or commas.
Do use a capital letter when your bullet points are complete sentences.
Do not use a capital letter when your bullet points are sentence fragments, single words, or short phrases.
Do not use a capital letter when combining the introduction and bullet points to make a complete sentence (AKA a “fascination”).
When listing three or more things, use commas to separate the words.
Do: Fleet is for IT professionals, Client Platform Engineers, and security practitioners.
Don’t: Fleet is for IT professionals, Client platform Engineers and security practitioners.
The above example lists three of Fleet’s users. Omitting the serial comma redefines the meaning, making Client Platform Engineers and security practitioners the IT professionals who use Fleet.
Aside from the serial comma, use commas, as usual, to break up your sentences. If you’re unsure where saying the sentence aloud can give you a clue. If you pause or take a breath, a comma is likely needed at those moments.
Use a hyphen to link words that function as an adjective to modify a noun or to indicate a range:
- We release Fleet on a three-week cadence.
A hyphen is unnecessary when not modifying a noun:
- The Fleet product is released every three weeks.
- How to make edits with GitHub
- How to edit recently merged pull requests for the handbook
- How to edit Markdown pull requests for the docs
- How to edit articles, release posts, and press releases
- How to edit social media posts
While we encourage and equip our writers to succeed by themselves in editing quests, tpyos are inevitable. Here's where the Fleet editor steps in.
The following is our handy guide to editor bliss at Fleet, but first, let's start by listing common content types that require an editor pass.
- Docs and Handbook pages.
- Articles, release posts, and press releases.
- Social media posts.
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.
- Click the "Edit page" button from the relevant handbook or docs page on fleetdm.com (this will take you to the GitHub editor).
- Make your suggested edits in the GitHub editor.
- From the Propose changes dialog, at the bottom of the page, give your proposed edit a title and optional description (these help page maintainers quickly understand the proposed changes).
- Hit Propose change which will open a new pull request (PR).
- Request a review from the page maintainer, and finally, press “Create pull request.”
- 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.
Keep PR titles short and clear. E.g., "Edit to handbook Product group"
Check the “Files changed” section on the Open a pull request page to double-check your proposed changes.
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:
Note: Contributors are not required to request reviews from editors for handbook changes.
- Check that the previous day's edits are formatted correctly on the website (more on this in the note below.)
- Use the Handbook history feed in GitHub to see a list of changes made to the handbook.
- 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 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.
- 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.
- 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."
- Watch this short video 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.
- When someone creates a pull request for a doc that affects Markdown files, they’ll need to request a review from the editor.
- If no edits are needed, the editor will merge the PR.
- If an edit changes the meaning, or if unsure, the editor should request a review from the on-call engineer and remove themselves as a reviewer.
Editing articles, release posts, and press releases usually comes in three flavors: a Google Docs draft, a new pull request, or an edit to an existing article.
For unpublished articles, please read the review process in How to submit and publish an article.
To edit an existing article, see How to make edits with GitHub.
In the world of the Fleet editor, there are two types of social media posts; those scheduled to be published and those published already.
Refer to Posting on social media as Fleet for details on editing draft social media posts.
Making edits to published social media posts gets a little tricky. Twitter, for example, doesn't allow editing of tweets, so the only way to make an edit is to remove the tweet and post it again.
- Post the tweet in the #g-growth Slack channel and tag the Digital Experience lead.
- Decide whether to remove the tweet. There's a tradeoff between us striving for perfection vs. losing the engagements that the tweet may have already generated.
- Suggest edits in the Slack thread for the Growth team to include and re-post.
When talking about Fleet the company, we stylize our name as either "Fleet" or "Fleet Device Management." For Fleet the product, we say either “Fleet” or “Fleet for osquery.”
Fleet uses sentence case capitalization for all headings across Fleet EE, fleetdm.com, our documentation, and our social media channels. In sentence case, we write titles as if they were sentences. For example:
- Ask questions about your servers, containers, and laptops running Linux, Windows, and macOS.
As we use sentence case, only the first word of a heading and subheading is capitalized. However, if a word would normally be capitalized in the sentence (e.g., a proper noun) it should remain capitalized in the heading.
Note the capitalization of “macOS” in the example above. Although this is a proper noun, macOS uses its own style guide from Apple, to which we adhere.
Osquery should always be written in lowercase unless used to start a sentence or heading. For example:
- Open source software, built on osquery.
- Osquery and Fleet provide structured, convenient access to information about your devices.
When deciding whether to describe Fleet as open source or open core, define who you are talking to first. e.g.;
- If talking to users, use "open source."
- If talking to enterprise customers or media outlets, e.g., Hacker News, use "open core."
For simplicity and to avoid conflicts with other uses of the word "core" (such as "core product" or "core team"), Fleet is always described as simply "open source" in all writing and verbal communication. In specific situations, e.g., discussing the distinction between various kinds of open source, it can be appropriate to mention "open core" to clarify your meaning. If ever in doubt, go with "open source."
If you find yourself feeling a little overwhelmed by all the industry terms within our space, or if you just need to look something up, our glossary of commonly used terms is here to help.
To download official Fleet logos, product screenshots, and wallpapers, head over to our brand resources page.
See also https://fleetdm.com/handbook/community#press-releases for our press-release boilerplate.
Do you need to send out a branded email blast to multiple recipients?
Use "bcc" so recipients don't see each other's email addresses and send an email manually using Gmail. (Good for small lists. This is definitely a "thing that doesn't scale.")
First, design the email and content. The preferred method is to base the design on one of our existing email templates in Figma. If your Figma boots aren't comfortable (or you don't have edit access), your design could be a Google Drawing, Doc, or just a sketch on paper in a pinch.
Bring your request to the digital experience team by posting it in their primary Slack channel, along with your urgency/timeline. The digital experience team will finalize the design and language for consistency, then fork and customize one of the existing email templates for you, and write a script to deliver it to your desired recipients. Then, digital experience will merge that, test it by hand to make sure it's attractive and links work, and then tell you how to run the script with e.g.;
We use Figma for most of our design work. This includes the Fleet product, our website, and our marketing collateral.
Fleet website. All website design work is done in the fleetdm.com (current, dev-ready) Figma file.
Design system. Shared logos, typography styles, and UI components can be found in Design system.
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.
Looking for the official Fleet logo? Download it from: https://fleetdm.com/logos.
The Digital Experience team is responsible for production and maintenance of the Fleet website.
- Design reviews
- Estimation sessions
- When can I merge changes to the website?
- How to export images for the website
- Maintaining browser compatibility
- Responding to a 5xx error on fleetdm.com
- The "Deploy Fleet Website" GitHub action failed
- Vulnerability monitoring
- How to make usability changes to the website
Before committing anything to code, we create wireframes to illustrate all changes that affect the website layout and structure.
See Why do we use a wireframe first approach for more information.
We hold regular design review sessions to evaluate, revise, and approve wireframes before moving into production.
Design review sessions are hosted by Mike Thomas and typically take place daily, late afternoon (CST). Anyone is welcome to join.
We use estimation sessions to estimate the effort required to complete a prioritized task.
Through these sessions, we can:
- Confirm that wireframes are complete before moving to production
- Consider all edge cases and requirements that may have been with during wireframing.
- Avoid having the engineer make choices for “unknowns” during production.
- More accurately plan and prioritize upcoming tasks.
Story points represent the effort required to complete a task. After accessing wireframes, we typically play planning poker, a gamified estimation technique, to determine the necessary story point value.
We use the following story points to estimate website tasks:
|1||1 to 2 hours|
|2||2 to 4 hours|
|5||1 to 2 days|
|8||Up to a week|
|13||1 to 2 weeks|
When merging a PR to master, remember that whatever you merge to master gets deployed live immediately. So if the PR's changes contain anything that you don't think is appropriate to be seen publicly by all guests of fleetdm.com, please do not merge.
Merge a PR (aka deploy the website) when you think it is appropriately clean to represent our brand. When in doubt, use the standards and quality seen on existing pages, ensure correct functionality, and check responsive behavior - starting widescreen and resizing down to ≈320px width.
- Select the layers you want to export.
- Confirm export settings and naming convention:
- Item name - color variant - (CSS)size - @2x.fileformat (e.g.,
- Note that the dimensions in the filename are in CSS pixels. In this example, if you opened it in preview, the image would actually have dimensions of 32x32px but in the filename, and in HTML/CSS, we'll size it as if it were 16x16. This is so that we support retina displays by default.
- File extension might be .jpg or .png.
- Avoid using SVGs or icon fonts.
- Click the Export button.
- We use BrowserStack (logins can be found in 1Password) for our cross-browser checks.
- Check for issues against the latest version of Google Chrome (macOS). We use this as our baseline for quality assurance.
- Document any issues in GitHub as a bug report, and assign them for fixing.
- If in doubt about anything regarding design or layout, please reach out to the Design team.
Production systems can fail for various reasons, and it can be frustrating to users when they do, and customer experience is significant to Fleet. In the event of system failure, Fleet will:
- investigate the problem to determine the root cause.
- identify affected users.
- escalate if necessary.
- understand and remediate the problem.
- notify impacted users of any steps they need to take (if any). If a customer paid with a credit card and had a bad experience, default to refunding their money.
- Conduct an incident post-mortem to determine any additional steps we need (including monitoring) to take to prevent this class of problems from happening in the future.
When conducting an incident post-mortem, answer the following three questions:
- Impact: What impact did this error have? How many humans experienced this error, if any, and who were they?
- Root Cause: Why did this error happen?
- Side effects: did this error have any side effects? e.g., did it corrupt any data? Did code that was supposed to run afterward and “finish something up” not run, and did it leave anything in the database or other systems in a broken state requiring repair? This typically involves checking the line in the source code that threw the error.
If the action fails, please complete the following steps:
- Head to the fleetdm-website app in the Heroku dashboard and select the "Activity" tab.
- Select "Roll back to here" on the second to most recent deploy.
- Head to the fleetdm/fleet GitHub repository and re-run the Deploy Fleet Website action.
Every week, we run
npm audit --only=prod to check for vulnerabilities on the production dependencies of fleetdm.com. Once we have a solution to configure GitHub's Dependabot to ignore devDependencies, this manual process can be replaced with Dependabot.
We want to make it easy to learn how to manage devices with Fleet. Anyone inside or outside the company can suggest changes to the website to improve ease of use and clarity.
To propose changes:
- Decide what you want to change. A small change is the best place to start.
- Wireframe the design. Usually, digital experience does this, but anyone can contribute.
- Present your change to the website DRI. They will approve it or suggest revisions.
- Code the website change. Again, digital experience often does this, but anyone can help.
- Measure if the change made it easier to use. This can be tricky, but the growth team will have ideas on how to do this.
The following table lists the Brand group's rituals, frequency, and Directly Responsible Individual (DRI).
|Documentation quality||On request||Review pull requests to the docs for spelling, punctuation, and grammar.||Chris McGillicuddy|
|Handbook quality||Daily||Review pull requests to the handbook for spelling, punctuation, and grammar.||Chris McGillicuddy|
|Tweet review||Daily||Review tweets for tone and brand consistency.||Mike Thomas|
|Article review||Weekly||Review articles for tone and brand consistency.||Mike Thomas|
|Article graphic||Weekly||Create a graphic for the weekly article||Mike Thomas|
|Digital experience planning||Three weeks||Prioritize and assigns issues to relevant personnel based on current goals and quarterly OKRs||Mike Thomas|
|OKR review||Three weeks||Review the status of current OKRs.||Mike Thomas|
|Handbook editor pass||Monthly||Edit for copy and content.||Chris McGillicuddy|
|Browser compatibility check||Monthly||Check browser compatibility for the website||Eric Shaw|
|OKR planning||Quarterly||Plan next quarter's OKRs||Mike Thomas|
|Website vulnerability check||Weekly||Checking for vulnerabilities on fleetdm.com||Eric Shaw|
These groups maintain the following Slack channels: