On Tue, Mar 19, 2019 at 12:53 PM bawolff bawolff+wn@gmail.com wrote:
Technical debt is by definition "ickyness felt by devs". It is a thing that can be worked on. It is not the only thing to be worked on, nor should it be, but it is one aspect of the system to be worked on. If its ignored it makes it really hard to fix bugs because then devs wont understand how the software works. If tech debt is worked on at the expense of everything else, that is bad too (like cleaning your house for a week straight without stopping to eat-bad outcomes) By definition it is not new features nor is it ickyness felt by users. It might help with bugs felt by users as often they are the result of devs misunderstanding what is going on, but that is a consequence not the thing itself.
The devs is not the primary user group, and they never will be. An editor is a primary user, and (s)he has no idea where the letters travels or how they are stored. A reader is a primary user, and likewise (s)he has no idea how the letters emerge on the screen.
The devs are just one of several in a stakeholder group, and focusing solely on whatever ickyness they feel is like building a house by starting calling the plumber.
Sales dept usually dont advocate for bug fixing as that doesnt sell products, new features do, so i dont know why you are bringing them up. They also dont usually deal with technical debt in the same way somebody who has never been to your house cant give you effective advice on how to clean it.
A sales dep is in contact with the customer, which is a primary user of the product. If you don't like using the sales department, then say you have a support desk that don't report bugs. Without anyone reporting the bugs the product is dead.
Actually this is the decade old fight over "who owns the product". The only solution is to create a real stakeholder group.
That said, fundamentally you want user priorities (or at least *your* priorities. Its unclear if your priorities reflect the user base at large) to be taken into consideration when deciding developer priorities? Well step 1 is to define what you want. The wmf obviously tries to figure out what is important to users, and its pretty obvious in your view they are failing. Saying people are working on the wrong thing without saying what they should work on instead is a self-fulfiling prophecy.
Not going to answer this, it is an implicit blame game