I agree that adding an insightful comment or javadoc might significantly improve the readability and maintainability of the code and that is an added value.
In my understanding, Stamatis is talking about minor fixes like typos or similar, which are probably better addressed within PRs already touching the class/file. On Fri, 26 Jul 2024 at 17:45, Stephen Carlin <scar...@cloudera.com.invalid> wrote: > I agree with most of that. > > But comments and javadoc? I guess it depends on the situation, but any > clarification of code would seem to me to be a good thing. > > If someone took the time to document something, they might have been > cursing for hours trying to figure out what was going on with that specific > piece of code. And if so, that could increase productivity for future > developers. > > I'm not sure it should be encouraged, but I'm not sure an outright ban on > such commits is the right thing. > > On Fri, Jul 26, 2024 at 5:09 AM Alessandro Solimando < > alessandro.solima...@gmail.com> wrote: > >> +1 >> >> On Fri, 26 Jul 2024 at 11:21, Stamatis Zampetakis <zabe...@apache.org> >> wrote: >> >>> Hi all, >>> >>> In some cases we receive PRs/JIRAs with minor non-code improvements: >>> * fix small typos in very specific places >>> * empty lines/javadoc/comments >>> * minor rewording >>> >>> Personally, I feel that such changes have more negatives than >>> positives for the Hive project and I am listing a few below: >>> >>> * Consume CI resources (runs are limited in Hive so minor PRs may >>> block others from running) >>> * Increase likelihood of merge conflicts during backports >>> * Consume reviewers time (for checking and merging) >>> * Consume contributors time (they could spend their time on more >>> impactful changes) >>> * Additional JIRA/git/mailing list traffic >>> >>> I tend to avoid looking/accepting/merging such contributions because I >>> have a limited amount of time and would like to focus on more >>> impactful changes. If other people have the same point of view then we >>> could add a small mention in our contribution guide to save time from >>> new contributors. If not, which is completely understandable, then we >>> can continue to operate as we do and accept everything. >>> >>> Best, >>> Stamatis >>> >>
