I believe that the review process is not working so well anymore. I'm not
sure if committers/PMC members have just not had time to do reviews or have
not felt comfortable doing them, but for the most part they aren't getting
done and PRs are languishing. Personally, I like our process, but if it
takes 3+ weeks to deal with a PR like this:

https://github.com/apache/tinkerpop/pull/879/files

where all we did was remove deprecated methods, I don't think we're ever
going to get anything else through. As it stands, I personally chase votes
in the background to get PRs to merge.....and, I don't want to do that
anymore.

I'll remind committers (and those interested in becoming committers) that a
"review" in our context doesn't have to be a full on review of code where
you hold this deep understanding of everything that is going on. That is
awesome when that happens, but it is perfectly fine to review/VOTE in the
following manner (as examples):

+ VOTE +1 - ran docker integration tests and everything passes
+ VOTE +1 - reviewed the code in detail - solid pull request
+ VOTE +1 - agree with the principle of this pull request but don't fully
understand the code
+ VOTE +1 - read through the updated documentation and understand why this
is important, nice

So basically, you can VOTE and just explain your position for why you voted
(or not explain). I would like to keep this process, however, if we can't
raise the VOTEs for whatever reason, then I'd like to suggest a change.

I'd suggest that we go to a slightly looser version of review-then-commit,
where we require the 3  binding +1 VOTEs as we have been doing OR we
require a single binding +1 and 1 week for objection at which point we have
a form of lazy consensus.

Honestly, I'd like to see some discussion on this from committers/PMC
members and not go with the standard form of lazy consensus that we
typically end up with. However, if no one truly has anything to say,
consider the 72 hours started now.

Reply via email to