the rgw team had a retrospective meeting this morning about our upstream processes, and came up with a lot of good ideas for improvement. thanks to everyone that joined! i'm also interested to hear how other teams are handling similar issues ## topics of discussion 1. subject matter experts 2. tracker issues 3. pr review 4. rgw teuthology suite 5. pr testing ## subject matter experts an idea that came up repeatedly was that of a designated 'subject matter expert' for each part of rgw, who would take a bigger role in reviewing and delegating the bugs and pull requests the team has a lot of great engineers with deep, specialized knowledge of rgw, and i'd love to find more ways to spread that knowledge around through collaboration and mentorship i'll be creating a document, probably as a pull request to the ceph repo, that breaks down these areas and names the maintainers ## tracker issues the rgw project has a lot of open tracker issues. we have a ~30 minute bug scrub every thursday, but many bugs remain unassigned and we end up scanning the same recent issues every week without making much progress * assign every bug! default to the relevant expert, who can delegate as necessary * make better use of tracker priorities to focus on a) severe user issues and b) teuthology failures * occasionally do 'deep scrubs' to cover the really old stuff, and either close the bugs or assign to an expert for further review * developers can work with their manager to help prioritize bug fixing, and to make sure nobody is being overwhelmed with too many assigned bugs ## pr review * pr reviews can be assigned to their subject matter experts, especially for old/stale prs that need attention * for pull requests authored by experts, try to get another team member involved early on the in process, so they can participate in design discussions and have a better understanding of the project/feature * very large pull requests can be broken into smaller pieces to make the review more accessible. it also helps to put some extra effort into documentation, code comments, commit messages, and pr description * face-to-face code reviews are a good way to reduce communication overhead, and can help focus review on the interesting parts * i encourage everyone to participate in code reviews on github, even if they're not very familiar with the features. following pr discussions is a great way to absorb knowledge, and a fresh perspective can help to catch big-picture issues that the author missed ## rgw teuthology suite we've been struggling with a lot of test failures since the pacific release. a lot of them are due to the general entropy of changing test environments, and others are inevitable from our larger refactoring projects the failures make it difficult to review teuthology results, because there are so many 'known issues' to keep track of. and sometimes those mask other failures, so don't prevent us from merging more breaking changes track teuthology failures under 'urgent' priority and team up on fixing them until the suite is green again! ## pr testing a lot of reviewed prs are tagged needs-qa but go stale without testing. subject matter experts can identify these old prs that should be prioritized let's start cycling through the responsibility of testing pr batches every week or two? that person can get a handle on the known failures, and make sure there are tracker issues for everything if we get the suite green again, that makes it so much easier to get more people involved in testing _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
