@@ -68,7 +68,7 @@ Sid is easy to talk to on any subject. He is good at drawing people out and chal
1. Sid is also the driving force for our iteration value. For example, he holds [Iteration Office Hours](#iteration-office-hours).
1. Sid really values 1:1 preparation.
1. Sid believes in “strong opinions, weakly held.” He doesn’t always seem like it, but he will change his mind quickly if you present him with compelling new information and a data driven perspective.
1. Sid loves naming things, and strongly believes in the power of clear language. Learn and use (and add to) our terminology e.g. `It’s not a “best practice”, it’s a “boring solution”`. The [product categories](https://about.gitlab.com/handbook/product/categories/) page is a good example. Sid advocates for using [MECEFU terms]({{<ref"communication#mecefu-terms">}}) to keep communication efficient.
1. Sid loves naming things, and strongly believes in the power of clear language. Learn and use (and add to) our terminology e.g. `It’s not a “best practice”, it’s a “boring solution”`. The [product categories](/handbook/product/categories/) page is a good example. Sid advocates for using [MECEFU terms]({{<ref"communication#mecefu-terms">}}) to keep communication efficient.
@@ -144,7 +144,7 @@ GitLab Product Designers are responsible for reviews and guidance and should not
**Process**
Once a Product Designer gets pinged on an issue that JiHu intends to contribute upstream, the Product Designer reviews whether that issue already has a clear proposal that does not conflict with our [Pajamas guidelines](https://design.gitlab.com), the [Product principles](https://about.gitlab.com/handbook/product/product-principles) or planned work of their team.
Once a Product Designer gets pinged on an issue that JiHu intends to contribute upstream, the Product Designer reviews whether that issue already has a clear proposal that does not conflict with our [Pajamas guidelines](https://design.gitlab.com), the [Product principles](/handbook/product/product-principles) or planned work of their team.
If there is no clear design proposal yet, or there are conflicts with Pajamas or the Product principles, the designer leaves a comment about what is required before the issue should go into implementation.
@@ -165,7 +165,7 @@ In the interest of creating IP, JiHu will take on larger product initiatives tha
GitLab Product Managers are not responsible for JiHu product decisions, but collaboration and feedback with JiHu Product Managers is encouraged and appreciated.
- Just like [PMs aren't the arbiters of community contribution](https://about.gitlab.com/handbook/product/product-processes/#gitlab-pms-arent-the-arbiters-of-community-contributions), product managers are not the arbiter of what the JiHu team works on
- Just like [PMs aren't the arbiters of community contribution](/handbook/product/product-processes/#gitlab-pms-arent-the-arbiters-of-community-contributions), product managers are not the arbiter of what the JiHu team works on
- Product managers are not responsible for JiHu product decisions, such as tiering, pricing
[Iteration training](https://about.gitlab.com/handbook/engineering/development/onboarding/manager/#iteration-training) is available to coach on GitLab's value of iteration. This can be helpful to understand the expectations of GitLab product teams for feature iteration.
Not every features can follow the same strategy, but the first strategy we
try should be [crafting the minimal viable change](https://about.gitlab.com/handbook/product/product-processes/#crafting-an-mvc), and for creating
try should be [crafting the minimal viable change](/handbook/product/product-processes/#crafting-an-mvc), and for creating
merge requests, always try to [keep merge requests small](https://about.gitlab.com/handbook/engineering/workflow/iteration/#how-to-keep-a-merge-request-small).
In the above guidelines to keep merge requests small, we mentioned:
