I haven't had as much time to review the Parquet PRs, so I'll remove myself from the CODEOWNERS for that.
I've found that I have a much easier time keeping up with PR reviews in projects that are smaller, even if there are proportionally fewer maintainers. I think that's the piece that appealed to me originally about CODEOWNERS: that we could start to make there be some more clarity on how reviewing responsibility can be divided up. But I agree it hasn't really lived up to that hope. On Tue, Jul 4, 2023 at 1:13 PM Joris Van den Bossche < jorisvandenboss...@gmail.com> wrote: > I think it can be useful in certain cases, where the selection is > specific enough (for example if all Go related PRs is not too much for > Matt, this features sounds useful for him. I can also imagine if you > are working on flight, just getting notifications for changes to the > flight-related files might be useful). > > Personally, for myself I didn't add my name to the CODEOWNERS, because > as someone doing general pyarrow maintenance, I was thinking that > adding my name as owner of "python" directory would lead to way too > many notifications for me, and there is no obvious more specific > selection. > > So if it's useful for some people, I wouldn't necessarily remove it, > as long as: 1) everyone individually evaluates for themselves whether > this is working or not (and it's fine to remove some entries again), > and 2) we know this is not a system to properly ping reviewers for all > PRs, and we still need to manually ping reviewers in other cases. > > On Tue, 4 Jul 2023 at 20:11, Matt Topol <zotthewiz...@gmail.com> wrote: > > > > I've found it useful for me so far since it auto adds me on any Go > related > > PRs so I don't need to sift through the notifications or active PRs, and > > instead can easily find them in my reviews on GitHub notifications. > > > > But if everyone else finds it more detrimental than helpful I can set up > a > > custom filter or something. > > > > On Tue, Jul 4, 2023, 12:30 PM Weston Pace <weston.p...@gmail.com> wrote: > > > > > I agree the experiment isn't working very well. I've been meaning to > > > change my listing from `compute` to `acero` for a while. I'd be +1 for > > > just removing it though. > > > > > > On Tue, Jul 4, 2023, 6:44 AM Dewey Dunnington > > > <de...@voltrondata.com.invalid> > > > wrote: > > > > > > > Just a note that for me, the main problem is that I get automatic > > > > review requests for PRs that have nothing to do with R (I think this > > > > happens when a rebase occurs that contained an R commit). Because > that > > > > happens a lot, it means I miss actual review requests and sometimes > > > > mentions because they blend in. I think CODEOWNERS results in me > > > > reviewing more PRs than if I had to set up some kind of custom > > > > notification filter but I agree that it's not perfect. > > > > > > > > Cheers, > > > > > > > > -dewey > > > > > > > > On Tue, Jul 4, 2023 at 10:04 AM Antoine Pitrou <anto...@python.org> > > > wrote: > > > > > > > > > > > > > > > Hello, > > > > > > > > > > Some time ago we added a `.github/CODEOWNERS` file in the main > Arrow > > > > > repo. The idea is that, when specific files or directories are > touched > > > > > by a PR, specific people are asked for review. > > > > > > > > > > Unfortunately, it seems that, most of the time, this produces the > > > > > following effects: > > > > > > > > > > 1) the people who are automatically queried for review don't show > up > > > > > (perhaps they simply ignore those automatic notifications) > > > > > 2) when several people are assigned for review, each designated > > > reviewer > > > > > seems to hope that the other ones will be doing the work, instead > of > > > > > doing it themselves > > > > > 3) contributors expect those people to show up and are therefore > > > > > bewildered when nobody comes to review their PR > > > > > > > > > > Do we want to keep CODEOWNERS? If we still think it can be > beneficial, > > > > > we should institute a policy where people who are listed in that > file > > > > > promise to respond to review requests: 1) either by doing a review > 2) > > > or > > > > > by de-assigning themselves, and if possible pinging another core > > > > developer. > > > > > > > > > > What do you think? > > > > > > > > > > Regards > > > > > > > > > > Antoine. > > > > > > > >
