Update links in source/handbook/engineering/development/.

parent 80b0d246
......@@ -12,7 +12,7 @@ title: Package Team
## Package Team
The Package team works on the part of GitLab concerning the [Package
stage], which integrates with [GitLab's CI/CD product](https://about.gitlab.com/direction/cicd).
stage], which integrates with [GitLab's CI/CD product](/direction/cicd/).
Our mission is to create a secure environment where both source code and dependencies can live by
allowing you to publish, consume, and discover packages of a large variety of languages and platforms
all in one place.
......
......@@ -14,7 +14,7 @@ title: "Release Team"
## Vision
For an understanding of what this team is going to be working on take a look at [the product
vision](/direction/release).
vision](/direction/release/).
## Mission
......@@ -43,7 +43,7 @@ Like most GitLab backend teams, we spend a lot of time working in Rails on the m
* [Issue Tracker](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Release)
* [Slack Channel](https://gitlab.slack.com/archives/g_release)
* [Roadmap](https://about.gitlab.com/direction/release)
* [Roadmap](/direction/release/)
## How to work with us
......@@ -53,7 +53,7 @@ Issues the Release team works on have the `~"Release"` label. Issues that contri
### Async Status Updates
Since we are a [remote](https://about.gitlab.com/company/culture/all-remote/) company, we utilize a Slack plugin called [Geekbot](https://geekbot.io/) to coordinate various status updates. There are currently 3 status updates configured in Geekbot, one is weekly and two are daily:
Since we are a [remote](/company/culture/all-remote/) company, we utilize a Slack plugin called [Geekbot](https://geekbot.io/) to coordinate various status updates. There are currently 3 status updates configured in Geekbot, one is weekly and two are daily:
#### Weekly Status Update
The **Weekly Status Update** is configured to run at noon on Fridays, and contains three questions:
......
......@@ -14,7 +14,7 @@ title: "Verify Team"
## Vision
For an understanding of what this team is going to be working on take a look at [the product
vision](/direction/verify).
vision](/direction/verify/).
## Mission
......
......@@ -30,7 +30,7 @@ The following members of other functional teams are our stable counterparts:
## Hiring
This chart shows the progress we're making on hiring. Check out our
[jobs page](https://about.gitlab.com/jobs/) for current openings.
[jobs page](/jobs/) for current openings.
<%= hiring_chart(department: 'Create:Editor BE Team') %>
......
......@@ -30,7 +30,7 @@ The following members of other functional teams are our stable counterparts:
## Hiring
This chart shows the progress we're making on hiring. Check out our
[jobs page](https://about.gitlab.com/jobs/) for current openings.
[jobs page](/jobs/) for current openings.
<%= hiring_chart(department: 'Create:Knowledge BE Team') %>
......
......@@ -30,7 +30,7 @@ The following members of other functional teams are our stable counterparts:
## Hiring
This chart shows the progress we're making on hiring. Check out our
[jobs page](https://about.gitlab.com/jobs/) for current openings.
[jobs page](/jobs/) for current openings.
<%= hiring_chart(department: 'Create:Source Code BE Team') %>
......
......@@ -18,7 +18,7 @@ stage] page.
[Plan stage]: /stages-devops-lifecycle/plan/
[Markdown rendering]: https://docs.gitlab.com/ee/user/markdown.html
[portfolio management features]: https://about.gitlab.com/product/agile-portfolio-management/
[portfolio management features]: /product/agile-portfolio-management/
## Team Members
......@@ -34,7 +34,7 @@ The following members of other functional teams are our stable counterparts:
### Hiring chart
This chart shows the progress we're making on hiring. Check out our
[jobs page](https://about.gitlab.com/jobs/) for current openings.
[jobs page](/jobs/) for current openings.
<%= hiring_chart(department: 'Plan FE Team') %>
......
......@@ -24,7 +24,7 @@ category](/handbook/product/categories/#dev). GitLab team-members can also use [
### How we work
* In accordance with our [GitLab values](https://about.gitlab.com/handbook/values/)
* In accordance with our [GitLab values](/handbook/values/)
* Transparently: nearly everything is public, we record/livestream meetings whenever possible
* We get a chance to work on the things we want to work on
* Everyone can contribute; no silos
......@@ -32,7 +32,7 @@ category](/handbook/product/categories/#dev). GitLab team-members can also use [
#### Planning
We plan in monthly cycles in accordance with our [Product Development Timeline](https://about.gitlab.com/handbook/engineering/workflow/#product-development-timeline).
We plan in monthly cycles in accordance with our [Product Development Timeline](/handbook/engineering/workflow/#product-development-timeline).
#### Prioritization
......@@ -47,7 +47,7 @@ Our planning process is reflected in boards that should always reflect our curre
| P3 | **Normal**: incremental improvements to existing features. These are important iterations, but deemed non-critical. | ~50% |
| P4 | **Low**: stretch issues that are acceptable to postpone into a future release. | ~25% |
You can read more about prioritization on the [direction page](https://about.gitlab.com/direction/manage/#how-we-prioritize) for the Manage stage of the DevOps lifecycle.
You can read more about prioritization on the [direction page](/direction/manage/#how-we-prioritize) for the Manage stage of the DevOps lifecycle.
#### Estimation
......@@ -90,7 +90,7 @@ Issues not already in development should be worked on in priority order.
#### Retrospectives
After the Kickoff, the Manage team conducts an [asynchronous retrospective](https://about.gitlab.com/handbook/engineering/management/team-retrospectives/) on the prior release. You can find current and past retrospectives for Manage in [https://gitlab.com/gl-retrospectives/manage/issues/](https://gitlab.com/gl-retrospectives/manage/issues/).
After the Kickoff, the Manage team conducts an [asynchronous retrospective](/handbook/engineering/management/team-retrospectives/) on the prior release. You can find current and past retrospectives for Manage in [https://gitlab.com/gl-retrospectives/manage/issues/](https://gitlab.com/gl-retrospectives/manage/issues/).
## Team Members
......
......@@ -36,7 +36,7 @@ This team is currently shared between Plan:Portfolio Management and
### Hiring chart
This chart shows the progress we're making on hiring. Check out our
[jobs page](https://about.gitlab.com/jobs/) for current openings.
[jobs page](/jobs/) for current openings.
<%= hiring_chart(department: 'Plan:Portfolio Management BE Team') %>
......
......@@ -38,7 +38,7 @@ stewardship of this API.
### Hiring chart
This chart shows the progress we're making on hiring. Check out our
[jobs page](https://about.gitlab.com/jobs/) for current openings.
[jobs page](/jobs/) for current openings.
<%= hiring_chart(department: 'Plan:Project Management BE Team') %>
......
......@@ -51,7 +51,7 @@ The following people are members of the Distribution Team:
### Stable counterparts
The following members of other functional teams are our [stable counterparts](https://about.gitlab.com/company/team/structure/#stage-groups):
The following members of other functional teams are our [stable counterparts](/company/team/structure/#stage-groups):
<%= stable_counterparts(role_regexp: /[,&] Distribution/, direct_manager_role: 'Engineering Manager, Distribution') %>
......
......@@ -139,7 +139,7 @@ If someone is asking for support in the omnibus-gitlab project, point them to th
```
Provided description seems to point to this issue not being related to this project. This can be the case when installation and `gitlab-ctl reconfigure` run went without issues, but your GitLab instance is still giving 500 error page with an error in the log.
For this reason, I will close this issue and you can check on [how to find further help](https://about.gitlab.com/get-help/) on the GitLab website.
For this reason, I will close this issue and you can check on [how to find further help](/get-help/) on the GitLab website.
/close
```
......
......@@ -28,7 +28,7 @@ For a quick overview of the architecture, see Geo [Architecture documentation](h
![Geo Diagram](geo_diagram.png)
This design was chosen after a few iterations. More background information is available on the [How we built GitLab Geo](https://about.gitlab.com/2018/09/14/how-we-built-gitlab-geo/) blog post.
This design was chosen after a few iterations. More background information is available on the [How we built GitLab Geo](/2018/09/14/how-we-built-gitlab-geo/) blog post.
#### Advantages
......
......@@ -26,7 +26,7 @@ repositories and projects, or can be part of a Disaster Recovery solution.
## Goals and Priorities
Our priorities are aligned with the product direction. You can read more about this on the [Geo Product Vision page](https://about.gitlab.com/direction/geo/).
Our priorities are aligned with the product direction. You can read more about this on the [Geo Product Vision page](/direction/geo/).
Alongside the items listed in our Product Vision, we need to constantly assess issues that our customers bring to our
attention. These could take the form of bug reports or feature requests. Geo users are often our largest
......@@ -71,7 +71,7 @@ Other Resources
- [Chat channel](https://gitlab.slack.com/archives/g_geo); please use the `#g_geo`
chat channel for questions that don't seem appropriate to use the issue tracker
for.
- [Product Support Requests](https://about.gitlab.com/handbook/product/#product-support-requests)
- [Product Support Requests](/handbook/product/#product-support-requests)
- Research Items : [Next Gen Geo](./2019-next-gen-geo.html)
## Planning and Process
......
......@@ -18,11 +18,11 @@ Offer the best operational experience of GitLab products from streamlined deploy
Enablement focuses on improving our capabilities and metrics in the following areas:
* [Distribution](/handbook/engineering/development/enablement/distribution)
* [Ecosystem](/handbook/engineering/development/enablement/ecosystem)
* [Geo (Disaster Recovery)](/handbook/engineering/development/enablement/geo)
* [Memory](/handbook/engineering/development/enablement/memory)
* [Search](/handbook/engineering/development/enablement/search)
* [Distribution](/handbook/engineering/development/enablement/distribution/)
* [Ecosystem](/handbook/engineering/development/enablement/ecosystem/)
* [Geo (Disaster Recovery)](/handbook/engineering/development/enablement/geo/)
* [Memory](/handbook/engineering/development/enablement/memory/)
* [Search](/handbook/engineering/development/enablement/search/)
## Section Members
......
......@@ -37,15 +37,15 @@ Where we can we follow the GitLab values and communicate asynchronously. Howeve
* Gitlab Development Week 1 New Hires Introductions - typically Wednesdays as new members join the team
## Work
We follow the GitLab [engineering workflow](https://about.gitlab.com/handbook/engineering/workflow/) guidelines. To bring an issue to our attention please [create an issue](https://about.gitlab.com/handbook/communication/#everything-starts-with-an-issue) in the relevant project, or in the [Memory team project](https://gitlab.com/gitlab-org/memory-team/team-tasks/issues/new?issue%5Bassignee_id%5D=&issue%5Bmilestone_id%5D=). Add the `~"group::memory"` label along with any other relevant labels. If it is an urgent issue, please reach out to the Product Manager or Engineering Manager listed in the [Stable Counterparts](https://about.gitlab.com/handbook/engineering/development/enablement/memory/#stable-counterparts) section above.
We follow the GitLab [engineering workflow](/handbook/engineering/workflow/) guidelines. To bring an issue to our attention please [create an issue](/handbook/communication/#everything-starts-with-an-issue) in the relevant project, or in the [Memory team project](https://gitlab.com/gitlab-org/memory-team/team-tasks/issues/new?issue%5Bassignee_id%5D=&issue%5Bmilestone_id%5D=). Add the `~"group::memory"` label along with any other relevant labels. If it is an urgent issue, please reach out to the Product Manager or Engineering Manager listed in the [Stable Counterparts](/handbook/engineering/development/enablement/memory/#stable-counterparts) section above.
### Planning
The Memory Team uses the [Memory by Milestone](https://gitlab.com/groups/gitlab-org/-/boards/1143987?label_name[]=group%3A%3Amemory) board to plan issues for each milestone.
We are adopting a lightweight weighting system, similar to those adopted by other teams.
* [Plan:Project Management BE Team Capacity Planning](https://about.gitlab.com/handbook/engineering/development/dev/plan-project-management-be/#capacity-planning)
* [Create: Source Code BE Team Weights](https://about.gitlab.com/handbook/engineering/development/dev/create-source-code-be/#weights)
* [Geo Team Weights](https://about.gitlab.com/handbook/engineering/development/enablement/geo/#weights)
* [Plan:Project Management BE Team Capacity Planning](/handbook/engineering/development/dev/plan-project-management-be/#capacity-planning)
* [Create: Source Code BE Team Weights](/handbook/engineering/development/dev/create-source-code-be/#weights)
* [Geo Team Weights](/handbook/engineering/development/enablement/geo/#weights)
Since we are a small team, each member is expected to comment on issue weight. Asking each member to estimate the weight will give the team a better understanding of the goals of the milestone, encourage communication around the issues, and lead to clarifying questions. If anyone feels they do not have enough information to comfortably apply a weight, they are encouraged to comment on the issues asking for more details. After feeback on issue weight has been gathered, the Engineering Manager is responsible to ensure that all issues within the milestone have a weight assigned.
......@@ -78,6 +78,6 @@ Anything larger than 5 should be broken down.
* [Memory Team subgroup](https://gitlab.com/gitlab-org/memory-team)
* [Retrospective page](https://gitlab.com/gl-retrospectives/memory-team)
* Slack Channel [#g_memory](https://gitlab.slack.com/messages/CGN8BUCKC)
* [Talent skills](https://about.gitlab.com/job-families/engineering/backend-engineer/#memory) that help the team
* [Product Development Timeline](https://about.gitlab.com/handbook/engineering/workflow/#product-development-timeline)
* [Talent skills](/job-families/engineering/backend-engineer/#memory) that help the team
* [Product Development Timeline](/handbook/engineering/workflow/#product-development-timeline)
......@@ -15,7 +15,7 @@ This page outlines the lightweight process of applying budget for professional d
## Scope
As described in [spending company money](https://about.gitlab.com/handbook/spending-company-money/), only expenses over $500 are subject to management approval. However, your manager should be informed regardless of the actual expense amount so it can be tracked for team budgeting purposes.
As described in [spending company money](/handbook/spending-company-money/), only expenses over $500 are subject to management approval. However, your manager should be informed regardless of the actual expense amount so it can be tracked for team budgeting purposes.
> Work-related online courses and professional development certifications. GitLab team members are allotted $500 USD per fiscal year to spend on one or multiple training courses. Reimbursement past the $500 USD total allotment requires manager approval.
......
......@@ -33,7 +33,7 @@ The following members of other functional teams are our stable counterparts:
## Meetings
## Work
We follow the GitLab [engineering workflow](https://about.gitlab.com/handbook/engineering/workflow/) guidelines. To bring an issue to our attention please [create an issue](https://about.gitlab.com/handbook/communication/#everything-starts-with-an-issue) in the relevant project. Add the `~"group::search"` label along with any other relevant labels. If it is an urgent issue, please reach out to the Product Manager or Engineering Manager listed in the [Stable Counterparts](https://about.gitlab.com/handbook/engineering/development/enablement/search/#stable-counterparts) section above.
We follow the GitLab [engineering workflow](/handbook/engineering/workflow/) guidelines. To bring an issue to our attention please [create an issue](/handbook/communication/#everything-starts-with-an-issue) in the relevant project. Add the `~"group::search"` label along with any other relevant labels. If it is an urgent issue, please reach out to the Product Manager or Engineering Manager listed in the [Stable Counterparts](/handbook/engineering/development/enablement/search/#stable-counterparts) section above.
### Planning
......
......@@ -19,7 +19,7 @@ Questions should start by @ mentioning the Product Manager for the [Activation g
### How we work
* We're data savvy
* In accordance with our [GitLab values](https://about.gitlab.com/handbook/values/)
* In accordance with our [GitLab values](/handbook/values/)
* Transparently: nearly everything is public
* We get a chance to work on the things we want to work on
* Everyone can contribute; no silos
......
......@@ -30,7 +30,7 @@ Fulfillment manages several product categories:
## How we work
* In accordance with our [GitLab values](https://about.gitlab.com/handbook/values/)
* In accordance with our [GitLab values](/handbook/values/)
* Transparently: nearly everything is public, we record/livestream meetings whenever possible
* We get a chance to work on the things we want to work on
* Everyone can contribute; no silos
......@@ -48,7 +48,7 @@ graph TD;
### Planning
We plan in monthly cycles in accordance with our [Product Development Timeline](https://about.gitlab.com/handbook/engineering/workflow/#product-development-timeline).
We plan in monthly cycles in accordance with our [Product Development Timeline](/handbook/engineering/workflow/#product-development-timeline).
Release scope for an upcoming release should be finalized by the `1st`.
On or around the `26th`: Product meets with Engineering Managers for a preliminary issue review. Issues are tagged with a milestone and are estimated initially.
......@@ -131,7 +131,7 @@ Any issues not merged on the current milestone post feature freeze, will need to
### Retrospectives
After the `8th`, the Fulfillment team conducts an [asynchronous retrospective](https://about.gitlab.com/handbook/engineering/management/team-retrospectives/). You can find current and past retrospectives for Fulfillment in [https://gitlab.com/gl-retrospectives/fulfillment/issues/](https://gitlab.com/gl-retrospectives/fulfillment/issues/).
After the `8th`, the Fulfillment team conducts an [asynchronous retrospective](/handbook/engineering/management/team-retrospectives/). You can find current and past retrospectives for Fulfillment in [https://gitlab.com/gl-retrospectives/fulfillment/issues/](https://gitlab.com/gl-retrospectives/fulfillment/issues/).
## Common links
......
......@@ -13,5 +13,5 @@ title: Fulfillment Group
Fulfillment consists of two Engineering teams:
* [Backend](/handbook/engineering/development/growth/be-fulfillment)
* [Frontend](/handbook/engineering/development/growth/fe-fulfillment)
\ No newline at end of file
* [Backend](/handbook/engineering/development/growth/be-fulfillment/)
* [Frontend](/handbook/engineering/development/growth/fe-fulfillment/)
\ No newline at end of file
......@@ -21,7 +21,7 @@ The Growth section consists of groups that eliminate barriers between our users
**Managing customer licensing and transactions**
The [Fulfillment](/handbook/engineering/development/growth/fulfillment) Group is responsible for:
The [Fulfillment](/handbook/engineering/development/growth/fulfillment/) Group is responsible for:
Licensing
- Seamless license compliance for customers and GitLab Team Members
......@@ -31,7 +31,7 @@ Transactions
**Deliver telemetry data that improves our product**
The [Telemetry](/handbook/engineering/development/growth/telemetry) Group is responsible for:
The [Telemetry](/handbook/engineering/development/growth/telemetry/) Group is responsible for:
Collection
- Collect information from GitLab.com and self-managed instances to improve our product
......@@ -46,20 +46,20 @@ Analysis
We focus on validating ideas with data across the following four Groups:
[Activation Group](/handbook/engineering/development/growth/activation)
[Activation Group](/handbook/engineering/development/growth/activation/)
- Get users off to a successful start
- Increase users completing key actions
[Adoption Group](/handbook/engineering/development/growth/adoption)
[Adoption Group](/handbook/engineering/development/growth/adoption/)
- Encourage cross-stage usage
- Increase Stage Monthly Active Users
[Upsell Group](/handbook/engineering/development/growth/upsell)
[Upsell Group](/handbook/engineering/development/growth/upsell/)
- Drive adoption of “higher” tiers
- Increase revenue per user/transaction
[Retention Group](/handbook/engineering/development/growth/retention)
[Retention Group](/handbook/engineering/development/growth/retention/)
- Get customers and users to return
- Increase gross retention
......
......@@ -17,8 +17,8 @@ Telemetry manages several product categories:
| Category | Description |
| ------ | ------ |
| [🧺 Collection](/direction/telemetry/collection) | The structure(s) and platform(s) of how we collect Telemetry data |
| [🔍 Analysis](/direction/telemetry/analysis) | Manages GitLab's internal needs for an analysis tool that serves the Product department |
| [🧺 Collection](/direction/telemetry/collection/) | The structure(s) and platform(s) of how we collect Telemetry data |
| [🔍 Analysis](/direction/telemetry/analysis/) | Manages GitLab's internal needs for an analysis tool that serves the Product department |
### Team members
......@@ -30,7 +30,7 @@ Telemetry manages several product categories:
### How we work
* In accordance with our [GitLab values](https://about.gitlab.com/handbook/values/)
* In accordance with our [GitLab values](/handbook/values/)
* Transparently: nearly everything is public, we record/livestream meetings whenever possible
* We get a chance to work on the things we want to work on
* Everyone can contribute; no silos
......@@ -48,7 +48,7 @@ graph TD;
#### Planning
We plan in monthly cycles in accordance with our [Product Development Timeline](https://about.gitlab.com/handbook/engineering/workflow/#product-development-timeline).
We plan in monthly cycles in accordance with our [Product Development Timeline](/handbook/engineering/workflow/#product-development-timeline).
Release scope for an upcoming release should be finalized by the `1st`.
On or around the `26th`: Product meets with Engineering Managers for a preliminary issue review. Issues are tagged with a milestone and are estimated initially.
......@@ -103,7 +103,7 @@ These are:
#### Retrospectives
After the `8th`, the Telemetry team conducts an [asynchronous retrospective](https://about.gitlab.com/handbook/engineering/management/team-retrospectives/).
After the `8th`, the Telemetry team conducts an [asynchronous retrospective](/handbook/engineering/management/team-retrospectives/).
## Common links
......
......@@ -19,13 +19,13 @@ The development team strives to deliver product requirements fast, resolve custo
The development team is responsible for developing products in the following categories:
* [CI/CD](https://about.gitlab.com/handbook/engineering/development/ci-cd/)
* [Defend](https://about.gitlab.com/handbook/engineering/development/defend/)
* [Dev](https://about.gitlab.com/handbook/engineering/development/dev/)
* [Enablement](https://about.gitlab.com/handbook/engineering/development/enablement/)
* [Growth](https://about.gitlab.com/handbook/engineering/development/growth/)
* [Ops](https://about.gitlab.com/handbook/engineering/development/ops/)
* [Secure](https://about.gitlab.com/handbook/engineering/development/secure/)
* [CI/CD](/handbook/engineering/development/ci-cd/)
* [Defend](/handbook/engineering/development/defend/)
* [Dev](/handbook/engineering/development/dev/)
* [Enablement](/handbook/engineering/development/enablement/)
* [Growth](/handbook/engineering/development/growth/)
* [Ops](/handbook/engineering/development/ops/)
* [Secure](/handbook/engineering/development/secure/)
## Team Members
......@@ -52,8 +52,8 @@ The following members of other functional teams are our stable counterparts:
Welcome to GitLab! We are excited for you to join us.
Here are some curated resources to get you started:
* [Joining as an Engineer](/handbook/engineering/development/onboarding/engineer)
* [Joining as an Engineering Manager](/handbook/engineering/development/onboarding/manager)
* [Joining as an Engineer](/handbook/engineering/development/onboarding/engineer/)
* [Joining as an Engineering Manager](/handbook/engineering/development/onboarding/manager/)
### Cross Functional Collaboration
......@@ -66,9 +66,9 @@ Note: once the label is added, the issue will also appear on the [development de
### Development Headcount planning
Development's headcount planning follows the Engineering [headcount planning](https://about.gitlab.com/handbook/engineering/#headcount-planning) and [long term profitability targets](https://about.gitlab.com/handbook/engineering/#long-term-profitability-targets). Development headcount is a percentage of overall engineering headcount. For FY20, the headcount size is 271 or ~58% of overall engineering headcount.
Development's headcount planning follows the Engineering [headcount planning](/handbook/engineering/#headcount-planning) and [long term profitability targets](/handbook/engineering/#long-term-profitability-targets). Development headcount is a percentage of overall engineering headcount. For FY20, the headcount size is 271 or ~58% of overall engineering headcount.
We follow normal span of control both for our managers and directors of [4 to 10](https://about.gitlab.com/handbook/leadership/#management-group). Our sections and groups match as closely as we can to the DevOps Stages to best map 1:1 to [Product Managers](https://about.gitlab.com/handbook/product/).
We follow normal span of control both for our managers and directors of [4 to 10](/handbook/leadership/#management-group). Our sections and groups match as closely as we can to the DevOps Stages to best map 1:1 to [Product Managers](/handbook/product/).
## Continuous Delivery, Infrastructure and Quality Collaboration
......
......@@ -12,10 +12,10 @@ title: Configure Team
## Vision
For an understanding of where this team is going take a look at [the product
vision](/direction/configure).
vision](/direction/configure/).
As a member of the Ops Section you may also like to understand [our
overall vision](https://about.gitlab.com/direction/ops/).
overall vision](/direction/ops/).
## Mission
......@@ -25,7 +25,7 @@ lifecycle. These refer to configuration of infrastructure as well as running
applications that are deployed via GitLab.
This team is currently building out more features for our Kubernetes integration
including the [Auto DevOps](/auto-devops) feature set and making it easier for
including the [Auto DevOps](/auto-devops/) feature set and making it easier for
GitLab users to make the most of Kubernetes and DevOps best practices.
As per the [product categories](/handbook/product/categories/) this team
......
......@@ -48,7 +48,7 @@ Current group focus:
### Backend & Frontend Issue Collaboration
Our team follows the GitLab [workflow guidelines for working in teams](https://about.gitlab.com/handbook/engineering/workflow/#working-in-teams).
Our team follows the GitLab [workflow guidelines for working in teams](/handbook/engineering/workflow/#working-in-teams).
Given a reasonable sized issue, that requires UX, frontend and backend work, the preferred way to collaborate on the issue is as follow:
1. Once an issue is labeled, `workflow::ready for development` , backend is usually able to start working on the issue.
......
......@@ -57,7 +57,7 @@ Recommended process for adding new metrics:
### Milestone Planning
In planning a milestone, the engineering and product team work closely together. We do follow the [Engineering Workflow](https://about.gitlab.com/handbook/engineering/workflow) and specifically the [Product Development Timeline](https://about.gitlab.com/handbook/engineering/workflow/#product-development-timeline) when planning a milestone. However, here is some additional information that may help in the planning process.
In planning a milestone, the engineering and product team work closely together. We do follow the [Engineering Workflow](/handbook/engineering/workflow/) and specifically the [Product Development Timeline](/handbook/engineering/workflow/#product-development-timeline) when planning a milestone. However, here is some additional information that may help in the planning process.
For APM we use the [APM Planning Board](https://gitlab.com/groups/gitlab-org/-/boards/1065731?label_name[]=group%3A%3Aapm) to do milestone planning and to prioritize our backlog. Here is what we do to keep that board up-to-date:
......@@ -66,7 +66,7 @@ For APM we use the [APM Planning Board](https://gitlab.com/groups/gitlab-org/-/b
* Responsible: Engineering Managers with input from the engineering teams
1. Organize the upcoming release column by priority.
* Due Date: First day of the month. *Note*: this aligns with the [Product Development Timeline](https://about.gitlab.com/handbook/engineering/workflow/#product-development-timeline)
* Due Date: First day of the month. *Note*: this aligns with the [Product Development Timeline](/handbook/engineering/workflow/#product-development-timeline)
* Responsible: Product Manager
1. Apply the [Deliverable](https://docs.gitlab.com/ee/development/contributing/issue_workflow.html#release-scoping-labels) label to the top items in the upcoming milestone that will be completed. These should be the top priority items that are almost sure to be completed by the end of the upcoming milestone.
......
......@@ -67,4 +67,4 @@ The development of these assigned issues should not typically last the entire re
> The frontend group also has a kickoff issue each release to help frontend engineers get visibilty to the work of other frontend engineers asynchronously. In this issue, it is recommended to only comment on the assigned issues as those are the primary issues that the team has committed to at the time of the kickoff issue.
## Monitor Stage PTO
Just like the rest of the company, we use [PTO Ninja](https://about.gitlab.com/handbook/paid-time-off/#pto-ninja) to track when team members are traveling, attending conferences, and taking time off. The easiest way to see who has upcoming PTO is to run the `/ninja whosout` command in the `#g_monitor_standup` slack channel. This will show you the upcoming PTO for everyone in that channel.
Just like the rest of the company, we use [PTO Ninja](/handbook/paid-time-off/#pto-ninja) to track when team members are traveling, attending conferences, and taking time off. The easiest way to see who has upcoming PTO is to run the `/ninja whosout` command in the `#g_monitor_standup` slack channel. This will show you the upcoming PTO for everyone in that channel.
......@@ -64,7 +64,7 @@ When new bugs are reported, the engineering managers ensure that they have prope
### Interacting with community contributors
Community contributions are encouraged and prioritized at GitLab. Please check out the [Contribute page](/community/contribute) on our website for guidelines on contributing to GitLab overall.
Community contributions are encouraged and prioritized at GitLab. Please check out the [Contribute page](/community/contribute/) on our website for guidelines on contributing to GitLab overall.
Within the Monitor stage, Product Management will assist a community member with questions regarding priority and scope. If a community member has technical questions on implementation, Engineering Managers will connect them with engineers within the team to collaborate with.
......@@ -138,12 +138,12 @@ While we try to keep our process pretty light on meetings, we do have a few recu
There is also an optional Monitor Social Hour meeting every week. This call has no agenda and alternates times every other week to be more inclusive of team members in different time zones.
## Retrospective
We follow the same retrospective process as the rest of the engineering department, which [can be found here](https://about.gitlab.com/handbook/engineering/management/team-retrospectives/).
We follow the same retrospective process as the rest of the engineering department, which [can be found here](/handbook/engineering/management/team-retrospectives/).
To encourage a more iterative retrospective process, we create a new retrospective issue at the beginning of each milestone, using the [Monitor retrospective template](https://gitlab.com/gl-retrospectives/monitor/blob/master/.gitlab/issue_templates/Retrospective.md). We leave this issue open for the duration of the milestone so any team member can add feedback as it happens instead of waiting until the end of the milestone.
## Monitor Stage PTO
Just like the rest of the company, we use [PTO Ninja](https://about.gitlab.com/handbook/paid-time-off/#pto-ninja) to track when team members are traveling, attending conferences, and taking time off. The easiest way to see who has upcoming PTO is to run the `/ninja whosout` command in the `#g_monitor_standup` slack channel. This will show you the upcoming PTO for everyone in that channel.
Just like the rest of the company, we use [PTO Ninja](/handbook/paid-time-off/#pto-ninja) to track when team members are traveling, attending conferences, and taking time off. The easiest way to see who has upcoming PTO is to run the `/ninja whosout` command in the `#g_monitor_standup` slack channel. This will show you the upcoming PTO for everyone in that channel.
## Useful Resources
......
......@@ -147,7 +147,7 @@ Mute all other channels but the escalation channel during a specific time period
**Q: Isn’t this more about discipline of seeing incidents through to resolution, not just how quickly we respond to them? It feels the on-call process addresses the latter, but not former.**
**A:** It’s actually both and we are working to address both. We have also added a Infra/Dev issue board to track concerns to see through to resolution and make sure we have the right priority and severity on them. It’s likely that oncall escalations will end up with follow on items for [this board](https://gitlab.com/groups/gitlab-org/-/boards/1193197?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=gitlab.com&label_name[]=infradev). [This page](https://about.gitlab.com/handbook/engineering/development/#continuous-delivery-and-infrastructure-collaboration) gives the description.
**A:** It’s actually both and we are working to address both. We have also added a Infra/Dev issue board to track concerns to see through to resolution and make sure we have the right priority and severity on them. It’s likely that oncall escalations will end up with follow on items for [this board](https://gitlab.com/groups/gitlab-org/-/boards/1193197?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=gitlab.com&label_name[]=infradev). [This page](/handbook/engineering/development/#continuous-delivery-and-infrastructure-collaboration) gives the description.
**Q: If we have an alternative suggestion, should we put together an MR in the same location as the current location? When are you looking to conclude on this? (How long have we got to propose an alternative)?**
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment