Commit 190e30aa authored by Cynthia "Arty" Ng's avatar Cynthia "Arty" Ng
Browse files

Update markdownlint and fix biztech folder

parent b02624ba
Loading
Loading
Loading
Loading
+1 −5
Original line number Diff line number Diff line
@@ -5,26 +5,22 @@
  ],
  "config": {
    "default": true,
    "blanks-around-lists": false,
    "code-block-style": { "style": "fenced" },
    "first-header-h1": false,
    "first-line-h1": false,
    "line-length": false,
    "header-style": { "style": "atx" },
    "heading-increment": false,
    "hr-style": { "style": "---" },
    "line-length": false,
    "no-bare-urls": false,
    "no-duplicate-heading": { "siblings_only": true },
    "no-emphasis-as-heading": false,
    "no-inline-html": false,
    "no-multiple-blanks": false,
    "no-trailing-punctuation": { "punctuation": ".,;:!。,;:!?" },
    "ul-indent": false
  },
  "fix": true,
  "ignores": [
    "layouts/**",
    "content/handbook/business-technology/**/*.md",
    "content/handbook/customer-success/**/*.md",
    "content/handbook/engineering/**/*.md",
    "content/handbook/marketing/**/*.md",
+0 −3
Original line number Diff line number Diff line
@@ -37,7 +37,6 @@ Our backlog should be prioritized on an ongoing basis. Prioritization will be do

The DRIs of these three core areas will work collaboratively to ensure the overall prioritization of the backlog is in alignment with [section direction](https://about.gitlab.com/direction/#devops-stages) or any other necessary product and business needs. If a team is not assigned a Product Designer then there is no UX counterpart needed for prioritization purposes. PMs will prioritize the final plan for a given milestone.


#### Planning for the milestone

The Product Manager is responsible for planning each milestone. Product Managers are also responsible for ensuring that their team's target ratios are maintained over time.
@@ -48,7 +47,6 @@ The Product Manager is responsible for planning each milestone. Product Managers
   1. Conversly, teams with more mature product categories may have more maintence work.
1. Sequencing of work within the milestone should reflect that we [plan ambitiously](/handbook/product/product-principles/#how-this-impacts-planning). This means not every issue will be delivered. Be aware that this can skew your ratios over time if subsequent milestones are not properly re-balanced.


Add the `milestone` ([example](https://gitlab.com/groups/gitlab-org/-/boards/4309441?label_name[]=group%3A%3Athreat%20insights&milestone_title=15.1)) to review the milestone plan. The board will show the number of issues and cumulative issue weights for `type::feature`, `type::maintenance`, and `type::bug` issues.

#### Cross-Functional Dashboard Reviews
@@ -128,7 +126,6 @@ The collaboration should be async first but include an optional sync review amon

The name of the meeting and associated agenda document should be clearly defined so that the invitees can decide if they should attend.


##### Company-wide review

The company-wide review is coordinated by the VP of Development.
+1 −2
Original line number Diff line number Diff line
@@ -11,6 +11,7 @@ Unless it is listed in this table, the Engineering Allocation for a stage/group
During an Engineering Allocation, the EM is responsible for recognizing the problem, creating a satisfactory goal with clear success criteria, developing a plan, executing on a plan and reporting status.  It is recommended that the EM collaborate with PMs in all phases of this effort as we want PMs to feel ownership for these challenges.  This could include considering adding more/less allocation, setting the goals to be more aspirational, reviewing metrics/results, etc.   We welcome strong partnerships in this area because we are one team even when allocations are need to resolving issues critical to our business.

During periods of Engineering Allocation, the PM remains the interface between the group and the fields teams & customers. This is important because:

- It allows Engineering to remain focused on the work at hand
- It maintains continuity for the field teams - they should not have to figure out different patterns of communication for the customer
- It keeps PMs fully informed about the product's readiness
@@ -29,7 +30,6 @@ Each allocation has a [direction page](/handbook/product/product-processes/#mana

To see an example for an Engineering Allocation Direction page, see [Continuous Integration Scaling](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/source/direction/verify/continuous_integration_scaling/index.html.md). Once the Engineering Allocation is complete, delete the direction page.


#### How to get a effort added to Engineering Allocation

One of the most frequent questions we get as part of this experiment is "How does a problem get put on the Engineering Allocation list?".  The short answer is someone makes a suggestion and we add it.  Much like everyone can contribute, we would like the feedback loop for improvement and long terms goals to be robust.  So everyone should feel the empowerment to suggest an item at any time.
@@ -41,7 +41,6 @@ To help with getting items that on the list for consideration, we will be perfor

We will keep the list of questions short to solicit the most input.  The survey will go out to members of the Development, Quality, Security.  After we get the results, we will consider items for potential adding as an Engineering Allocation.


#### Closing out Engineering Allocation items

Once the item's success criteria are achieved, the Engineering Manager should consult with counterparts to review whether the improvements are sustainable. Where appropriate, we should consider adding monitoring and alerting to any areas of concern that will allow us to make proactive prioritizations in future should the need arise. The Engineering Manager should close all related epics/issues, reset the allocation in the above table to the floor level, and inform the Product Manager when the allocated capacity will be available to return their focus to product prioritizations.
+0 −1
Original line number Diff line number Diff line
<%# ##### Development %>
<%# No differences between engineering and Development senior leadership competencies %>
+0 −2
Original line number Diff line number Diff line
@@ -20,7 +20,6 @@ Additional benefits to GitLab:

We are looking for companies interested in helping deliver on our [vision](https://about.gitlab.com/direction/#vision) to create a single application for the entire DevOps lifecycle. We value strong teams and technology and are looking for a combination of both that will help us accelerate our roadmap. We're looking for acquisitions which can either present a strategic value-add or create potential for significant revenue upside.


## Acquisition target profile

Below is a set of general, yet not strict, characteristics of companies that are a potential fit for our acquisition process:
@@ -38,7 +37,6 @@ according to our [category maturity](https://about.gitlab.com/direction/maturity
- Aligned to ship on the first month and iterate quickly
- Strong founders looking to join GitLab


## Considering joining forces with GitLab

1. Please review our [handbook](/handbook/); it is the central repository for how we run the company.
Loading