Just inherited a codebase. Need to get new devs up to speed fast on quality standards. Saw SonarQube has a 'my issues' view.
Here's how I use it as a mandatory first-day checklist. New hire logs in, goes to 'my issues', filters to the 'BLOCKER' and 'CRITICAL' severity on the main branch. That's their list. They fix them. Forces them to navigate the project, understand the rules, and clean up tech debt immediately. Works better than a doc nobody reads.
Set up a quality gate that fails if any new 'my issues' are assigned over 24 hours. This locks merging until they engage. It's blunt but effective.
I've seen this approach turn into a hazing ritual. If the inherited codebase is a dumpster fire, a new hire's first day is now triaging someone else's 'BLOCKER' debt. Good luck with retention.
The 24-hour quality gate lock is particularly harsh. What if the issue is a false positive or requires infra changes the new dev can't possibly own yet? You've just created a merge blockade for the entire team because someone got auto-assigned a legacy critical issue. Better to scope it to issues introduced *after* their start date, or at least have a manual override.
It does get them into the code, I'll give you that. Just make sure you're paying for their time to fix old problems, not just your sprint commitments.
-- cost first
Forcing new hires to immediately own the team's most critical legacy debt through an automated assignment system is a great way to see how much leash you're actually giving them. It's not onboarding, it's indentured servitude.
That 24-hour quality gate lock turns a tool into a compliance trap. What's the SLA on the vendor for resolving their false positives? You've now made that the team's new top priority, not shipping features. Good luck explaining that project delay because SonarQube mis-flagged a regex.
It gets them into the code, sure. I've also seen it get them onto LinkedIn updating their profile. If the codebase is that bad, pay for a cleanup sprint. Don't bake the cost into your turnover rate.
- Ray
That 24-hour quality gate is a good forcing function, but you're building a critical dependency on the SonarQube assignee model. Are you using email-based assignment or SCM committer association? If it's the latter, any commit from the new dev to a legacy file could auto-assign them all its existing issues, blowing up your gate.
You need to scope the gate to issues on *new code*, not just 'new to me'. Otherwise you'll have senior devs blocked because a new hire touched a legacy module during onboarding.
Consider this alternative: keep your 'my issues' checklist, but use a separate project-level quality gate that tracks *new* issues of those severities, period. That still incentivizes cleaning, but doesn't weaponize legacy assignment.
Show me the query.