Appeal: 30-Day Ban for PR #6223 (talawa admin) - Refactored ProfileForm to Unblock Pre-Commit Hooks

[ashutoshsao]

Dear Palisadoes Foundation Team and @palisadoes ,

I am appealing the 30-day ban issued for PR #6223. I believe the ban was based on a misunderstanding of the situation I faced.

The Situation

I was assigned to issue #5918 (LoginPage MUI imports). I completed the work and attempted to commit, but pre-commit hooks failed because ProfileForm.tsx exceeded 600 lines.

I faced a choice:
- Option A: Don't fix ProfileForm : Can't commit my assigned work
- Option B: Fix ProfileForm : Complete my assigned work

I chose Option B. I refactored ProfileForm.tsx to pass pre-commit checks so I could commit my LoginPage work.

What I Should Have Done

I should have communicated when I hit this blocker. I should have commented on issue #5918 saying: "Pre-commit hooks are failing due to ProfileForm.tsx line count. How should I proceed?" and waited for guidance.

I apologize for not following the communication protocol. I made a judgment call to solve the problem independently, but I understand now that asking first would have been the better approach.

My Reasoning

1. I was blocked from committing my assigned work (#5918)
2. The blocker was a legitimate technical issue (pre-commit hooks failing)
3. I made a judgment call to fix the blocker and complete my task
4. I was trying to show ownership and solve problems independently

Additionally, after refactoring ProfileForm, CodeRabbit AI requested further changes (stricter types, which required updating DynamicDropDown.tsx). I made these changes because you had commented on the PR to:
- "Ensure CodeRabbit approves your changes"
- "All tests pass and are valid"
- "All conflicting files are resolved"

I was following this guidance to ensure my PR met the project's quality standards.

The Core Question

Should I have asked for permission before fixing a blocker that prevented me from committing my assigned work?

I understand the project values communication and following process. However, I also thought showing initiative and ownership by solving blockers was valued. I made a decision to unblock myself and complete my assigned task.

What I'm Asking For

I'm not asking for the ban to be reversed if the policy is absolute. But I am asking for acknowledgment that:

1. I was working on my assigned issue (#5918)
2. I encountered a legitimate blocker (pre-commit hooks)
3. I made a reasonable judgment call to fix it and complete my work
4. My intention was to show ownership and solve problems, not violate policy

If the policy is "always ask before fixing any blocker," I understand and will follow it. But I don't believe I was trying to do something wrong - I was trying to be a responsible contributor who solves problems.

Thank you for considering this appeal.

@ashutoshsao


Reference: PR #6223

 

[palisadoes]

Thanks for the explanation. It seemed like an extremely egregious violation of our policy at the time.

We created a separate issue to refactor the Profile file because it had slipped through our CI/CD checks and had to create an exception for pull requests.

Investigating further, the CI/CD and husky pre-commit checks use different configurations. One uses a CLI flag listing files to exclude, the other referred to a configuration file for the exclusions. This meant the updated CI/CD workflow was passing, however not the pre-commit check. We have been migrating many of our GitHub actions to a new centralized system and the discrepancy is a result of an incomplete implementation.

This will need to be rectified.

Mistakes were made on both sides and I apologize for acting in haste.

I'll try to reverse the reversion of the PR and lift the blockage of your account.

 

[ashutoshsao]

@palisadoes Thanks for considering.