mirror of
https://github.com/fleetdm/fleet
synced 2026-05-23 17:08:53 +00:00
parent
4f0a2e2af9
commit
ca15cbe3bb
1 changed files with 8 additions and 8 deletions
|
|
@ -56,18 +56,18 @@ At Fleet, like [GitLab](https://about.gitlab.com/handbook/product-development-fl
|
|||
3. Add page names (e.g. "Host details" page) to the user story's title and/or description to help contributors find Figma wireframes for the area of the UI you're making changes to.
|
||||
|
||||
4. If the story requires API or YAML file changes, open a pull request (PR) to the reference docs with the proposed design. Pay attention to existing conventions (URL structure, parameter names, response format) and aim to be consistent. Your PR should follow these guidelines:
|
||||
- Make a PR against the docs release branch for the version you expect this feature to be in. Docs release branches are named using the format `docs-vX.X.X`, so if you're designing for Fleet 4.61.0, you would make a PR to `docs-v4.61.0`.
|
||||
- Add a link to the issue in the PR description.
|
||||
- Attach the `~api-or-yaml-design` label.
|
||||
- Mark the PR ready for review. (Draft PRs do not auto-request reviews.)
|
||||
- After your changes are approved by the API design DRI, they will merge your changes into the docs release branch.
|
||||
- Make a PR against the docs release branch for the version you expect this feature to be in. Docs release branches are named using the format `docs-vX.X.X`, so if you're designing for Fleet 4.61.0, you would make a PR to `docs-v4.61.0`.
|
||||
- Add a link to the issue in the PR description.
|
||||
- Attach the `~api-or-yaml-design` label.
|
||||
- Mark the PR ready for review. (Draft PRs do not auto-request reviews.)
|
||||
- After your changes are approved by the API design DRI, they will merge your changes into the docs release branch.
|
||||
|
||||
5. Add links to the user story as specified in the [issue template](https://github.com/fleetdm/fleet/issues/new?template=story.md).
|
||||
|
||||
6. Draft changes to the Fleet product that solve the problem specified in the story.
|
||||
- Constantly place yourself in the shoes of a user while drafting changes.
|
||||
- Use dev notes (component available in our library) to highlight important information to engineers and other teammates. - Reach out to sales, customer success, and demand for a business perspective.
|
||||
- Engage engineering to gain insight into technical costs and feasibility.
|
||||
- Constantly place yourself in the shoes of a user while drafting changes.
|
||||
- Use dev notes (component available in our library) to highlight important information to engineers and other teammates. - Reach out to sales, customer success, and demand for a business perspective.
|
||||
- Engage engineering to gain insight into technical costs and feasibility.
|
||||
|
||||
Additionally:
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue