My personal take is a slightly different approach. Of course as a reviewer and code owner we always accept that we can be better and address things in a more timely manner but.
As a reviewer I like to “Accept” things from people I trust, and that trust doesn’t come overnight, but its fairly easily earned.
So often the contributors first submission is some massive feature, Its their dream feature… “I wish clang-XXXX could do this!” You’ve probably worked on your huge idea for weeks learning the code base as you go with little to no feedback because you didn’t contact us because you wanted your feature to make a splash…
You submitted your first review with a “Ta daa”… here is the best thing to be added since sliced bread… (I know this behaviour because I’ve done this myself)
Ultimately as code owners we have no idea if you are here just for this one commit (drive by) or if you are here for the duration. Do I want to land your work of art? Do I want to consume that body of work into my responsibility. Have you followed the coding conventions, do I want to read your work of art or do I want to continue with my own submission or fix bugs, given the little time I have to work on this project myself…
At this point I am very reluctant to accept your review. Not because I think your submission isn’t valid or good but because I’m trying to see how committed you are… I want you to correct your review, I want you find your own bugs and resubmit the patch. I want to give you 1 or 2 comments then see if you come back…because SO many reviews we spend time reviewing only for the submitter to disappear because we didn’t get to it immediately.
Honestly its a little bit of a test for my perspective! are you a committed submitter who will:
a) manage your review to completion
b) have patience to see your submission land.(no matter how long it will take)
b) help in the future fix other peoples bugs
b) look after your own feature in the future
c) do my reviews
Ultimately this comes down to expectation as to how quickly you’d like to see you patch landed. Honestly what is the rush? I’ve had personal code reviews live for a very long time before they land (1+ year). For me its more about the perseverance and longevity of the contributor.
The thing with these tools is you don’t need to commit them to see them being used, Its much better if you make your change locally and then use it extensively first so you iron out all the bugs. I understand the rush to commit, I felt it myself in the early days (especially to get that feeling of your first submission), but I have to say take it slow there is no rush. (Its a Marathon not a Sprint)
As a code contributor for clang-format, I know that a code change that gets committed might not actually make it to mainstream usage for 3 or 4 releases. If you look at most projects using clang-format they are rarely on the latest release. (we are getting bugs coming in for 13/14 when we are about to goto 16). The problem is if we rush to commit incorrect code, it could be very difficult to patch these versions so we need to be very sure that the changes are good. We could break an awful lot of open source projects. (It is not uncommon for project that run on the bleeding edge such as Firefox to be the ones that Thankfully find these early for us!)
Ultimately contributors are put off, they get fed up and leave their review. (not even abandon it), its not ideal but the reality is they failed the patience and longevity test, they would have left anyway in that case and then we would be lumbered with their submission and someone else would have to fix their bugs. Do we need their submission? (its not like we don’t have it? as its in the review, if its a good idea it will rise to the surface and someone with take it on).
So how to over come this, is not about the reviewer giving more time, its about the submitter giving more time… you have to be realistic, you have to win the reviewers trust first. You need to become part of the team.
At this point your going to say you don’t have time to do that, We understand that we are in the same boat, and its why if there are only 3 or 4 of us doing the reviews its why we can’t get to yours in a timely fashion. (cause and effect!)
We recently had someone join the clang-format team, and that person did so without their first commit being a huge submission. That person quickly won our trust, and has become a regular contributor and code reviewer.
That person gained our trust by first being in the git issues, by working through the issues, in some cases just triaging them or finding duplicates and adding labels. It got them noticed, they also started to send reviews with very small one liners, bug fixes, They looked at other reviews to see who to add, and who would give them the quickest feedback and I’m pretty certain they also looked at the comments we were giving to others because their submission seemed almost perfect first time, and most importantly they were not trying to land a 1000 line new feature. But they proactively became a member of the community before doing the next biggest thing. This was highly refreshing…
I know for one I do the reviews of those regular reviewers/contributors first. With limited time its them I’m doing, because I know their review will likely be good and its unlikely to be huge.
So from my perspective ask yourself as a submitter what can you do to help the teams become better, what can you do to become a reviewer or trusted advisor…what can you do to free up the experienced code owner to work on what they are doing because it could be amazing (as they know the code better than you!)… If your review isn’t getting noticed… then get yourself noticed first, befriend a reviewer or review others. (not just comments, be brave and accept some)
Help out and you might just be able to drop in a “could you look at my review”