* add section about onboarding and
* Update people.md
All edits are recorded by line:
227 replace “out” with “on”; replaced “that” with “they”
229 replaced “important” with “essential”; deleted “a” before “good”; deleted “that” before “they”; replaced “like they take seriously” with “is necessary”; added “a” before “review”
223 added “,” after “screen”
235 replaced “Make” with “make”, added “.” after “quickly”
236 replaced “Make” with “make”, added “.” after “quickly
237 replaced “Make” with “make”, added “.” after “mean”
238 replaced “Make” with “make”, added “.” after “markdown”
239 replaced “Talk” with “talk”; added “.” after “calendar”
240 replaced “Give” with “give”; added “.” after “folder”
Co-authored-by: Desmi-Dizney <99777687+Desmi-Dizney@users.noreply.github.com>
* all login methods no longer use redux
* removed redux from registration
* redirect user from registration
* removed redux from sso invite
* removed redundant component
* refactored user settings page
* removed redux from logout
* cleaned up unused redux calls
* lint fixes
* removed test
* removed old config interface
* fixed registration bug
* team permission fix
* removed remaining redux references from pages - #4436
* better way to set config
* Update people.md
Things new and old employees should know
Why do we wireframe first?
- Wireframing is called “drafting” at Fleet and is done in Figma.
- Anyone can make a wireframe suggestion, and wireframes are easy to contribute without being code literate.
- Drafting is completed for each change.
- It can be thrown away after changes. Coding first leaves verbiage that is difficult to update, if it ever gets done at all.
- It allows you to simplify the creation and testing of error messages.
- Iterating in wireframes first lets us do all this for:
- Error messages
- Layouts
- Flows
- Interactions
- Help text
- Button text
- Forms
- URLs
- API parameters
- API response data…and more
Why mono repo?
- One repo keeps all of the relevant work in one place. The only exception is when working on something confidential.
- One repo means that there is less to get lost.
- One repo pools GitHub stars to reflect Fleet’s actual presence better.
Why organize work in team-based kanban boards?
- Kanban boards provide a uniform layout across all teams where anyone in the company can look to see what other teams are working on and have coming up.
- The different columns on the boards allow us to create a game plan for our to-do list for each 3 week iteration.
- These boards allow anyone in the world to contribute.
Why 3 week cadence?
- Fleet product is released every 3 weeks so everyone in the company is synced up to this same schedule.
- Other companies use a 4 week release cycle but at Fleet, we like to move a little faster so we can get more done.
- Everyone always knows when the new release is so they also know when their work is due.
Why agile?
- See: https://agilemanifesto.org/
- Collaborating and pushing for the next release creates the best product and culture.
Our values and mission.
- See: https://fleetdm.com/handbook/company
Why the emphasis on training?
- Investing in people makes them better and faster contributors.
- Creating a culture of helping others results in people feeling more comfortable and confident even if they aren’t familiar with osquery.
- A sharp focus on training means things are written down.
Why handbook-first strategy?
- Watch: https://www.youtube.com/watch?v=aZrK8AQM8Ro
- For more details see: https://about.gitlab.com/company/culture/all-remote/handbook-first-documentation/
- Documenting in the handbook allows Fleet to scale up and retain knowledge for consistency.
Why not continuously generate REST API docs from javadoc-style code comments?
- It looks cheap. Those using open API still are embarrassed by their docs.
- Generated documentation via tools like Swagger/OpenAPI have a tendency to get out of date and becomes harder to fix to make it up to date.
- There is less control over how to add annotations to the doc.
- It has less visibility/ accessibility/ modifiability for people without Golang coding experience.
- Fully integrating with swagger's format sufficiently to document everything involves more people on the team learning about the intricacies of swagger (instead of editing markdown that looks like any other markdown in the docs/website)).
- Autogenerating docs is not the only way to make sure docs accurately reflect the API.
- Generated docs become just as out of date as handmade docs, except since they are generated makes them more difficult to edit and therefore gated/siloed. Adaptability is efficient.
- Using markdown allows anyone to edit our docs.
- Replacing markdown files with code comments makes API reference docs harder to locate and edit.
I also removed "." from "### Purchasing a company-issued device" on line 120.
* Update people.md
39 replaced “employees with “team members”
79, 84, 94, 95 updated to a Markdown link
* Update company.md
All edits are recorded by line:
Lines 30- 97 added "Things new and old team members should know" section.
* Update people.md
Removed all edits
* Adding hardware security key guide
* Update security.md
Finish sentence...
* Update security.md
Fixed Slack channel names
* Update README.md
Added section to README
* Update security.md
Edited 2FA table + removed info about Titan key since we've picked our model
* Update security.md
All edits are recorded by line:
272 replaced “,” with “.”; deleted “or” before “ask”; added “If you do not have a company card” before “ask”
273 deleted “you” after “get”; deleted “ if you do not have a company card” after “one”
317 added “.” to the end
322 added space before “You”
324 added “.” to the end
336 deleted “,” after “key”
344 added “,” after “sites”; replaced “much” with “many”; replaced “, “ with “ (“
345 added “)” after “keys”
352 replaced “When doing this, you” with “You”
353 replaced “itself” with “when doing this”
354 replaced “the” with “The”
355 deleted “using” after “than”
360 replaced “that being said,” with “Stay mindful that”
365 replaced “IF” with “If”
368 added “,” after “keys”
370 replaced “are” with “find yourself”
371 replaced “You” with “Fleet”; deleted “be” after “will”; replaced “provided” with “provide”; deleted “,” after “key”
378 replaced “does support” with “supports”
379 replaced “to” with “that”
526 added “.” after “YubiKeys”
545 replaced “Privileged” with “Fleet configures privileged”; deleted “ are configured” before “with”
546 replaced “,” with “.”; replaced “which” with “This”; replaced “prevent” with “prevents”
547 replaced “setting” with “set”
548 deleted “, as well as the model we use and why”
* Update security.md
Fixed as per @zwass comments!
Co-authored-by: Desmi-Dizney <99777687+Desmi-Dizney@users.noreply.github.com>
This optimizes the query in particular for Domain Controllers, where
there are a number of users with no local accounts and don't need to be
searched for software.
See #4261
not set on the INSERT.
- OUT: Only sets the ID on the passed session and returns it. (`CreatedAt`, `AccessedAt`, are not set.)
New version:
```go
func (ds *Datastore) NewSession(ctx context.Context, userID uint, sessionKey string) (*fleet.Session, error) {
sqlStatement := `
INSERT INTO sessions (
user_id,
` + "`key`" + `
)
VALUES(?,?)
`
result, err := ds.writer.ExecContext(ctx, sqlStatement, userID, sessionKey)
if err != nil {
return nil, ctxerr.Wrap(ctx, err, "inserting session")
}
id, _ := result.LastInsertId() // cannot fail with the mysql driver
return ds.sessionByID(ctx, ds.writer, uint(id))
}
```
- IN: Define arguments that are truly used when creating a session.
- OUT: Load and return the fleet.Session struct with all values set (using the `ds.writer` to support read replicas correctly).
PS: The new `NewSession` version mimics what we already do with other entities, like policies (`Datastore.NewGlobalPolicy`).
* Ritual Heading with OKR planning subheading
Proposing to add the ritual heading to handbook/people in line with [https://github.com/fleetdm/confidential/issues/1013] and [https://github.com/fleetdm/fleet/issues/4671].
cc: @hollidayn
* Ritual update
Added OKR planning context and ritual steps to "Ritual" section of handbook.
* Move ritual section above Slack channels
Co-authored-by: Eric <eashaw@sailsjs.com>
* Orbit: Add Fleet Desktop support to Windows
* Rename workflow, fix linux build
* Do not compile systray on linux
* nolint on unused
* Fix lint properly
* nolint both checkers
* Fix monitor logic in desktopRunner
* Fix interrupt and execute order
