1f4f673816
<!-- It's not this actually- this is an unrelated issue: https://github.com/fleetdm/confidential/issues/2187 --> ... --------- Co-authored-by: Mike McNeil <mikermcneil@users.noreply.github.com> Co-authored-by: Eric <eashaw@sailsjs.com> |
||
---|---|---|
.. | ||
article-formatting-guide.md | ||
how-to-submit-and-publish-an-article.md | ||
README.md |
Community
Marketing mission
To show organizations how Fleet is the best way to keep their employees and their machines safe and productive. To create demand for the world’s first open-source and cross-platform MDM.
Positioning
See 📖Company#Positioning.
Marketing Qualified Opportunities (MQOs)
Marketing's goal is to increase product usage. We value users of all sizes adopting Fleet Free or Fleet Premium. Companies purchasing under 100 device licenses should sign up for self-service. Companies that enroll more than 100 devices should talk to an expert. When these companies attend this meeting, Fleet considers them Marketing Qualified Opportunities (MQOs).
Lead enrichment
Fleet's lead enrichment process can be found in this Google Doc (private).
Product Marketing and Launch strategies
- How we rank features for launch
- Our Launch Playbook on Monday.com To start a new major product launch, duplicate this monday board, as well as the Run-of-show board.
- MDM Launch Retrospective
How we show up for our community online
Posting to social media should follow a personable tone and strive to deliver useful information across our social accounts. Some specific guidelines that we follow at Fleet:
- Answer technical questions quickly: if a community member has a technical question drop it in #g-marketing in slack if you can't answer it yourself.
- Never engage with un-constructive feedback or competitive spamming. If there is a valuable conversation to be had, let our community lead the conversation, and let our community come to our defense. They are the users, and often their insight and debates are more attuned then ours.
- Do not share Hacker News links directly. If we are on Hacker News, just let the community know and if they find us then great.
Topics:
- Fleet the product
- Internal progress
- Highlighting community contributions
- Highlighting Fleet and osquery accomplishments
- Industry news about osquery
- Industry news about device management
- Upcoming events, interviews, and podcasts
Guidelines:
In keeping with our tone, use hashtags in line and only when it feels natural. If it feels forced, don’t include any.
Self-promotional tweets are not ideal(Same goes for, to varying degrees, Reddit, HN, Quora, StackOverflow, LinkedIn, Slack, and almost anywhere else). Also, see The Impact Equation by Chris Brogan and Julien Smith.
Great brands are magnanimous.
Scheduling:
Once a post is drafted, deliver it to our three main platforms.
Log in to Sprout Social and use the compose tool to deliver the post to each platform. (credentials in 1Password).
Promoting blog posts on social media
Once a blog post has been written, approved, and published, make sure that it is promoted on social media. Please refer to our Publishing as Fleet guide for more detailed information.
Fleet in the news!
- Computer World: Fleet announces open-source, cross-platform MDM solution
- 9to5Mac: Apple @ Work Podcast: Fleet announces open-source, cross-platform device management platform
- Open Source For U: Fleet Unveils The First Ever Open Source, Cross-Platform Device Management Platform
- Tech Switch: Fleet announces open-source, cross-platform MDM solution
About Fleet Device Management
(Under 50 words)
Fleet is a lightweight, open-core, cross-platform solution providing real-time insights using osquery and GitOps-driven device management, including Mac, Windows, Linux, and ChromeOS. Fleet streamlines IT security with automated vulnerability management, facilitating compliance policy implementation. Offering seamless on-premise or cloud integration, Fleet is a trusted, accessible tool for robust IT administration.
(Under 100 words)
Fleet is a lightweight, open-core, cross-platform solution that provides real-time insights using osquery and GitOps-driven management for all your devices, including Mac, Windows, Linux, and ChromeOS. It empowers IT security and IT administrators by facilitating device investigation, mobile device management (MDM), and implementing standard compliance policies for remediation and updates. Fleet enhances IT security with automated vulnerability management and security workflows within a single application. Trusted by hundreds of companies, Fleet requires no certification and offers seamless on-premise or cloud integration. Fleet is a comprehensive, accessible tool to strengthen IT security and device management.
(Under 200 words)
Fleet is a lightweight, open-core, cross-platform platform that embraces the power of osquery to provide real-time insights and GitOps-driven management across all your devices, including Mac, Windows, Linux, and ChromeOS. This versatile platform is a comprehensive tool for IT security and IT administrators, offering a streamlined approach to investigating computers, servers, and managing mobile devices.
Leverage Fleet's programmable Mobile Device Management (MDM) capabilities to illuminate the darkness surrounding MDM access and data acquisition. Trusted by hundreds of companies, Fleet and osquery deliver superior visibility into your devices, facilitating the implementation of standard compliance policies for real-time remediation and updates.
Fleet offers seamless integration for on-premise or cloud-based operations, requiring no certification or education to start, making Fleet accessible and straightforward. Additionally, Fleet contributes to robust IT security by enabling the automation of vulnerability management and security workflows within a single application. Create or install policies to ascertain device compliance with your security guidelines, and build automations to address vulnerabilities in your environment promptly.
As a result, Fleet emerges as a practical and efficient solution for IT administrators seeking to enhance their IT security landscape through GitOps and elevate their device management capabilities.
Press releases
If we are doing a press release, we are probably pitching it to one or more reporters as an exclusive story if they choose to take it. Consider not sharing or publicizing any information related to the upcoming press release before the announcement. Also, see What is a press exclusive, and how does it work on Quora.
Press release boilerplate
Fleet gives teams fast, reliable access to data about the production servers, employee laptops, and other devices they manage - no matter the operating system. Users can search for any device data using SQL queries, making it faster to respond to incidents and automate IT. Fleet is also used to monitor vulnerabilities, battery health, and software. It can even monitor endpoint detection and response and mobile device management tools like Crowdstrike, Munki, Jamf, and Carbon Black, to help confirm that those platforms are working how administrators think they are. Fleet is open source software. It's easy to deploy and get started quickly, and it even comes with an enterprise-friendly free tier available under the MIT license.
IT and security teams love Fleet because of its flexibility and conventions. Instead of secretly collecting as much data as possible, Fleet defaults to privacy and transparency, capturing only the data your organization needs to meet its compliance, security, and management goals, with clearly-defined, flexible limits.
That means better privacy, better device performance, and better data but with less noise.
Sponsoring events
When reaching out for sponsorships, Fleet's goal is to expose potential hires, contributors, and users to Fleet and osquery. Track prospective sponsorships in "Sponsorships"
Once a relevant sponsorship opportunity and its prospectus are reviewed:
-
Create a new GitHub issue.
-
Detail the important information of the event, such as date, name of the event, location, and page links to the relevant prospectus.
-
Add the issue to the “Conferences/speaking” column of the Growth plan project.
-
Schedule a meeting with the representatives at the event to discuss pricing and sponsorship tiers.
-
Invoices should be sent to Nathan Holliday for approval.
-
Nathan Holliday (Business Operations) will route the signatures required over to Mike McNeil (CEO) with DocuSign.
-
Once you complete the above steps, use the Speaking events issue template to prepare speakers and participants for the event.
Partners
All of Fleet's partnerships are located in "❤️🔥 Buying situations > 🚿Channels / partners". (This is the source of truth for any active or proposed partnership.)
Community
Communities
Fleet's users and broader audience are spread across many online platforms. Here are the most active communities where Fleet's developer relations and social media team members participate at least once every weekday:
- osquery Slack (
#fleet
channel) - MacAdmins Slack (
#fleet
channel) - osquery discussions on LinkedIn
- osquery discussions on Twitter
- reddit.com/r/sysadmins
- reddit.com/r/SysAdminBlogs
- r/sysadmin Discord
Goals
Our primary quality objectives are customer service and defect reduction. We try to optimize the following:
- Customer response time
- The number of bugs resolved per release cycle
- Staying abreast of what our community wants and the problems they're having
- Making people feel heard and understood
- Celebrating contributions
- Triaging bugs, identifying community feature requests, community pull requests, and community questions
How?
- Folks who post a new comment in Slack or issue on GitHub should receive a response within one business day. The response doesn't need to include an immediate answer.
- If you feel confused by a question or comment raised, request more details to better your understanding of the next steps.
- If an appropriate response is outside of your scope, please post to
#help-engineering
(in the Fleet Slack)), tagging@oncall
. - If things get heated, remember to stay positive and helpful. If you aren't sure how best to respond positively, or if you see behavior that violates the Fleet code of conduct, get help.
Requesting more details
Typically, the questions, bug reports, and feature requests raised by community members will be missing helpful context, recreation steps, or motivations.
❓ For questions that you don't immediately know the answer to, it's helpful to ask follow-up questions to receive additional context.
- Let's say a community member asks, "How do I do X in Fleet?" A follow-up question could be, "What are you attempting to accomplish by doing X?"
- This way, you have additional details when you bring this to the Roundup meeting. In addition, the community member receives a response and feels heard.
🦟 For bug reports, it's helpful to ask for re-creation steps so you're later able to verify the bug exists.
- Let's say a community member submits a bug report. An example follow-up question could be, "Can you please walk me through how you encountered this issue so that I can attempt to recreate it?"
- This way, you now have steps that verify whether the bug exists in Fleet or if the issue is specific to the community member's environment. If the latter, you now have additional information for further investigation and question-asking.
💡 For feature requests, it's helpful to ask follow-up questions to understand better the "Why?" or underlying motivation behind the request.
- Let's say a community member submits the feature request "I want the ability to do X in Fleet." A follow-up question could be "If you were able to do X in Fleet, what's the next action you would take?" or "Why do you want to do X in Fleet?."
- Both of these questions provide helpful context on the underlying motivation behind the feature request when brought to the Roundup meeting. In addition, the community member receives a response and feels heard.
Closing issues
It is often good to let the original poster (OP) close their issue themselves since they are usually well equipped to decide to mark the issue as resolved. In some cases, circling back with the OP can be impractical, and for the sake of speed, issues might get closed.
Keep in mind that this can feel jarring to the OP. The effect is worse if issues are closed automatically by a bot (See balderashy/sails#3423 and balderdashy/sails#4057 for examples of this).
Tools
Find the script in scripts/oncall
for use during oncall rotation (only been tested on macOS and Linux).
Its use is optional but contains several useful commands for checking issues and PRs that may require attention.
You will need to install the following tools to use it:
Resources
There are several locations in Fleet's public and internal documentation that can be helpful when answering questions raised by the community:
-
Find the frequently asked question (FAQ) documents in each section in the
/docs
folder. These documents are the Get started FAQ, and Contributing FAQ (on GitHub). -
Use the internal FAQ document.
Assistance from engineering
Community team members can reach the engineering oncall for assistance by writing a message with @oncall
in the #help-engineering
channel of the Fleet Slack.
Pull requests
The most important thing when community members contribute to Fleet is to show them we value their time and effort. We need to get eyes on community pull requests quickly (within one business day) and get them merged or give feedback as soon as we can.
Managing community contributions
The Community Engagement DRI is responsible for keeping an eye out for new community contributions, getting them merged if possible, and getting the right eyes on them if they require a review.
Each business day, the Community Engagement DRI will check open pull requests to
- check for new pull requests (PRs) from the Fleet community.
- approve and merge any community PRs that are ready to go.
- make sure there aren't any existing community PRs waiting for a follow-up from Fleet.
Identify community contributions
When a new pull request is submitted by a community contributor (someone not a member of the Fleet organization):
-
Add the
:community
label. -
Self-assign for review.
-
Check whether the PR can be merged or needs to be reviewed by the Product team.
-
Things that generally don't need additional review:
-
Minor changes to the docs.
-
Small bug fixes.
-
Additions or fixes to the Standard Query Library (as long as the SQL works properly and is attributed correctly).
-
-
If a review is needed:
- Request a review from the Product DRI. They should approve extensive changes and new features. Ask in the #help-product channel in Fleet's Slack for more information.
- Tag the DRI and the contributor in a comment on the PR, letting everyone know why an additional review is needed. Make sure to say thanks!
- Find any related open issues and make a note in the comments.
-
Please refer to our PRs from the community guide and use your best judgment.
Communicate with contributors
Community contributions are fantastic, and it's important that the contributor knows how much they are appreciated. The best way to do that is to keep in touch while we're working on getting their PR approved.
While each team member is responsible for monitoring their active issues and pull requests, the Community Engagement DRI will check in on pull requests with the :community
label daily to make sure everything is moving along. If there's a comment or question from the contributor that hasn't been addressed, reach out on Slack to get more information and update the contributor.
Making the updates
Every week, the Community Engagement DRI will:
- Create a new
Weekly Doc Update
issue on Monday and add it to the Community board. - Review the Slack Questions Spreadsheet and make sure that any necessary updates to the documentation are made.
- Update the spreadsheet to indicate what action was taken (Doc change, FAQ added, or None) and add notes if need be.
- Set up a single PR to update the Docs.
- In the notes, include a list of changes made as well as a link to the related thread.
- Bring any questions to DevRel Office Hours (time TBD).
- Submit the PR by the end of the day on Thursday.
- Once the PR is approved, share in the #fleet channel of Osquery Slack Workspace and thank the community for being involved and asking questions.
Fleet swag
We want to recognize and congratulate community members for their contributions to Fleet. Nominating a contributor for Fleet swag is a great way to show our appreciation.
How to order swag
We currently deliver Fleet swag and osquery stickers for those that request it through community contributions, Fleet documentation, and social media posts.
Our Typeform integrations automatically populate information within the #help-swag Slack channel for osquery sticker and shirt requests through TypeForm.
For community contributions, reach out to the contributor to thank them for their contribution, ask if they would like any swag, and fill out their information in the Fleet swag request sheet.
Once approved in the sheet, or submitted through Typeform, place the order through our Printful account (credentials in 1Password) within 48 hours of submission. If available through the ordering process, add a thank you note for their contribution or request.
When an estimated shipping date is available, notify the requestor by email with an update on shipping, thank them for being a part of the community, and provide the tracking number once shipped.
Printful order information can be found on Printful.
At this time, double-check that information within Salesforce and Typeform is accurate according to the enrichment process.
Brand
Brand resources
To download official Fleet logos, product screenshots, and wallpapers, head over to our brand resources page.
See About Fleet Device Management for ready-to-go descriptions of Fleet and for the press-release boilerplate.
Figma
We use Figma for most of our design work. This includes the Fleet product, our website, and our marketing collateral.
Which file should I use?
Fleet product. All product design work is done in the Fleet product Figma project.
See 📖Product#Working with Figma for more details.
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.
Publishing Fleet content
The following describes how to go about publishing and editing content at Fleet.
Publication methods
- Instant: Content is published instantly. Content is approved by Brand post-facto – see links in the table below to get the required training.
- Gated: Submit content to Brand 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.
Revision methods (for editors)
- 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.
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 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 Brand – 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 the Brand team – 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 |
Decks | Instant. Sales typically creates decks. The Brand team shouldn't be a blocker. | Feedback | three business days |
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
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.
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.
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-marketing Slack channel and tag the Brand team 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 Marketing team to include and re-post.
Commonly used terms
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.
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 Brand team by posting it in their primary Slack channel, along with your urgency/timeline. The Brand 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, the Brand team 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"]'
Newsletter emails
The content for our newsletter emails comes from our articles. Because our HTML emails require that the styles are added inline, we generate HTML emails by using a script and manually QA them before sending them out to subscribers.
Generating emails for the Fleet newsletter
To convert a Markdown article into an email for the newsletter, you'll need the following:
- A local copy of the Fleet repo.
- Node.js
- (Optional) Sails.js installed globally on your machine (
npm install sails -g
)
Once you have the above follow these steps:
- Open your terminal program, and navigate to the
website/
folder of your local copy of the Fleet repo.
Note: If this is your first time running this script, you will need to run
npm install
inside of thewebsite/
folder to install the website's dependencies.
- Run the
build-html-email
script and pass in the filename of the Markdown article you would like to convert with the--articleFilename
flag.
- With Node, you will need to use
node ./node_modules/sails/bin/sails run build-html-email
to execute the script. e.g.,node ./node_modules/sails/bin/sails run build-html-email --articleFilename="fleet-4.19.0.md"
- With Sails.js installed globally you can use
sails run build-html-email
to execute the script. e.g.,sails run build-html-email --articleFilename="fleet-4.19.0.md"
Note: Only Markdown (
.md
) files are supported by the build-html-email script. The file extension is optional when providing the articleFilename.
- Once the script is complete, a new email partial will be added to the
website/views/emails/newsletter-partials/
folder.
Note: If an email partial has already been created from the specified Markdown article, the old version will be overwritten by the new file.
- Start the website server locally to preview the generated email. To test the changes locally, open a terminal window in the
website/
folder of the Fleet repo and run the following command:
- With Node.js: start the server by running
node ./node_modules/sails/bin/sails lift
. - With Sails.js installed globally: start the server by running
sails lift
.
- With the server lifted, navigate to http://localhost:2024/admin/email-preview and login with the test admin user credentials (email:
admin@example.com
pw:abc123
).
Click on the generated email in the list of emails generated from Markdown content and navigate to the preview page. On this page, you can view the see how the email will look on a variety of screen sizes.
When you've made sure the content of the email looks good at all screen sizes, commit the new email partial to a new branch and open a pull request to add the file. You can request a review from a member of the digital experience team.
Things to keep in mind when generating newsletter emails:
- The emails will be generated using the Markdown file locally, any changes present in the local Markdown file will be reflected in the generated email.
- HTML elements in the Markdown file can cause rendering issues when previewing the generated email. If you see a "Script error" overlay while trying to preview an email, reach out to Eric Shaw for help.
- The filename of the generated email will have periods changed to dashes. e.g., The generated email partial for
fleet-4.19.0.md
would befleet-4-19-0.ejs
Website
Read the Website handbook for detailed information and processes specific to the Fleet website. Including the website roadmap, how to request changes, and processes related to QA, deploying changes, and marketing experimentation.
Rituals
The following table lists the Marketing, Brand, and Community group's rituals, frequency, and Directly Responsible Individual (DRI).
Ritual | Frequency | Description | DRI |
---|---|---|---|
Daily tweet | Daily | Post Fleet content on Twitter | Drew Baker |
Daily LinkedIn post | Daily | Post Fleet content to LinkedIn | Drew Baker |
Check Twitter messages | Daily | Check and reply to messages on the Fleet Twitter account, and disregard requests unrelated to Fleet | Drew Baker |
Social engagement | Weekly | Participate in 50 social media engagements per week | Drew Baker |
Osquery jobs | Weekly | Post to @osqueryjobs twice a week | Drew Baker |
Enrich Salesforce leads | Weekly | Follow the Salesforce lead enrichment process every Friday | Drew Baker |
Outside contributions | Weekly | Check pull requests for outside contributions every Monday | Drew Baker |
Weekly article | Weekly | Publish an article and promote it on social media | Drew Baker |
Weekly ins and outs | Weekly | Track marketing team ins and outs | Mike McNeil |
Podcast outreach | Weekly | Conduct podcast outreach twice a week | Drew Baker |
Weekly update | Weekly | Update the marketing KPIs in the "🌈 Weekly updates" spreadsheet | Drew Baker |
Update the "Release" field on the #g-marketing board | Every 3 weeks |
|
Mike McNeil |
Monthly conference checks | Monthly | Check for conference openings and sponsorship opportunities on the 1st of every month | Drew Baker |
Freshen up pinned posts | Quarterly | Swap out or remove pinned posts on the brand Twitter account and LinkedIn company page | Drew Baker |
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 |
Brand 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 |
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 |
Updating the extended osquery schema | Three weeks | Running the generate-merged-schema script and committing the merged schema json to the Fleet GitHub repo |
Eric Shaw |
Community Slack | Daily | Check Fleet and osquery Slack channels for community questions, make sure questions are responded to and logged | Kathy Satterlee |
Social media check-in | Daily | Check social media for community questions and make sure to respond to them. Generate dev advocacy-related content | Kathy Satterlee |
Issue check-in | Daily | Check GitHub for new issues submitted by the community, check the status of existing requests, and follow up when needed | Kathy Satterlee |
Outside contributor follow-up | Weekly | Bring pull requests from outside contributors to engineering and make sure they are merged promptly and promoted | Kathy Satterlee |
Documentation update | Weekly | Turn questions answered from Fleet and osquery Slack into FAQs in Fleet’s docs. | Kathy Satterlee |
StackOverflow | Weekly | Search StackOverflow for “osquery,” answer questions with Grammarly, and find a way to feature Fleet in your StackOverflow profile prominently | Rotation: Community team |
Intake
Changing the website
Everyone can contribute. Changes that impact the user interface, design, or APIs of fleetdm.com go through Fleet's drafting process.
To plan or propose a change to the website, or to submit a bug report about the website, create a public issue using the "Website request" issue template. These changes are addressed by the website group.
Note: One important exception is changes to the website that accompany changes in the core product. These are instead handled by the Customer Experience group, and should be proposed as changes to the core product.
Other requests
To make any other kind of request from the marketing department, or if you are unsure, then post in our group Slack channel (#g-marketing
) and someone from this group will reply within 1 business day. Please only at-mention specific contributors in time-sensitive situations, or when their personal attention is required.
Slack channels
These groups maintain the following Slack channels:
Slack channel | DRI |
---|---|
#g-marketing |
Mike McNeil |
#g-website |
Michael Thomas |
#fleet-mindshare-pr |
Drew Baker |
#help-public-relations |
Mike McNeil |
#help-promote |
Mike McNeil |
#help-swag |
Drew Baker |
#oooh-websites |
Michael Thomas |
#help-p1 |
Mike McNeil |
Stubs
Content style guide
Please see 📖handbook/company/communications/content-style-guide.
Documentation
Please see 📖handbook/company/communications/content-style-guide.