fleet/handbook/brand.md

Brand

Publishing Fleet content

The following describes how to go about publishing and editing content at Fleet.

Publication methods

1. Instant: Content is published instantly. Content is approved by Digital Experience post-facto – see links in the table below to get the required training.
2. Gated: Submit content to Digital Experience for review – see specific instructions in the table below.
3. Queued: Communicate the publication date with the DRI responsible for approving this content – refer to specific instructions linked in the table below.

Revision methods (for editors)

1. Absorb: Fix and publish yourself
2. Feedback: Request changes and wait
3. 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.

Timeframe

Detail the minimum time needed for new or updated content to be live (published) and brand-approved (reviewed and revised, if necessary).

Content types

Content	To publish	To revise (for editors)	Timeframe
Articles	Queued – see (TODO: Publishing articles on fleetdm.com).	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 Desmi Dizney – 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

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.

• 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.

What would Mr. Rogers say?

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.

Becomes...

• 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

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 😵‍💫

Editing written content

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.

Grammarly

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.

Punctuating and capitalizing bullet points

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.

How to introduce a list/when to use a colon?

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.

Should I use terminal punctuation at the end of each bullet point?

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.

Does Fleet ever use semicolons or commas to end bullet points?

No. For consistency, we choose not to. Although not grammatically incorrect, it’s becoming increasingly uncommon to separate list items with semicolons or commas.

When to capitalize bullet points?

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”).

Commas

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.

Dashes and hyphens

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.
• Monday-Friday

A hyphen is unnecessary when not modifying a noun:

• The Fleet product is released every three weeks.

For editors

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.

How to make edits with GitHub

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 (this will take you to the GitHub editor).
2. Make your suggested edits in the GitHub editor.
3. 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).
4. Hit Propose change which will open a new pull request (PR).
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.

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.

How to edit recently merged pull requests for the handbook

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.

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 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 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 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.

How to edit Markdown pull requests for the docs

• 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.

How to edit articles, release posts, and press releases

This type of content comes in two flavors: draft articles and published articles.

For draft articles, please refer to Publishing articles on fleetdm.com.

For making edits to published articles:

1. Log in to Medium.
2. Find the article to edit and select "Edit story" from the hotdog menu (•••).
3. Scan for typos and grammatical errors.
4. Check that the tone aligns with our Communicating as Fleet guidelines and that Grammarly's tone detector is on-brand.
5. Remember, this article is already published, so if you're unsure about any edits, it doesn't hurt to check in with the original author.
6. Hit "Save and publish," and you're all done.

How to edit social media posts

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.

1. Post the tweet in the #g-growth Slack channel and tag the Digital Experience lead.
2. 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.
3. Suggest edits in the Slack thread for the Growth team to include and re-post.

Voice and tone guidelines

How to use our name

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.”

How to write headings & subheadings

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.

How to use osquery in sentences and headings

Osquery should always be written in lowercase unless used to start a sentence or heading. For example:

• Open source software, built on osquery.

or

• Osquery and Fleet provide structured, convenient access to information about your devices.

Open source vs. open core

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."

Commonly used terms

Term	Meaning
antivirus	A class of programs designed to detect, block, and clear away malware from devices, networks, and IT systems.
API	(Application Programming Interface) a software go-between that allows applications to communicate.
automation	A system that operates without needing intervention from a human to do so.
AWS	(Amazon Web Services) An ever-evolving cloud computing platform designed to allow application providers, ISVs, and vendors to host applications.
CI/CD	(Continuous Integration and Continuous Delivery/Continuous Deployment) A software development practice where cumulative code changes are made regularly and accurately.
CLI	(Command Line Interface) A tool for managing Fleet from the command line.
Client Platform Engineer (CPE)	See: CPE.
cloud	Data storage, networking, servers, databases, software, intelligence, and analytics through the internet instead of a device's hard drive.
command line	A horizontal row on an interface for text to allow you to type in a variety of commands. Also, see "CLI."
compliance	The act of being in line with the established risk-based expectations to preserve the strength and confidentiality of data stored, used, and transmitted.
CPE	(Client Platform Engineer) A person who constructs, evaluates, and deploys solutions to administrate a fleet of "clients" or end-users and does so in a scaleable manner.
CVE	(Common Vulnerabilities and Exposures) A system that provides a technique for sharing information publicly.
data leaks	When crucial and confidential data is unwittingly exposed physically, on the Internet, or any other way. This includes misplaced hard drives or devices.
device management	The process of overseeing the execution, process, and upkeep of a device, be it physical or virtual.
DevOps	Practices that incorporate both software development (Dev) and IT operations (Ops).
Docker	An open source platform that allows one to manage containerized applications.
DRI	The person who is singularly responsible for a given aspect of the open source project, the product, or the company.
EDR	(Endpoint Detection and Response) Security software that continually audits end-user devices to identify and respond to threats such as malware and ransomware. Also, see EDTR.
EDTR	(Endpoint Detection and Threat Response) Security software that continually audits end-user devices to identify and respond to threats such as malware and ransomware. Also, see EDR.
encryption	The act of converting data into a cipher that requires a key to be deciphered.
end-users	Someone using a distributed device or service. This could be a computer or a mobile device.
FileVault	The macOS feature to encrypt entire drives.
Firewall	A device or software that is used to block unwanted network traffic.
fleetctl	A CLI tool for managing Fleet from the command line. It can be used to accomplish many tasks you would typically need to do through the UI (User Interface). Also, fleetctl enables a GitOps workflow with Fleet and osquery.
GitHub	Cloud-based service for software development and version control using Git.
historical compliance	The ability to view past behavior around established risk-based controls to safeguard the integrity, confidentiality, and access of data storage, processing, or transfers.
IETF	(Internet Engineering Task Force) An organization that defines standardizing operations of internet protocols
Internet Engineering Task Force (IETF)	See: IETF
IR	(Incident Response) The actions one takes in response to a security breach or cyberattack.
Linux	An open source operating system.
Logica	An IT and management consultancy company based in the United Kingdom.
macOS	The operating system used in all of Apple's Mac computers.
Munki	Open-source software deployment tool for macOS.
open core	Is the business model where a company has a core version of a product with some of the features as (FOSS) Free Open Source Software in addition to a paid commercial version that is proprietary software.
open source	Software with intentionally public code for the sake of transparency.
OS	(Operating System) Software that provides the groundwork and instructions for a device's basic functions, including application use and controlling peripherals.
osquery	A tool that assembles low-level operating system analytics and monitoring.
out-of-policy device	A device that is fails any security or vulnerability policy created in Fleet.
permissions	Users have different abilities depending on the access level they have.
platform	Any software or hardware for hosting an application, data, or service.
policies	Yes or no questions you can ask using Fleet about your host devices.
policy compliance	The state of whether a device is passing or failing policies created in Fleet.
queries	Questions you can ask an end-user device's operating system via Fleet.
SAML	(Security Assertion Markup Language) A standard that allows identity providers (IdP) to authorize credentials for service providers; enabling SSO (Single Sign-On).
security audits	An assessment of an organization's security posture.
security engineer	Individual for managing and implementing security systems in an organization.
SIEM	(Security Information and Event Management) Technology that assembles data, security warnings, and events into one platform and provides almost real-time analyzed data to help you better monitor your organization's security.
Site Reliability Engineers (SREs)	Individuals who apply site reliability principles to improve reliability and scalability of systems in a systematic manner.
SQL	(Structured Query Language) A language used to manage databases and complete a variety of operations tasks within said databases.
SRE	See "Site Reliabilty Engineers."
SSO authentication	(Single Sign-On authentication) Allows identity providers (IdP) to authorize credentials for service providers once and use that as the authentication for multiple outside accounts.
TLS	(Transport Layer Security) An Internet Engineering Task Force (IETF) standardized protocol that authenticates and provides privacy and data protection over computer networks.
token	A physical Two-Factor Authentication (2FA) login security device to prove one's identity.
Transport Layer Security (TLS)	See: TLS
UI	(User Interface) An interactive space in a program that concentrates on style and intuitive use.
URL	Uniform resource locator. Specifies where a web resource is located (ex: https://fleetdm.com/articles/)
vulnerabilities	An exploitable weakness that can lead to unauthorized access or other negative consequences to a computer system.
Windows	Microsoft's graphical operating system.
YAML	A data serialized language that has features derived from Perl, C, HTML, and other languages and is often used to write configuration files.

Brand resources

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.

Email blasts

Do you need to send out a branded email blast to multiple recipients?

The manual way

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.")

The automated way

• 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.;

  sails run deliver-release-announcement --emailAddresses='["foo@example.com","bar@example.com"]'

Fleet website

Using Figma?

Fleet EE

• All product design work is done in the Fleet EE (scratchpad) Figma doc. Check out the README for how to use this doc.

Fleet website

• All website design work is done in the fleetdm.com (current, dev-ready) Figma file.

Shared 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.

Which logo should I use?

The "official" Fleet logo and other assets can be found at: https://fleetdm.com/logos

Responding to a 5xx error on fleetdm.com

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.

Incident post-mortems

When conducting an incident post-mortem, answer the following three questions:

1. Impact: What impact did this error have? How many humans experienced this error, if any, and who were they?
2. Root Cause: Why did this error happen?
3. 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.

When can I merge a change to the website?

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.

The "Deploy Fleet Website" GitHub action failed

If the action fails, please complete the following steps:

1. Head to the fleetdm-website app in the Heroku dashboard and select the "Activity" tab.
2. Select "Roll back to here" on the second to most recent deploy.
3. Head to the fleetdm/fleet GitHub repository and re-run the Deploy Fleet Website action.

Maintaining browser compatibility

A browser compatibility check of fleetdm.com should be carried out monthly to verify that the website looks and functions as expected across all supported browsers.

• 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.

How to make usability changes to the website

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:

1. Decide what you want to change. A small change is the best place to start.
2. Wireframe the design. Usually, digital experience does this, but anyone can contribute.
3. Present your change to the website DRI. They will approve it or suggest revisions.
4. Code the website change. Again, digital experience often does this, but anyone can help.
5. 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.

How to export images for the website

In Figma:

1. Select the layers you want to export.
2. Confirm export settings and naming convention:

• Item name - color variant - (CSS)size - @2x.fileformat (e.g., os-macos-black-16x16@2x.png)
• 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.

3. Click the Export button.

Vulnerability monitoring

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.

Article formatting guidelines

To publish an article, you will need to create a Pull Request for a new file, formatted in Markdown (todo), in https://github.com/fleetdm/fleet/tree/main/articles.

On this page

• Layout
• Images and screenshots
• Meta tags
• Customizable CTA
• Other pages of interest

Layout

The following layout guide aims to help you create consistently formatted articles. For an existing article example, check out the Markdown and the finished result.

Hero image

Consider adding a hero image for a more significant impact. Get in touch with Digital Experience via #content on Slack to make a request.

Table of contents

For long articles or guides, consider adding a table of contents.

Introduction

It’s good practice to start your article with a clear summary of what you will be discussing.

Main content

The main body of your article.

Conclusion

It’s a good idea to finish your article with a clear closing statement.

Add a customizable CTA

Add a CTA at the end of your article. See Customizable CTA below for instructions on creating a CTA tailored to your article topic.

Images and screenshots

Images are a great way to help engage your readers. But consider the following before including images or screenshots in your article:

• Does the image add value?
• Is your image likely to go out of date soon? (Consider the long-term maintenance of your article.)

Meta tags

These tags help pass information to the website about the article to display and store it.

<meta name="articleTitle" value="Deploying Fleet on Render">
<meta name="authorFullName" value="Ben Edwards">
<meta name="authorGitHubUsername" value="edwardsb">
<meta name="category" value="guides">
<meta name="publishedOn" value="2021-11-21">
<meta name="articleImageUrl" value="../website/assets/images/articles/deploying-fleet-on-render-cover-1600x900@2x.jpg">

articleTitle

The title of your article. Avoid long titles. As a rule of thumb, your title should not exceed two lines at desktop browser resolution. This is roughly 75 characters (including spaces).

authorFullName

Add the author’s full name here. Our system does not currently support multiple authors.

authorGitHubUsername

Add the author’s GitHub username to populate the author’s headshot.

category

Choose only one of the following categories for your article.

• Announcements: company or product announcements (including breaking changes), news, or events.
• Engineering: posts about engineering at Fleet and other engineering-related topics.
• Guides: help articles for using and deploying Fleet.
• Podcasts: podcast-related posts.
• Product: posts related to Fleet features.
• Releases: release posts, security, and patch releases.
• Reports: posts about the industry, data, surveys, etc.
• Security: posts about how we approach security at Fleet and other security-related topics.
• Success stories: stories from users or customers successfully using Fleet.

publishedOn

The date that the article was published. Please follow the correct date format, e.g., 2021-09-29.

articleImageUrl

The relative url path for the article cover image. Article images are stored in ../website/assets/images/articles/ See How to export images for the website.

Customizable CTA

Use the following code snippet to include an inline CTA (call to action) in your article:

<call-to-action 
  title=”All the data you need, without the performance hit.”
  text=”Fleet is the lightweight telemetry platform for servers and workstations.”
  primary-button-text=”Try Fleet Free” 
  primary-button-href=”/get-started?try-it-now” 
  secondary-button-text=”Schedule a demo”
  secondary-button-href=”calendly.com/fleetdm/demo”>
</call-to-action>

Tip

: paste the code-snippet at the end of your article, or, when creating long articles, consider adding a CTA mid-way through.

How to modify the customizable CTA

You can customize the CTA to promote what's relevant to your article.

title

The main call to action text

text

The proposition statement for your call to action

primary-button-text

The main call to action interaction. E.g., “Get started.”

primary-button-href

The URL link for your primary CTA.

secondary-button-text (optional)

The secondary call to action interaction. E.g., “Schedule a demo.”

secondary-button-href

The URL link for your secondary CTA.

Example

In the following example we will modify title, text, primary-button-text, and also remove secondary-button-text and secondary-button-href to create a call to action that promotes a job opening at Fleet.

<call-to-action 
  title=”We're hiring remote engineers, worldwide.”
  text=”Are you interested in working full time in Fleet's public GitHub repository?”
  primary-button-text=”Apply now” 
  primary-button-href=”https://fleetdm.com/jobs” 
</call-to-action>

Other pages of interest

• Process for submitting and publishing articles
• Markdown guide (todo)
• Writing style guide (todo)

Rituals

The following table lists the Brand group's rituals, frequency, and Directly Responsible Individual (DRI).

Ritual	Frequency	Description	DRI
Documentation quality	On request	Review pull requests to the docs for spelling, punctuation, and grammar.	Desmi Dizney
Handbook quality	Daily	Review pull requests to the handbook for spelling, punctuation, and grammar.	Desmi Dizney
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
Docs editor pass	Weekly	Edit two sections a week until completed.	Desmi Dizney
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.	Desmi Dizney
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

Slack channels

These groups maintain the following Slack channels:

Slack channel	DRI
#g-digital-experience	Mike Thomas and Eric Shaw (multiple DRIs, for the sake of timezones)
#oooh-websites	Mike Thomas
#oooh-automation	Mike McNeil
#g-people	Charlie Chance
#help-onboarding	Charlie Chance
#help-finance	Nathan Holliday
#help-brex-memos	Nathan Holliday
#help-p1	Mike McNeil
#help-operations	Nathan Holliday