I go with reject and move-on.
The downside is that other folks and new folks will keep discovering the bug 'anew' and have to remember them in their head. Which sounds like a huge problem.
In practice I have found that the fear is worse than the reality. Also consider that in many systems the number of bugs based on the combination of different devices, sizes, bandwidths, etc is essentially infinite anyway.
The other key factor is that just because the bug has been previously found and recorded it will still be found by new users, testers, etc. The difference now is that instead of logging a ticket, they allow the existing ticket to stand. However they still had to 'learn' what existing bugs are by actually encountering them. Reading through all the tickets in the backlog can help here but is rarely done as there may be hundreds or thousands and reading them all is not usually considered a standard practice for on-boarding new employees in most organizations that I have encountered. Not to say that you can't innovate anyway. Maybe a week of reading bug tickets will be something you decide to actually do.
The upside is a significant one - you move away from the dreaded 'ever growing backlog that everyone ignores' problem. The reason why this upside is worth the downsides to me is that after a while, tickets become a 'dumping ground' to park issues and not fix them and after a while this happens with more and more significant issues that are no longer as trivial as the ones that led to this practice in the first place.
I have seen this at multiple employers in a row. When I was finally able to manage tickets and bugs and a backlog myself I was determined to break this mold. I was successful and the backlog slowly diminished over time. However this meant a radically different approach to application development. Call it 'true agile' with developers actually truly empowered to make coding and design and maintenance decisions themselves.
I say radical because it requires processes that will be hard to introduce and sustain at many companies such as:
- refactoring can often be 50-90% of the work for a sprint. Not "as well as as features" but instead of.
- a focus on communication through multiple methods and on approaches such as 3 amingo to ensure that the team takes a dynamic and flexible approach to development, always willing to question assumptions.
- issues have to generally be fixed now. Not "at some point in the future" (frequently never) but actually fixed now to the satisfaction of the product owner. New features and releases have to be truly balanced against bugs, refactorings, quality issues, test automation etc.
The fact that you can't record bugs and issues to get the satisfaction and benefits from filing them away may, conversely, in some organizations, increase pressure to fix things now. Also, if instead of 'filing a bug' someone has to talk to the developer and have a detailed conversation this will often be a better approach (and generate more ideas, solutions, workaround, etc). Not to mention empowerment. However this will depend on a ton of external factors about the culture of the company. Unfortunately in many and perhaps most orgs today, this might well lead to even lower quality if folks aren't already motivated to produce high quality. In those situations, not recording bugs will be seen as not caring about them either.
So this is complex, non-trivial and requires long-term vision and approach. That's where good leadership comes in. Hire them.
Remember that in organizations that claim to be "Agile" (like all of them today) you're supposed to fix things now instead of creating processes to 'manage them'. like ticket backlog.
Warning signs that quality may not be job #1 ?
- a large backlog
- a growing backlog
- refactoring sprints
- technical debt sprints
- tech debt fridays
In other words, I would look at the big picture and think about:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Sound familiar? :)