Improvements to the Design Trainee Maintainer process
This issue is a reflection of my current Trainee Designer Maintainer work for Pajamas. Traintainer numero uno!
- My Designer Trainee issue gitlab-com/www-gitlab-com#4977 (closed)
- Handbook page
As I started collecting data from my mainteinter contributions, I noticed that the Trainee process for designer has a few gaps that need discussion.
Duration of the traineeship
The traineeship process might take longer than expected.
In the beginning my expectation was to become a maintainer in 2 milestones max. This is definitely not the case :) We need to adjust the process and set better expectations about the duration moving forward. The questions below are currently open, and might be necessary for us to increase the number of designers wanting to become more involved with Pajamas on a maintainer level:
- How long does the trainee process for the UXer normally takes?
- How much effort should be applied to the process, so that the designer can allocate the right amount of time to become a maintainer, and align availability with ux manager/product manager?
As an example, the BE team added a new criteria to their maintainer program: Ask your manager to set up a check in on this issue every six weeks or so. This is because historically most backend trainee maintainers have become maintainers five to seven months after starting their training.
- Is this also a reality for designers?
- Can the 5 to 7 months process discourage other designers to partake in the traineeship?
Proposal
Break down the traineeship into levels. Within each level, come up with more specific tasks/steps that designers can follow in order to become maintainer lvl 1, lvl 2. Example:
- Lvl 1 Component expert -- expert in a component and has deep knowledge of its function and user experience.
- Lvl 2 Sketch expert -- expert at ui review, has knowledge of product foundations (color, spacing, etc).
- Lvl 3 Usability expert -- expert at accessibility, internationalization, etc.
- Lvl 4, 5 and so on.
This can help us evaluate progress in specific areas of the design system, allowing both the trainee and the maintainers to determine what success is, and work on an actionable plan to make the trainee move on to more pajamas-heavy tasks.
Knowledge required to become a maintainer
Thinking out loud, I don't believe anyone will have acquired the same level of knowledge around Pajamas that Taurie, Pedro, George and others have in a short period of time. We need to get rid of the perception you need to do extra to contribute to the design system.
Pajamas is a living document, and on top of the design guidelines, we need to be informed of what decisions have been made in the gitlab-ui project, and the changes coming from the stage groups that shape the idea of our system (components, guidelines, processes).
The current criteria informs us that maintainers:
- Are experts at design and code review.
- Know the GitLab product, design guidelines, and code base very well.
- Are empowered to accept merge requests in one or several GitLab Engineering Projects.
With that in mind:
- What is the criteria for an expert at design?
- How can we ensure designers become experts without having to take on extra work on top of their current responsibilities?
- How can the existing maintainers help trainees be more strategic about the success metrics for the design system?
Proposal
- Introduce the role of a Maintainer buddy. A maintainer will be assigned to the issue together with the trainee, and both will be responsible for evaluating progress. Decide on a cadence to review progress.
- Built-in effort, not additional to what a designer is responsible for. Make the traineeship process part of the designer's personal OKRs.
Next steps
I would like to invite @pedroms @tauriedavis and @gtsiolis to discuss the points above. Together we can adapt the process and make a handbook update to the Design Trainee page, as well as to the issue template.