Commit 8a01f8fa authored by Sid Sijbrandij's avatar Sid Sijbrandij

Merge branch 'msp-refine-enablement' into 'master'

Refine enablement

See merge request !18033
parents 483326d6 4a44e73e
Pipeline #43135423 passed with stages
in 13 minutes and 59 seconds
......@@ -1214,11 +1214,11 @@ ueba:
roi: false
available: 2019-12-22
# Admin
# Enablement
omnibus:
name: Omnibus
stage: admin
stage: enablement
alt_link: https://docs.gitlab.com/omnibus/
documentation: https://docs.gitlab.com/omnibus/
roi: false
......@@ -1226,7 +1226,7 @@ omnibus:
cloud_native_installation:
name: Cloud Native Installation
stage: admin
stage: enablement
alt_link: https://docs.gitlab.com/ee/install/kubernetes/
documentation: https://docs.gitlab.com/ee/install/kubernetes/
roi: false
......@@ -1234,7 +1234,7 @@ cloud_native_installation:
license_sync:
name: License Sync
stage: admin
stage: enablement
alt_link: https://gitlab.com/groups/gitlab-org/-/epics/456
vision: https://gitlab.com/groups/gitlab-org/-/epics/456
roi: false
......@@ -1242,24 +1242,82 @@ license_sync:
license_gitlab_com:
name: license.gitlab.com
stage: admin
stage: enablement
roi: false
available: 2017-01-01
version_gitlab_com:
name: version.gitlab.com
stage: admin
stage: enablement
roi: false
available: 2017-01-01
customers_gitlab_com:
name: customers.gitlab.com (Subscription portal)
stage: admin
stage: enablement
roi: false
available: 2017-01-01
usage_data:
name: Usage data
stage: admin
stage: enablement
roi: false
available: 2017-01-01
geo:
name: Geo
stage: enablement
alt_link: https://about.gitlab.com/solutions/geo/
roi: false
available: 2018-01-01
gitaly:
name: Gitaly
stage: enablement
alt_link: https://gitlab.com/gitlab-org/gitaly
description: "Gitaly is a Git RPC service for handling all the git calls made by GitLab."
roi: false
available: 2018-01-01
gitter:
name: Gitter
stage: enablement
alt_link: https://gitter.im/
roi: false
available: 2018-01-01
api:
name: API
stage: enablement
alt_link: https://docs.gitlab.com/ee/api/
roi: false
available: 2017-01-01
graphql:
name: GraphQL API
stage: enablement
alt_link: https://docs.gitlab.com/ee/api/graphql/
roi: false
available: 2018-01-01
realtime:
name: Realtime
stage: enablement
description: "GitLab has rudimentary realtime features, and we need to evolve to include proper push-based realtime for (nearly) everything."
roi: false
available: 2018-01-01
search:
name: Search
stage: enablement
description: "The Advanced Global Search in GitLab is a powerful search service that saves you time. Instead of creating duplicate code and wasting time, you can now search for code within other teams that can help your own project. GitLab leverages the search capabilities of Elasticsearch"
alt_link: https://docs.gitlab.com/ee/user/search/advanced_global_search.html
roi: false
available: 2017-01-01
service_integrations:
name: Service Integrations
stage: enablement
alt_link: https://docs.gitlab.com/ee/user/project/integrations/
roi: false
available: 2017-01-01
......@@ -227,7 +227,6 @@ stages:
- review_apps
- feature_flags
configure:
display_name: "Configure"
image: "/images/solutions/solutions-configure.png"
......@@ -408,14 +407,12 @@ stages:
# categories:
# - data_loss_prevention
admin:
display_name: Admin
enablement:
display_name: Enablement
dept: enablement
related:
- "create"
internal_customers:
- Quality Department
- Infrastructure Department
established: 2012
groups:
distribution:
name: Distribution
......@@ -434,6 +431,9 @@ stages:
categories:
- omnibus
- cloud_native_installation
internal_customers:
- Quality Department
- Infrastructure Department
sync:
name: Sync
display_name: Sync
......@@ -464,42 +464,56 @@ stages:
frontend_engineering_manager: André Luís (Interim)
ux: Dimitrie Hoekstra
tech_writer: Evan Read
gitaly_and_gitter:
display_name: "Gitaly and Gitter"
image: "/images/solutions/solutions-gitaly.png"
description: "Add Gitaly and Gitter description here"
body: |
GitLab makes Gitaly and Gitter
vision: /direction/gitaly
roadmap: "https://gitlab.com/groups/gitlab-org/-/roadmap?label_name[]=devops%3Adistribution&scope=all&sort=end_date_asc&state=opened&layout=QUARTERS"
established: 2012
related:
- "create"
dept: enablement
pm: James Ramsay
pmm: John Jeremiah
engineering_manager: Tommy (interim)
frontend_engineering_manager: Tim Z (Interim)
ux: Dimitrie Hoekstra
tech_writer: Axil
internal_customers:
- Quality Department
- Infrastructure Department
growth:
display_name: "[Growth](growth-team/)"
pm: Tamas Szuromi
engineering_manager: Liam McAndrew
frontend_engineering_manager: Dennis Tang (Interim)
dept: enablement
system:
display_name: System
dept: enablement
description: "Supporting GitLab components that are behind the stages or shared between many stages without having directly user-facing impact."
ecosystem:
display_name: Ecosystem
dept: enablement
description: "Supporting the success of third-party products integrating with GitLab."
categories:
- geo
gitaly:
name: "Gitaly"
image: "/images/solutions/solutions-gitaly.png"
description: "Gitaly is a Git RPC service for handling all the git calls made by GitLab."
body: |
GitLab makes Gitaly
vision: /direction/gitaly
roadmap: "https://gitlab.com/groups/gitlab-org/-/roadmap?label_name[]=devops%3Adistribution&scope=all&sort=end_date_asc&state=opened&layout=QUARTERS"
related:
- "create"
dept: enablement
pm: James Ramsay
pmm: John Jeremiah
engineering_manager: Tommy (interim)
frontend_engineering_manager: Tim Z (Interim)
ux: Dimitrie Hoekstra
tech_writer: Axil
internal_customers:
- Quality Department
- Infrastructure Department
categories:
- gitaly
gitter:
name: Gitter
pm: James Ramsay
pmm: John Jeremiah
engineering_manager: Tommy (interim)
frontend_engineering_manager: Tim Z (Interim)
ux: Dimitrie Hoekstra
tech_writer: Axil
categories:
- gitter
growth:
name: "[Growth](growth-team/)"
pm: Tamas Szuromi
engineering_manager: Liam McAndrew
frontend_engineering_manager: Dennis Tang (Interim)
dept: enablement
system:
name: System
description: "Supporting GitLab components that are behind the stages or shared between many stages without having directly user-facing impact."
categories:
- api
- graphql
- realtime
- search
ecosystem:
name: Ecosystem
description: "Supporting the success of third-party products integrating with GitLab."
categories:
- service_integrations
......@@ -140,26 +140,26 @@ Inspired by:
## How to work as/with product
At GitLab, the PMs lead their specialization. That is, the Platform PM decides
what the platform team works on, for which release, and makes sure
this furthers our goals. This includes bugs, features, and architectural changes.
At GitLab, the PMs lead their specialization. That is, the Create PM decides
what the Create group works on, for which release, and makes sure this furthers
our goals. This includes bugs, features, and architectural changes.
The PM can't be expected to parse every single bug or issue that comes by, so
they have to rely heavily on the input of the various stakeholders. To be
able to achieve this, both the PM and the stakeholders have to actively work
they have to rely heavily on the input of the various stakeholders. To be able
to achieve this, both the PM and the stakeholders have to actively work
together. It's a two-way street.
In general terms, if you require something to happen with the product or if you
need engineering staff for a particular change, you approach a PM.
Preferably through creating an issue (the GitLab way), and mentioning them there.
need engineering staff for a particular change, you approach a PM. Preferably
through creating an issue (the GitLab way), and mentioning them there.
In the same vein, PMs are required to ask for feedback from the stakeholder of
particular changes. If a change will affect GitLab.com and its maintenance, a
PM should proactively reach out to infrastructure engineers to help with the
scope, design, and decisions regarding this change.
particular changes. If a change will affect GitLab.com and its maintenance, a PM
should proactively reach out to infrastructure engineers to help with the scope,
design, and decisions regarding this change.
It is then up to the PM to weigh all these inputs and decide on a
[prioritization](#prioritization). It is to be expected that they are the best equipped to make this
It is then up to the PM to weigh all these inputs and decide on a [prioritization](#prioritization).
It is to be expected that they are the best equipped to make this
prioritization, while also keeping in mind all goals of GitLab.
### Examples: A customer has a feature request
......@@ -174,7 +174,8 @@ A salesperson for an organization asking for a paid-tier feature request shall
work with the product manager to arrange conversations to further explore the
feature request and desired outcome. The process will be:
* Sales schedules 1 hour zoom meeting with product manager, customer and themselves. Call recorded if customer gives permission.
* Sales schedules 1 hour zoom meeting with product manager, customer, and
themselves. Call recorded if customer gives permission.
* Product Manager prepares any additional questions they would like answered, beyond what is below.
* What version of GitLab are you currently using? CE / Starter / Premium?
* How are you currently doing source code management? GitLab merge requests or another tool? How about CI/CD?
......@@ -187,22 +188,28 @@ feature request and desired outcome. The process will be:
* Sales and product manager schedule 15 minute pre-meeting to share what we know about the customer thus far, so as to not waste time asking questions we already know the answer to. Notes from this pre-meeting are added to the Google document.
* Sales adds a link to the Google document under the account object as a note.
In the event that an EE customer is willing to pay for us to develop a specific feature, we should still respond as above. It's great that they're willing to pay for it: that means they really need it. However, we will not make a custom version of GitLab; even gitlab.com is running on EE, and we move faster that way by minimizing technical complexity to determine features to follow after, it’s a trade off to make. This doesn’t mean that "no" is always going to stay "no." We keep an open mind for improvements.
In the event that a paid customer is willing to pay for us to develop a specific
feature, we should still respond as above. It's great that they're willing to
pay for it: that means they really need it. However, we will not make a custom
version of GitLab; even gitlab.com is running on GitLab Ultimate, and we move
faster that way by minimizing technical complexity to determine features to
follow after, it’s a trade off to make. This doesn’t mean that "no" is always
going to stay "no." We keep an open mind for improvements.
### Example: Many support requests come in about a bug with CI
Same as before, make sure an issue is made and make your case with Mark that
this is becoming a problem and needs to be fixed. Mark will make sure that this
is fixed or resolved in some other way.
Same as before, make sure an issue is made and make your case with the PM that
this is becoming a problem and needs to be fixed. The PM will make sure that
this is fixed or resolved in some other way.
### Example: I think creating new files is slow
Everything in GitLab should be fast and creating files falls under the
repository, so you create an issue and make James aware of it by mentioning it.
repository, so you create an issue and make the PM aware of it by mentioning it.
James in turn will investigate whether this is a general problem or one specific
to GitLab.com, in collaboration with infrastructure and others and schedule any
necessary changes for an upcoming release.
The PM in turn will investigate whether this is a general problem or one
specific to GitLab.com, in collaboration with infrastructure and others and
schedule any necessary changes for an upcoming release.
## Product Process
......
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