An idea discussed with @Jrbranaa on 20181210, potentially targeting engineering and programming managers.

Intention: Better understanding of the problem; sharing tools and workflows how to succeed, identifying best practices, give a hand.

Rough list of potential ideas (TODO: Some items might be better as subitems, or removed to save time, or rephrased?):

• [FREETEXT] What is the name of your team?
• [Y/N; URL] Do you have a list of the code repositories that your team currently maintains / is supposed to maintain? If yes, please provide a link to it.
• [Y/N; URL] Does your team have a SLA / time frame intention for reviewing proposed patches in your code repositories? If yes, please provide a link to it. (Example: Language Team)
• [Y/N] Do you think your team manages to stay "on top" of patches proposed in Gerrit in code repositories that your team maintains / is supposed to maintain?
• [FREETEXT] How does your team perform code review in Gerrit (or Github)? If a workflow exists, please describe it in words.
• [Y/N] Is code review an established integrated part of your team's recurring workflows?
• [Y/N] Do you make sure that your team watches all code repositories in Gerrit that your team maintains / is supposed to maintain?
• [Y/N; URL] Does your team use a dashboard in Gerrit? If yes, please provide a link to it.
• [Y/N] Does your team use and read mail notifications from Gerrit to get informed about code review to perform?
• [Y/N] Does your team "watch projects" via https://gerrit.wikimedia.org/r/#/settings/projects to get informed about code review to perform?
• [Y/N; FREETEXT] Do you think there is a difference in speed/acceptance between reviewing patches authored by other team members, vs authored by other WMF/WMDE/... members, vs authored by volunteer contributors? If you think there is, do you have ideas why?