Improving on our “Bias towards action”
This continues the discussion async from the UX weekly on improving on our “Bias towards action”
Decision as to move forward with a more self-responsible review process, similar to https://about.gitlab.com/handbook/product/#changing-the-product-handbook and how that would work for the design.GitLab.com and design repository projects.
Potentially, as well for https://gitlab.com/gitlab-com/www-gitlab-com/tree/master/source/handbook/engineering/ux (though let's focus on the other 2 first)
Notes which were mentioned in the UX weekly conversation
- Merge requests are there to receive feedback and act upon it
- The new review process would still ask for feedback in a certain timeframe (say 3-5 days), after that if there is feedback it will be adressed and/or it will be merged.
- Is merge requests turnaround currently that high? => Generally speaking no, but this might have even more of an impact on design.GitLab.com where we will have an continuous increase in the amount of changes going forward.
- We should consider per situation: Is it better than what is currently is? If so, it should be generally good to merge.
- Is velocity, really velocity, if you need to go back to fix it?
- We should avoid big merge requests, which are harder to merge, need bigger review process. They are not suitable for this kind of process change.
- Docs team has moved on to a "merge regardless of review" process, where docs team reviews after it has been merged
- Automatisation is possible through means like danger bot for example.
- Docs shines with added velocity, docs changes are easy to fix.
- More natural review process. It lessens the load on the few maintainers for more high impact changes, adds transparency to the complete team to whom the change matters the most (or know the most about).
Proposal for process change
I have updated the proposal to take the notes above into account.
Documentation changes towards https://gitlab.com/gitlab-org/gitlab-design and https://gitlab.com/gitlab-org/design.GitLab.com going forwards will only require a 3-5 days review period going forward. Mention the team
@gitlab-com/gitlab-ux, fix any comments made if any, and finally merge it yourself.
Design documentation ultimately informs the product and is a great tool to define a decision across the product. The faster we are able to move these decisions into our documentation, the more effective our documentation will be. We have a bias for action and trust your judgement, therefore we can reduce as much friction as possible and improve the velocity for adding changes.