Elgato_dark/fleet
1
0
Fork 0
mirror of https://github.com/fleetdm/fleet synced 2026-05-24 09:28:54 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 52

Handbook editor pass - Engineering (#5134)

Browse source 
* Handbook editor pass - Engineering

All edits are recorded by line:

18 Replace: “between” with “between the”
35 corrected capitalization
36 corrected capitalization
38 corrected capitalization
40 corrected capitalization
48 Replace: “the” with “a”
60 Replace: “follow” with “follow-up”
65 Replace: “follow up” with “follow-up”
77 Replace: “point to” with “point”
83 Replace: “.)” with “).”
102 Replace: “that” with “where”
104 Replace: “here” with “here.”
108 Replace: “in” with “on”
114 Replace: “linux” with “Linux”
115 Replace: “It's” with “Its”; Replace: “optional,” with “optional”; Replace: “prs” with “PRs”
125 Replace: “found” with “are found”
138 Replace: “Hand off” with “Handoff”

* Update handbook/engineering.md

* Update handbook/engineering.md

* Update handbook/engineering.md

* Update handbook/engineering.md

* Update handbook/engineering.md

* Update handbook/engineering.md

* Update handbook/engineering.md

* Update handbook/engineering.md

* Update handbook/engineering.md

* Update handbook/engineering.md

* Update handbook/engineering.md

Co-authored-by: Mike Thomas <78363703+mike-j-thomas@users.noreply.github.com>
This commit is contained in:
Desmi-Dizney 2022-04-19 22:00:07 -05:00 committed by GitHub
parent 1e0ea67e6f
commit 65a1c81a30
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 17 additions and 18 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

35
handbook/engineering.md
View file

@ -15,7 +15,7 @@ Release blocking bugs are exempt from the freeze period and are defined by the s
2. Security concerns
3. Issues with features targeted for current release
Non-release blocking bugs may include known issues that were not targeted for the current release, or newly documented behaviors that reproduce in older stable versions. These may be addressed during a release period by mutual agreement between [Product](./product.md) and Engineering teams.
Non-release blocking bugs may include known issues that were not targeted for the current release, or newly documented behaviors that reproduce in older stable versions. These may be addressed during a release period by mutual agreement between the [Product](./product.md) and Engineering teams.
### Release day
@ -29,9 +29,11 @@ This section outlines the on-call rotation at Fleet.
The on-call engineer is responsible for responding to technical Slack comments, Slack threads, and GitHub issues raised by customers and the community which cannot be handled by the [Customer Success team](./customers.md).
### Goals
At Fleet, our primary quality objectives are *customer service* and *defect reduction*. This entails Key Performance Indicators such as customer response time and the number of bugs resolved per cycle and:
Our primary quality objectives are *customer service* and *defect reduction*. We use the following Key Performance Indicators (KPIs) to measure our success with these goals:
- Become familiar with and stay abreast of what our community wants and the problems they're having.
- Customer response time.
- The number of bugs resolved per release cycle.
- Stay abreast of what our community wants and the problems they're having.
- Make people feel heard and understood.
@ -41,12 +43,9 @@ At Fleet, our primary quality objectives are *customer service* and *defect redu
### How?
- No matter what, folks who post a new comment in Slack or issue in GitHub get a **response** from the on-call engineer within 1 business day. The response doesn't need to include an immediate answer.
- Folks who post a new comment in Slack or issue on GitHub **must** receive a response from the on-call engineer **within 1 business day**. The response doesn't need to include an immediate answer.
- The on-call engineer can discuss any items that require assistance at the end of the daily standup. They are also requested to attend the "Customer experience standup" where they can bring questions and stay abreast of what's happening with our customers.
- If you do not understand the question or comment raised, [request more details](#requesting-more-details) to best understand the next steps.
- If you do not understand a question or comment raised, [request more details](#requesting-more-details) to best understand the next steps.
- If an appropriate response is outside your scope, please post to `#help-oncall`, a confidential Slack channel in the Fleet Slack workspace.
- If things get heated, remember to stay [positive and helpful](https://canny.io/blog/moderating-user-comments-diplomatically/). If you aren't sure how best to respond in a positive way, or if you see behavior that violates the Fleet code of conduct, get help.
@ -57,12 +56,12 @@ Typically, the *questions*, *bug reports*, and *feature requests* raised by memb
❓ 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 the question "How do I do X in Fleet?" A follow question could be "What are you attempting to accomplish by doing X?"
- Let's say a community member asks the question "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 the primary question is brought to the Roundup meeting. In addition, the community member receives a response and feels heard.
🦟 For bug reports, it's helpful to ask for recreation 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?"
- 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 in an attempt to understand the "Why?" or underlying motivation behind the request.
@ -74,13 +73,13 @@ Typically, the *questions*, *bug reports*, and *feature requests* raised by memb
If the feature is requested by a customer, the on-call engineer is requested to create a feature request issue and follow up with the customer by linking them to this issue. This way, the customer can add additional comments or feedback to the newly filed feature request issue.
If the feature is requested by anyone other than a customer (ex. user in #fleet Slack), the on-call engineer is requested to point to the user to the [feature request GitHub issue template](https://github.com/fleetdm/fleet/issues/new?assignees=&labels=idea&template=feature-request.md&title=) and kindly ask the user to create a feature request.
If the feature is requested by anyone other than a customer (ex. user in #fleet Slack), the on-call engineer is requested to point the user to the [feature request GitHub issue template](https://github.com/fleetdm/fleet/issues/new?assignees=&labels=idea&template=feature-request.md&title=) and kindly ask the user to create a feature request.
### Closing issues
It is often a good idea to let the original poster (OP) close their issue themselves since they are usually well equipped to decide whether the issue is 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](https://github.com/balderdashy/sails/issues/3423#issuecomment-169751072) and [balderdashy/sails#4057](https://github.com/balderdashy/sails/issues/4057) for examples of this.)
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](https://github.com/balderdashy/sails/issues/3423#issuecomment-169751072) and [balderdashy/sails#4057](https://github.com/balderdashy/sails/issues/4057) for examples of this).
To provide another way of tracking status without closing issues altogether, consider using the
green labels that begin with "+". To explore them, type `+` from GitHub's label picker.
@ -101,18 +100,18 @@ Premium support for support/troubleshooting: **All versions**
There are four sources that the on-call engineer should monitor for activity:
1. Customer Slack channels - Found under the "Connections" section in Slack. These channels are usually titled "at-insert-customer-name-here"
1. Customer Slack channels - Found under the "Connections" section in Slack. These channels are usually titled "at-insert-customer-name-here."
2. Community chatroom - https://osquery.slack.com, #fleet channel
3. Reported bugs - [GitHub issues with the "bug" and ":reproduce" label](https://github.com/fleetdm/fleet/issues?q=is%3Aissue+is%3Aopen+label%3Abug+label%3A%3Areproduce). Please remove the ":reproduce" labels after you've followed up in the issue.
3. Reported bugs - [GitHub issues with the "bug" and ":reproduce" label](https://github.com/fleetdm/fleet/issues?q=is%3Aissue+is%3Aopen+label%3Abug+label%3A%3Areproduce). Please remove the ":reproduce" label after you've followed up in the issue.
4. Pull requests opened by the community - [GitHub open pull requests](https://github.com/fleetdm/fleet/pulls?q=is%3Apr+is%3Aopen)
### Tools
There is a script located in `scripts/on-call` for use during on-call rotation (only been tested on macOS and linux).
It's use is completely optional, but contains several useful commands for checking issues and prs that may require attention.
There is a script located in `scripts/on-call` for use during on-call rotation (only been tested on macOS and Linux).
Its use is completely optional but contains several useful commands for checking issues and PRs that may require attention.
You will need to install the following tools in order to use it:
- [Github CLI](https://cli.github.com/manual/installation)
@ -122,7 +121,7 @@ You will need to install the following tools in order to use it:
There are several locations in Fleet's public and internal documentation that can be helpful when answering questions raised by the community:
1. The frequently asked question (FAQ) documents in each section found in the `/docs` folder. These documents are the [Using Fleet FAQ](../docs/Using-Fleet/FAQ.md), [Deploying FAQ](../docs/Deploying/FAQ.md), and [Contributing FAQ](../docs/Contributing/FAQ.md).
1. The frequently asked question (FAQ) documents in each section are found in the `/docs` folder. These documents are the [Using Fleet FAQ](../docs/Using-Fleet/FAQ.md), [Deploying FAQ](../docs/Deploying/FAQ.md), and [Contributing FAQ](../docs/Contributing/FAQ.md).
2. The [Internal FAQ](https://docs.google.com/document/d/1I6pJ3vz0EE-qE13VmpE2G3gd5zA1m3bb_u8Q2G3Gmp0/edit#heading=h.ltavvjy511qv) document.
@ -135,7 +134,7 @@ Every week, the on-call engineer changes. Here are some tips for making this han
Click `@oncall`. In the right sidebar, click "Edit Members". Remove the former on-call, and add
yourself.
2. Hand off newer conversations. For newer threads, the former on-call can unsubscribe from the
2. Handoff newer conversations. For newer threads, the former on-call can unsubscribe from the
thread, and the new on-call should subscribe. The former on-call should explicitly share each of
these threads, and the new on-call can select "Get notified about new replies" in the "..." menu.
The former on-call can select "Turn off notifications for replies" in that same menu. It can be