- Aliaksei Chumakou
- Oleksandr Kurash
- Vasily Gancharov
- Marc Johnson
- Richard Redweik
- Mikhail Fokanov
- Taras Spashchenko
- Martin Tran
- Stephen Pampell
- Come up with a list of explicit next steps and/or action items
From previous meeting: (2020-03-03 Cross-Team PR Reviews Discussion)
The tech lead from each team is responsible for reviewing PRs created by their team, regardless of the repository.
- This can be delegated to a backend/frontend lead, but the responsibility ultimately lies with the tech lead.
- In order for this to work and for tech leads to trust one another, it needs to be clear what goes into a quality PR review. PR checklists need to be rolled out and used. Additional documentation may be needed … What to look for, Level of detail, tips/tricks, etc.
- Publish a list of teams and their structure and areas they work in and keep it up to date! Zak commented that he doesn’t necessarily know who’s working in a particular area/repository
- Tech leads must have a succession plan. My understanding is that the EPAM teams already do this. When a tech lead leaves is replaced, their successor must understand what their responsibilities are, update the list above, etc.
- I'm guessing there will be a learning curve in some places like circulation - maybe having the tech leads for teams that contribute to circ should "shadow" Marc for a PR or two - maybe do the review together on a call or something? IDK just a thought.
- There's definitely a need to be clear about who is the tech lead for each team, who knows which codebase
- tech leads are allocated to teams - publish a list on the wiki and keep it up to date. FE/BE Leads for each team
- code owners are allocated to repositories
- Some form of delegation must happen
- We need to be more proactive than reactive - don't wait until the PR is created/approved/reviewed,
- Get buy-in from the various tech leads for a given codebase before the PR is created or even before the code is written
- Rely on tools (PR check lists, sonarqube, raml-cop, etc.) to catch the no-brainers - test coverage, linting, etc.
- Shore-up policies in places like PR check-lists, e.g. "are you adding new dependencies? check with the other tech leads"
- If the rules are broken or ignored, the tech leads need to discuss/sort it out.
- Expand participation in the tech leads meeting? Create a tech leads retrospective?
- Need to be diplomatic about raising issues - not naming names/pointing fingers
Things the TC will officially mandate:
Process improvements, meetings, tooling, documentation, etc. that will help implement the new policies:
- (All) Tech leads go back to their teams and promote PR reviews by all devs - stress the benefits.
- Craig McNally Publish a list of teams and their structure and areas they work in. Marc Johnson and Taras Spashchenko to provide links.
- Craig McNally Jakub Skoczen Organize tech leads retrospectives - initially every sprint, eventually space out to every Nth sprint
- Craig McNally Reach out to all current tech leads / call a meeting dedicated to going over this - what are their new responsibilities, promoted practices, etc.
- (TC) Define documentation policies/formats/templates - farmed out to a subgroup, etc...
- Craig McNally polish the policy wording and get to David Crossley to put on dev.folio.org → - FOLIO-2506Getting issue details... STATUS