Thanks all for the input! Dana:
> This list includes per-file owners, did the script look for 100 CLs in > those files named by the rule when deciding to remove the person? Thanks for pointing this out! I'll exclude per-file owners from the list for now. Peter: > I'm worried that this process excludes/penalizes folks who may be OOO for > extended leave (incl long stretches of parental leave, bereavement) and > have that in their Gerrit status. This should not be a source of review > latency, if it is Gerrit should better surface that they are OOO. > Are any of the inactive owners, who did opt out last time, a source of > review latency? I.e. are reviews assigned to them but they don't review > them within some SLO window? Otherwise I strongly suggest we let folks > decline the OWNERS removal (at other OWNERS' discretion who should probably > review removal CLs). I think Glen covered this topic very well. As written in this guideline <https://chromium.googlesource.com/chromium/src/+/master/docs/code_reviews.md#expectations-of-owners>, owners are expected to be an active contributor to the directory ("Have the bandwidth to contribute to reviews in a timely manner. ... Don't try to discourage people from sending reviews, including writing “slow” or “emeritus” after your name."). If you are on an extended leave and removed by this process, you can explain it and re-add yourself through the owner nomination process. Will it work? Matt: > Maybe it would make more sense to identify OWNERS who are not active > globally in chrome/, instead of owners not active in a particular > directory? How common are OWNERS active in Chrome, but high latency only > for specific directories? My personal opinion is that owners who made no contributions globally in the past 6 months *or* owners who made no contribution to the directory they own while there were 100+ commits in the past 6 months can be identified as inactive owners. Note that this is not an irreversible process. When you have a reason, you can explain it and re-add yourself through the owner nomination process. I'm asking as someone who was recently inundated by auto-generated removal > CLs, the majority of which did not make sense (admittedly, I believe it > wasn't based on activity). The tool even seemed to want to remove all > owners from some directories. Right, the removal tool is not looking at activities, and this proposed process is different from it. FWIW when I removed ~500 inactive owners last year, it ended up removing (only) ~10 OWNERS files. So removing all owners from some directories will be rare. Pavel: > The data in the table seems off, what is considered a "review": is that a > "Code Review +1" or is that any review comment? "Code Review +1" in the git commit log is considered as "review". > I also have an edge case where I'm mostly interested in several files in a > folder where other files are being changed more frequently, should I be > optimizing OWNERS to list myself as per-file? This sounds reasonable to me :) Glen: > I recently tried a similar automated audit of inactive owners - I looked > for anyone who hadn't reviewed or authored a CL in 12 months anywhere, > regardless of activity in the directory and found (as list, Google internal > only) many accounts that no longer exist (or perhaps never did) in OWNERS. > It probably has different false positives than the proposed set above. > Maybe the intersection of the two sets would be sensible? I'm happy to tweak the criteria depending on the conclusion of this email thread :) On Thu, Jul 28, 2022 at 3:32 PM Glen Robertson <[email protected]> wrote: > > Having your name on OWNERS is an award for your previous amazing > contributions > I'm concerned that being in OWNERS is regarded as a reward, and being > removed as a penalty -- it is part of the problem with cleaning up inactive > OWNERS. I'd much prefer to have a separate "amazing contributors" file to > list people who have made amazing contributions, without this affecting the > code review process. > > Owners are supposed to be > <https://chromium.googlesource.com/chromium/src/+/master/docs/code_reviews.md#expectations-of-owners> > active reviewers for a directory. I'd even expect us to remove people who > go on long leave, unless Gerrit can understand that status and avoid > suggesting them for reviews (currently it does not do that well). Re-adding > an owner is not an arduous process, but adding days to a code review is a > significant cost. > > I recently tried a similar automated audit of inactive owners - I looked > for anyone who hadn't reviewed or authored a CL in 12 months anywhere, > regardless of activity in the directory and found > <https://chromium-review.googlesource.com/c/chromium/src/+/3750667> (as > list, Google internal only > <https://docs.google.com/spreadsheets/d/1BWvj44vJUjSXUHI85fJwX8AgIoYR5SkAm378pp80ljw/edit?resourcekey=0-7pInBE4h65x3c5t6Af1hbA#gid=0>) > many accounts that no longer exist (or perhaps never did) in OWNERS. It > probably has different false positives than the proposed set above. Maybe > the intersection of the two sets would be sensible? > > On Thu, 28 Jul 2022 at 07:45, Pavel Feldman <[email protected]> wrote: > >> The data in the table seems off, what is considered a "review": is that a >> "Code Review +1" or is that any review comment? >> I also have an edge case where I'm mostly interested in several files in >> a folder where other files are being changed more frequently, should I be >> optimizing OWNERS to list myself as per-file? >> >> On Wednesday, July 27, 2022 at 2:16:47 PM UTC-7 Matt Menke wrote: >> >>> Maybe it would make more sense to identify OWNERS who are not active >>> globally in chrome/, instead of owners not active in a particular >>> directory? How common are OWNERS active in Chrome, but high latency only >>> for specific directories? I'm asking as someone who was recently inundated >>> by auto-generated removal CLs, the majority of which did not make sense >>> (admittedly, I believe it wasn't based on activity). The tool even seemed >>> to want to remove all owners from some directories. >>> >>> On Wednesday, July 27, 2022 at 5:03:05 PM UTC-4 [email protected] wrote: >>> >>>> I echo Dana's concern about removing per-file owners and would like to >>>> see that policy rethought. Agree with Peter's observations as well. >>>> >>>> -Ken >>>> >>>> >>>> >>>> On Wed, Jul 27, 2022 at 9:12 AM Peter Boström <[email protected]> >>>> wrote: >>>> >>>>> I'm worried that this process excludes/penalizes folks who may be OOO >>>>> for extended leave (incl long stretches of parental leave, bereavement) >>>>> and >>>>> have that in their Gerrit status. This should not be a source of review >>>>> latency, if it is Gerrit should better surface that they are OOO. >>>>> >>>>> Are any of the inactive owners, who did opt out last time, a source of >>>>> review latency? I.e. are reviews assigned to them but they don't review >>>>> them within some SLO window? Otherwise I strongly suggest we let folks >>>>> decline the OWNERS removal (at other OWNERS' discretion who should >>>>> probably >>>>> review removal CLs). >>>>> >>>>> On Wed, Jul 27, 2022 at 8:08 AM <[email protected]> wrote: >>>>> >>>> This list includes per-file owners, did the script look for 100 CLs in >>>> *those >>>>>> files* named by the rule when deciding to remove the person? >>>>>> >>>>>> On Tue, Jul 26, 2022 at 9:16 PM Kentaro Hara <[email protected]> >>>>>> wrote: >>>>>> >>>>> Hi >>>>>>> >>>>>>> As of 2022 July, Chromium has 4531 OWNERS files containing 6850 >>>>>>> names. These include inactive owners, which are one of the sources of >>>>>>> slow >>>>>>> code review latency. One year ago, we cleaned up inactive owners >>>>>>> <https://groups.google.com/a/chromium.org/g/chromium-dev/c/MpOgk56qKS0/m/HHy7G19oAwAJ> >>>>>>> and removed ~500 inactive owners. I propose running the clean-up process >>>>>>> again to keep the OWNERS files updated. >>>>>>> >>>>>>> Specifically, a person is identified as an "inactive" owner iff: >>>>>>> >>>>>>> - >>>>>>> >>>>>>> The person didn't commit or review any CLs in the directory they >>>>>>> own while there were 100+ CLs that touched the directory in the past >>>>>>> 6 >>>>>>> months (as of July 6, 2022). >>>>>>> >>>>>>> Last year, I gave the inactive owners an option to flip the decision >>>>>>> manually to stay as an owner, but for this cycle, I'm planning to remove >>>>>>> the inactive owners unconditionally. The rationale is 1) if the person >>>>>>> made >>>>>>> no contribution on a very active directory for 6 months, it will be >>>>>>> reasonable to say that the person is inactive, and 2) if there is any >>>>>>> special reason for it and the person needs to stay as an owner, the >>>>>>> person >>>>>>> can show evidence that they are meeting the owners expectations >>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/code_reviews.md#expectations-of-owners> >>>>>>> and be readded through the standard OWNERS nomination process. >>>>>>> >>>>>>> Specifically, people listed in this spreadsheet >>>>>>> <https://docs.google.com/spreadsheets/d/1gJbXzTaoITvCDmQaqMmGCvfOngrcFtMPmMsGhHgEV_4/edit#gid=0> >>>>>>> are identified as inactive owners and will be removed. >>>>>>> >>>>>>> I understand this is a tricky proposal. Having your name on OWNERS >>>>>>> is an award for your previous amazing contributions, and I understand >>>>>>> your >>>>>>> feeling about your name being removed. However, I think it's important >>>>>>> to >>>>>>> keep the OWNERS files updated so that Chromium developers can find >>>>>>> active >>>>>>> owners and improve the code review latency. >>>>>>> >>>>>>> If you have any questions / concerns, please let me know. Thanks! >>>>>>> -- >>>>>>> Kentaro Hara, Tokyo >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "blink-dev" group. >>>>>>> >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>> >>>>>> >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jyArLjDp0ixPu%2BCSZ9NVrn0M1GwNFiJqiPGRE1f0mrbfQ%40mail.gmail.com >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jyArLjDp0ixPu%2BCSZ9NVrn0M1GwNFiJqiPGRE1f0mrbfQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>>>> -- >>>>>> Chromium Developers mailing list: [email protected] >>>>> >>>>> >>>>>> View archives, change email options, or unsubscribe: >>>>>> http://groups.google.com/a/chromium.org/group/chromium-dev >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Chromium-dev" group. >>>>>> >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>>> an email to [email protected]. >>>>> >>>>> >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAHtyhaTNC4tgQbqbUq%2BQdFfcORr3aFobjgbeE%2BTaVf7eDgU2Bg%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAHtyhaTNC4tgQbqbUq%2BQdFfcORr3aFobjgbeE%2BTaVf7eDgU2Bg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>>> -- >>>>> Chromium Developers mailing list: [email protected] >>>> >>>> >>>>> View archives, change email options, or unsubscribe: >>>>> http://groups.google.com/a/chromium.org/group/chromium-dev >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Chromium-dev" group. >>>>> >>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>> >>>> >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAGFX3sFB9G8R2MyHT6rjVtEFRAKMeyCTH6Yu0DYqUOfLPCxCBw%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAGFX3sFB9G8R2MyHT6rjVtEFRAKMeyCTH6Yu0DYqUOfLPCxCBw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0a2a01e2-652b-4e31-895c-f020e7b46358n%40chromium.org >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0a2a01e2-652b-4e31-895c-f020e7b46358n%40chromium.org?utm_medium=email&utm_source=footer> >> . >> > -- Kentaro Hara, Tokyo -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABg10jyCNN1%3DpfT%3DCWPmc4%2Bi9PmGs-%3DbX9e2mUi2bHthF%2B0w-w%40mail.gmail.com.
