Product / UX / Development process improvements
On 6 July 2017 we had a meeting with @mydigitalself, @sarrahvesselov and most of the engineering leads (@DouweM @ayufan @smcgivern @timzallmann @jschatz1 @sta) regarding our process.
Notes are available here: https://docs.google.com/document/d/1hPtBZLcavF08R1R_rhovIU7VCeLr3tFco8Me2VNu5eY/edit
To summarise, as there were many interrelated issues and themes, we outlined the following problems:
- We aren't delivering what we set out to achieve in our releases, this includes Deliverables
- For reference, on day of feature freeze, we have 185 Open issues in 9.4 Milestone against a total of 387 (202 closed)
- Of these issues, there are 90 open
Deliverables
and 88 closed. - It's impossible to view this data historically as issues will often get moved
- We are generating a huge number of regressions every release
- In 9.1 131 of 405 closed issues are regressions. That's
32%
of all issues! - In 9.2 125 of 353 =
35%
- In 9.3 97 of 406 =
23%
although we are still finding and fixing regressions at time of writing.
We decided on a handful of process adjustments, which will be implemented in various issues and need to find their way into the appropriate places in our handbook and process guides. The reason for this issue is to track each one of these and make sure they are put into the correct place and that they were summarised correctly.
We agreed on the following:
- We need to take fewer issues, including
Deliverables
into the next releases. By planning more and not delivering we are sending incorrect signals about what will be in a release internally and to our customers and community.
- This should also improve quality of code that is shipped, reducing regressions
- We need to do a better job of estimating work capacity at the start of the month, ahead of planning
- This may be through better use of weighting issues
- Many regressions can be avoided by more thorough testing of a feature during review and before merging
- Review process needs better testing on
dev.gitlab.com
- We will create an EE version of
dev.gitlab.com
to allow for EE testing and integration testing (LDAP, Jenkins, etc...) https://gitlab.com/gitlab-com/infrastructure/issues/2201 - PMs should be involved in this process too as part of feature assurance
- We can even do this ahead of time by doing screenshare sessions earlier in the process
- We should aim to do this as early as possible, rather than having a huge volume of merges, testing and feature assurance on day of code freeze
- All
Deliverables
are to be assigned before kickoff
- This includes front-end, back-end and UX assignments where appropriate
- Whoever is assigned to the issue should agree ahead of kickoff that they are able to complete all of their assigned deliverables.
- One MR per feature
- Many issues have front-end and back-end issues or multiple MRs. This makes end-to-end testing impossible.
- Setup monthly process meeting @stanhu
- Perhaps we can have a workshop in Crete on this?
cc @gl-product