- Permissions changes will either be a draft PR to manage access doc
page or explicitly mention that there's no change to the doc page
- Anyone on product team can assign API changes to engineering team
- Add "Product designer" section so that contributors know who to
contact with questions about UI, CLI, or API design
- Move entire "Context" section higher up so that it's easier to find
- Clarify that the Figma link should take folks to the "ℹ️ Cover" page
- This way, everyone can see the status of the story: Work in progress,
Settled, Released
- This way, it's hard to accidentally link to the scratchpad file which
is not ready for dev
#15881
This PR adds a script to test DB migrations with Percona XtraDB 5.7.25.
PS: To run this test before we merge this PR to `main` you will need to
change step 2 (`Make sure to be on latest main`), instead of `main` use
this branch `15881-test-migrations-with-percona`.
Related to: https://github.com/fleetdm/fleet/issues/15089
Changes:
- Replaced the expired osquery Slack invitation with a link to the Fleet
website's `/slack` redirect.
---------
Co-authored-by: Mike McNeil <mikermcneil@users.noreply.github.com>
This new `:incoming` label is used by engineers to filter down to _new_
bugs on their sprint board during each standup. They will remove the
label, indicating they have triaged the issue.
QA removes `:reproduce`, EM removes `:incoming`.
- Move "Scalability testing" to Engineering section. Engineering team
will have a better idea if the story needs load testing
---------
Co-authored-by: Luke Heath <luke@fleetdm.com>
Per discussion with @noahtalerman and @marko-lisica today: we're going
to aim to always add redirects in `/website/config/routes.js` for any
docs/external pages we link to in the Fleet UI & CLI, to reduce surface
areas of PRs when doc headings change or things are moved around...
---------
Co-authored-by: Eric <eashaw@sailsjs.com>
Since a lot of bugs end up needing additional product design work, I
propose adding a (commented-out by default) section to this template to
standardize where to add design changes, once settled.
Reasoning: in estimation sessions, it can sometimes be hard to find this
information: sometimes it's in the comments, sometimes it's been added
to the description... either way, its not always obvious to spot. I
think it will help us move quicker if there's a consistent heading to
look for.
(Also, open to suggestions for other ways of wording that heading! This
is just the way I've been adding it to issue descriptions lately.)
- "Head of Product" => "Head of Product Design"
- #help-product => #help-product-design
- "Sprint kickoff review" is now one ritual that includes both MDM and
Endpoint ops teams
- "Pre-sprint prioritization" ritual is now one ritual that includes
both MDM and Endpoint ops teams
- Remove "Sprint release notes kickoff" ritual. Plan is to inform
#g-demand of new features asynchronously. Any discussion that needs to
happen live will happen at product office hours
- Remove "Report number of estimated stories (Endpoint ops))" and
"Report number of estimated stories (MDM)" rituals. One person (Head of
Product Design) is both reporting and tracking product KPIs
- Remove "Bug de-prioritization" ritual. Trying this instead: ~~CEO,~~
Head of Product Design, and Head of Product Development align on next
steps for which bugs to schedule into the next sprint and which can be
de-prioritized during the "Churned bug review" ritual. Less meetings.
---------
Co-authored-by: Mike McNeil <mikermcneil@users.noreply.github.com>
Slight shift in the template to focus more on the problems people are
facing. Helps us get to the root of issues without getting sidetracked
by suggested solutions.
---------
Co-authored-by: Mo Zhu <mo@fleetdm.com>
Co-authored-by: Mike McNeil <mikermcneil@users.noreply.github.com>
Feedback from team that it was not obvious that if you delete it, you
should assume it is free. Probably should not rely on that embedded
assumption going forward, esp. for new engineers.
---------
Co-authored-by: Mike McNeil <mikermcneil@users.noreply.github.com>
- Remove "Product quality" section from the template. @sabrinabuckets
and I think this might be redundant. Separate "QA" section asks for
testing steps and has a confirmation step.
Adding addition fields & re-ordering the Bugs template to facilitate
more robust bug reporting.
---------
Co-authored-by: Mike McNeil <mikermcneil@users.noreply.github.com>
There have been several tickets created for investigation or research
purposes like [this one ](https://github.com/fleetdm/fleet/issues/12904)
that we don't have a ticket type for within our current three types
(`story`, `~sub-task`, and `bug`). This results in the existing scrum
item types needing to be misused. I'm adding a fourth type called
`timebox` at Mike's request. I'm also including documentation on the
usage of this new type.
Lastly, I'm proposing we stop calling sub-tasks "unestimated sub-tasks"
in the GitHub template because it is confusing and inaccurate. Our
documentation states: "Sub-tasks are labeled as `~sub-task` and enable
us to break down complex tasks into more detailed and easier-to-estimate
work units.". In our estimation sessions, we put point estimates on
sub-tasks.
The spirit of this statement is that all sub-task points bubble up to
their parent story, and the parent story is what matters to the rest of
the business. That is clearly defined in our documentation and processes
and will not confuse our usage of stories.
---------
Co-authored-by: Mike McNeil <mikermcneil@users.noreply.github.com>
Based on our last product/eng sync. Slimming down the fields so it's
less daunting and separating the checkboxes into each department.
The expectation would be that each list is fully complete before passing
to the next step (product > engineering > product quality). ..
---------
Co-authored-by: Mike McNeil <mikermcneil@users.noreply.github.com>
Changes:
- I added links to "Writing a good user story" and "Quality" in the
website handbook.
- Fixed up a couple of things that Grammarly keeps reminding me about
when I create issues from this template.
Add step to ensure there are no release blocking tickets open that might
have gone missed.
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
- [x] Added/updated tests (smoke test template)
Add requestor to help keep track of who needs to be notified if a story
gets de-prioritized
.
---------
Co-authored-by: Mike McNeil <mikermcneil@users.noreply.github.com>
