On Mon, Mar 18, 2019 at 10:52 PM bawolff
<bawolff+wn(a)gmail.com> wrote:
First of all, I want to say that I wholeheartedly agree with everything
tgr
wrote.
Regarding Pine's question on technical debt.
Technical debt is basically a fancy way of saying something is "icky". It
is an inherently subjective notion, and at least for me, how important
technical debt is depends a lot on how much my subjective sensibilities
on
what is icky matches whoever is talking about
technical debt.
So yes, I think everyone agrees icky stuff is bad, but sometimes
different
people have different ideas on what is icky and
how much ickiness the
icky
things contain. Furthermore there is a trap one
can fall into of only
fixing icky stuff, even if its only slightly icky, which is bad as then
you
don't actually accomplish anything else. As
with everything else in life,
moderation is the best policy (imo).
--
Brian
To set degree of ickyness you need a stakeholdergroup, which is often
just the sales department. When you neither have a stakeholder group
or sales department you tend to end up with ickyness set by the devs,
and then features win over bugs. Its just the way things are.
I believe the ickyness felt by the editors must be more visible to the
devs, and the actual impact the devs do on bugs to lower the ickyness
must be more visible to the editors.
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.
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.
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.
--
Brian