Goal: track amount of bugs per author (productised version)

[zolotokrylin]

Blocked by

• https://github.com/holdex/marketing/issues/78

Job story

• When developers fix the bug (create fix: type of PR)
• I want them to identify and specify a bug author as a part of cost submission
• So Leads can track the amount of introduced bugs per developer and work with this information later

Solution flow

1. track the PR name and if it includes fix prefix request the developer to provide the link to the commit and the author's username which has introduced the bug (the "Bug Info")
2. if information is not provided, do not let the user merge ("CI check fail").
3. when information is submitted, account it in the HR report.

Submission of the Bug Info

Use the same message as the cost submission message and extend it further with the instruction addressing to the author of fix PR:

@authorname please use git blame and specify the link to the commit link that has introduced this bug. Send the following message in this PR: @pr-time-tracker bug commit [link] && bug author @name

Tasks

Preview Give feedback

1. Problem: Tracker is not triggered when a fix PR is created #276
   +0
   
2. Problem: Cannot see bug info warning in the fix PR #316
   +0
   
3. Problem: fix PR action and warning stays after title updated #318
   +0
   
4. Problem: Tracker doesn't store bug info in DB #320
   +0
   
5. Problem: Cannot see the bug events in the developers spreadsheet #321
   +0
6. Problem: Tracker mesage is not removed if the check is cancelled #327
   +0
   

[zolotokrylin]

@georgeciubotaru could you please provide a rough man-hours cost here? 🙏

[georgeciubotaru]

@zolotokrylin This will take around 3 days. Also, what should be the trigger event?

[zolotokrylin]

@georgeciubotaru:

• PR created
• PR name changed

May be someone creates a wrong PR name and then renames into correct one or the opposite way.

[zolotokrylin]

@georgeciubotaru can you please create a problems list and let's start tackling them slowly so by the end of the next week we release this feature.

[georgeciubotaru]

Log: blocked by #279

[zolotokrylin]

@markcurchin @georgeciubotaru do you think this feature is useful?

[markholdex]

@zolotokrylin my thoughts it is mostly related to company cost optimizations. Of course, we don't want people to push buggy code. And remaking buggy apps takes more time and thus costs more. I know that in the end, everything affects the cost. But I think we can also work on the coaching perspective.

for me, this is 50/50.

---

Labels or any way to flag PRs over certain guideline rules feels more valuable for a 1-on-1 meeting. Or the possibility of submitting time from the bot is also much better.

[zolotokrylin]

The problem here I see not only with money per hour cost but also with:

1. lousy culture and bad example where you have people delivering good work and people delivering bad work; it is not fair for high performers
2. disappointed customers (leading to less business/referrals & lost trust)
3. It is a waste of my time and the time of people who are not directly coding; it is a lost opportunity to do what is important and not urgent (bugs are always urgent and important).

I want:

1. high quality of code in main regardless of the level of seniority and experience; each code author and reviewer must make sure the code is bug-free
2. everyone respects our values
3. us a group of people achieving meaningful results, and becoming the best in the industry

These things can be achieved only with good quality. And the more people we have, the more distortion we will have. If we allow bugs now, there will be more bugs in the future–it will happen exponentially.

We must track the ratio between bugs and features.
How can we achieve fewer bugs without implementing this feature, so we save time?

Any ideas?

[zolotokrylin]

Goal: manually track the amount of bugs per author