Problems With Checkstyle Admin

[rnveach]

#15643 (comment)

We need proposal on what should be improved

I suggest starting with a review of project management practices. I have lost confidence in the process here. I find it distasteful that you block and stop progress on things when you disagree with them, but you are fine going over others disagreements as long it is what you want.

Due to these issues, I have stopped contributing changes to this project for some time now and will continue to do so. My involvement now is limited to trying to prevent the project’s code from declining, but I’m unsure how long that will be feasible.

===

What started this:

Please refrain from pinging me via PM or GH to ask for my opinion only to disregard it or potentially ignore our rule requiring two admin approvals for merging, especially when another admin has disapproved of the PR.

[rnveach]

@romani I am compelled to address this directly, as I feel it concerns your handling of the project.

I no longer agree with the way you are handling the project. This seems to have escalated from the decision that you could act as the sole reviewer and merge based on your own assessments. While we, as admins, initially agreed to this, I now believe we didn't foresee it reaching this negative of an extent.

We are merging incomplete and subpar work just to close issues. Over the years, I've noticed a decline in the quality of the code being merged, especially in complex GSoC projects, leaving unresolved problems in our codebase. Despite my efforts to address these concerns, you have pushed me to review the PR, only to merge them after disregarding my requests for change. That example was merged without addressing requests from two admins and wrongly marked as completed. This is why, in today's Discord discussion, I immediately denied your request to proceed with this approach more. I was disappointed by, what I believe to be your follow up attempts, to guilt us this was a wrong decision, when this process used to function well for us years before.

At the moment, I don’t feel trust is present. I’m unsure if this post will even resonate with you, as your response to my earlier disagreement ( #15643 (comment) ) felt dismissive. This also recalls our discussion regarding this year’s GSoC projects, where you suggested we should simply trust you without sharing a plan. The quality of that project, in my view, hasn’t met even a basic threshold we once upheld. I’m at a point where I no longer wish to deal with low-quality work in my personal time, especially when I encounter it enough in my professional life.

To restore trust, I suggest returning to our previous practice: requiring two reviewers for every PR. In case of disagreements, we should follow a majority vote. Additionally, I propose that we put more effort into planning future GSoC projects, ensuring agreement on key challenges before starting. If consensus cannot be reached, I am fine with this project not participating in GSoC. This is mostly going back to what we once had, but I am not sure I see an alternative yet.

Given the state of our codebase, with many unresolved concerns, I recommend we consider making substantial breaking changes to improve it, even if it means missing release cycles.