Reputational damge and reviews

I agree. The problem is that once those AI shows up, whether PRs are good or bad, they pop up in the clusters, which takes more time to review.

I remember that we had a similar incident with another user who did a lot of great work, but did create quite a backlog. This lead to the addition of a serial submission policy being added to:

https://github.com/openssl/openssl/blob/master/CONTRIBUTING.md

Essentially your concern (in my view) is the same concern that Dmitry put forward in:

https://openssl-communities.org/d/3kjl5wx8/openssl-pr-review-process-proposal

In my view the reputational damage is caused by the lack of clear goals with the review pace. Ie. when can a contributor expect to see progress on a pull request.

The whole Foundation team was away since Thursday. That's unfortunate coincidence. I cannot do much with that. Also I do not think that anybody submitting tens of reports with extensive help of AI can expect immediate responses. So I am sorry but I disagree there is any serious reputation damage in this.

The Foundation are not the only group responsible for reviewing code. In fact they make up a minority of the project's staff who can review submissions.

I hear your concerns @Paul Dale , and I think, as others have mentioned, we've been in this situation before (in fact we seem to be perpetually in this state, given the fact that we consistently seem to have a backlog of ~300 PRs to address the disposition of, which is always growing slowly (its currently up to 403)).

We currently have 22 commiters on the list, and I would wager we are all in the same position as you are (i.e. would like to review, but have other priorities to attend to).

It seems like a economics style problem to me, in that we have a large and ever increasing demand for reviews, but a supply of reviewers that isn't keeping up, coupled with a lack of incentive for existing reviewers to engage on those reviews (i.e. the "I'm busy but I'm sure someone else will get to it" disposition).

So whats to be done about it? I would personally suggest a two step approach:

1) Increase the number of people that can do reviews. We had spoken about a way to address this in other threads I believe, via the creation of a MAINTAINERS or github codeowners file (in which code areas which have community members that have a level of expertise in the code being modified can weigh in and approve). These individuals need not be commiters, but their reviews "count" towards our review requirements. Individuals that want to participate can petition to be included in such a file, so that they have a greater voice in the community in terms of getting their code integrated by helping others do the same, thus increasing the total body of individuals doing reviews (i.e. addressing our supply issue)

2) Create an Incentive. Mandate participation on the part of those individuals who elect to participate in the mechanism in (1) - i.e. people in the codeowners/maintainers file should be required to review some percentage of the PR's which impact their area of expertise. Failure to do so results in their removal from the file. In fact comitters should be required to appear in this file, and its use should govern which PR's we are required to review.

In short, lets give the community at large an opportunity to have a bigger voice, and then make sure they use that voice. OpenSSL isn't the committers project, its the entire communities', and that mandates participation across the whole array of steps in the development process.

I had this conversation a few days ago as well, and I keep coming back to the same thought: While its true that not getting to reviews isn't a great look for us, its important to remember that being part of a community isn't a one way street. It doesn't just mean using the code, it also means raising issues (which we have members do prodigiously), opening PR's (which we also have in copious amounts), and, yes, doing reviews. Failure to do all of these things degrades the system as a whole, and right now we're missing enough people to do that last bit, and this approach (I think) could really help us in that area.

I don't recall from prior conversations, is there general consensus on the above approach? Should we put it to a vote?

Best

Neil

I do not mind a more formal review duty specification but I think calling it MAINTAINERS sends the wrong message, I would go for something more neutral but at the same time also giving more credit by calling it something like SME (for Subject Matter Expert).

@Simo Sorce Thats fair, and I think the CODEOWNERS mechanism (I think) gets us closer to that mark. It also integrates well as part of github, auto-assigning owners to reviews

I am really put off when people talk about code "ownership" as it put people in a defensive and/or possessive frame of mind. But we agree on the concept I think.

@Simo Sorce we could also do a custom mapping file, call it REVIEWERS or some such. It would require some additional work to do automated review assignments of course, but that might be a good tradeoff, as CODEOWNERS has some limitations in github that make maintenence of large projects a bit of a pain to manage