Question to WMF: Backlog on bugs

classic Classic list List threaded Threaded
87 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

Andre Klapper-2
Hi and thanks for joining the discussion!

On Sat, 2019-03-16 at 20:37 -0400, Thomas Eugene Bishop wrote:

> Here’s a specific example, created in 2015:
>
> https://phabricator.wikimedia.org/T116145 <
> https://phabricator.wikimedia.org/T116145>
>
>
> A bug fix was provided years ago but never accepted or rejected. It’s
> the first and last MediaWiki bug ever assigned to me. I’ve just
> unassigned myself.
>
> In cases like this, remarks like “Because you did not fix these bugs”
> and “... anyone is free to pick it up and work on it ... No further
> response needed” miss the point. When a bug fix is provided, but
> nobody with authority to accept or reject it ever does so, that’s a
> failure on the part of those who have authority, not on the part of
> those who are able and willing to fix bugs. Sure, volunteers are
> “free” to waste their time!
>
> You need to use and share your authority more effectively, to “be
> bold” with accepting and rejecting bug fixes. Authorize more people
> to accept or reject bug fixes. Assign each proposed bug fix to one
> such person, starting with the oldest bugs. Then hold those people
> accountable. You don’t lack volunteers, you lack volunteers with
> authority.

I fully agree. I was referring to bug reports in my emails.

Code review is an area in which Wikimedia is very frustrating. There
are regular emails about patches by new contributors awaiting review
[1] but that obviously only covers a small group of contributors.
And while we recently started to have code stewardship reviews [2] to
fill some gaps in the list of responsible persons and teams [3] per
code base, we for example still lack meaningful statistics how big the
code review problem is, in general and per team.

andre

[1] https://lists.wikimedia.org/pipermail/wikitech-l/2019-March/091632.html
[2] https://www.mediawiki.org/wiki/Code_stewardship_reviews
[3] https://www.mediawiki.org/wiki/Developers/Maintainers
--
Andre Klapper | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

C. Scott Ananian
I'll echo Andre here: the specific problem of patches from new volunteer
devs which don't get timely responses is a real issue, and one which we
have attempted to address (as Andre described) but an area we could
probably still use additional ideas, accountability, etc for.

A secondary issue is that too much wiki dev is done by WMF/WMFDE employees
(IMO); I don't think the current percentages lead to an overall healthy
open source community. But (again in my view) the first step to nurturing
and growing our non-employee contributors is to make sure their patches are
timely reviewed.
  --scott

On Sat, Mar 16, 2019, 10:54 PM Andre Klapper <[hidden email]> wrote:

> Hi and thanks for joining the discussion!
>
> On Sat, 2019-03-16 at 20:37 -0400, Thomas Eugene Bishop wrote:
> > Here’s a specific example, created in 2015:
> >
> >       https://phabricator.wikimedia.org/T116145 <
> > https://phabricator.wikimedia.org/T116145>
> >
> >
> > A bug fix was provided years ago but never accepted or rejected. It’s
> > the first and last MediaWiki bug ever assigned to me. I’ve just
> > unassigned myself.
> >
> > In cases like this, remarks like “Because you did not fix these bugs”
> > and “... anyone is free to pick it up and work on it ... No further
> > response needed” miss the point. When a bug fix is provided, but
> > nobody with authority to accept or reject it ever does so, that’s a
> > failure on the part of those who have authority, not on the part of
> > those who are able and willing to fix bugs. Sure, volunteers are
> > “free” to waste their time!
> >
> > You need to use and share your authority more effectively, to “be
> > bold” with accepting and rejecting bug fixes. Authorize more people
> > to accept or reject bug fixes. Assign each proposed bug fix to one
> > such person, starting with the oldest bugs. Then hold those people
> > accountable. You don’t lack volunteers, you lack volunteers with
> > authority.
>
> I fully agree. I was referring to bug reports in my emails.
>
> Code review is an area in which Wikimedia is very frustrating. There
> are regular emails about patches by new contributors awaiting review
> [1] but that obviously only covers a small group of contributors.
> And while we recently started to have code stewardship reviews [2] to
> fill some gaps in the list of responsible persons and teams [3] per
> code base, we for example still lack meaningful statistics how big the
> code review problem is, in general and per team.
>
> andre
>
> [1]
> https://lists.wikimedia.org/pipermail/wikitech-l/2019-March/091632.html
> [2] https://www.mediawiki.org/wiki/Code_stewardship_reviews
> [3] https://www.mediawiki.org/wiki/Developers/Maintainers
> --
> Andre Klapper | Bugwrangler / Developer Advocate
> https://blogs.gnome.org/aklapper/
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

Gergo Tisza
In reply to this post by Strainu
On Fri, Mar 15, 2019 at 9:25 AM Strainu <[hidden email]> wrote:

> That's an overstatement: 18% (not counting bugs closed as declined) is
> almost double to 11%. If you're going this route, we're doing much
> worse than Chromium.
>

I have a hard time imagining that anyone would be upset that 18% of our
tasks are open but would be fine with that number being 11%. A hundred
times more is significant difference. 60% more, not really.
I just wanted to point out that open bugs being about one magnitude less
than total bugs is fairly normal for an opensource project (possibly closed
projects too, it's just harder to find data there). Just to have some more
data points: Firefox has 1.4M bugs, 140K are open; Debian has 140K active
and 800K archived bugs; PHP has 77K bugs, 37K of which are closed; Apache
has 47K bugs, and 5900 open ones (including LATER).

I'm not sure how you arrived at the $2M figure (even 36 months of dev
> time - 18 teams, 2 man-months/team - only add up to ~$400K, unless
> Glasdoor is waaay off on the salaries there [2]), but presumably going
> down on the list will also surface bugs and not only features, which
> will take less time to solve. Investing an additional 1% of the
> revenue into this seems reasonable to me.
>

I used $200K per year as a rough guesstimate for the total cost of one
man-year of development (which includes salary, taxes, benefits, office
space, event participation costs, salary for administration and management
which has to scale up with the number of developers...), which I think is
on the low end (for a mostly Bay Area based organization, anyway).
Also one month of a team's time is something like 5-6 months on average.

Anyway, the point is that we are talking about fairly large amounts of
donor money here, which should be spent responsibly. Taking community
feedback into account is important, but it's not the only thing that needs
to be taken into account (one should consider how much it impacts
contributors who are for some reason less likely to speak up; how much it
impacts readers; future maintenance costs; how well it matches current
capabilities; how well it fits the roadmap; how it compares in importance
to strategic priorities; etc). The wishlist (or voting in general) is not
an ideal tool for that.

IMO one opportunity for improvement there is having a list of bugs which
are relatively easy to fix (so people can work on them in their free time
or 10% time) but relatively important to (some group of) editors. There are
plenty of developers interested in working on tasks like that. But curating
it would not be a trivial effort. (I tried something similar with the
developer wishlist two years ago (except it wasn't limited to relatively
small issues, which I think is the main reason it wasn't very successful);
that took something like six weekends if I remember correctly. Granted, it
wasn't done in a particularly efficient manner, plus, some of the
infrastructure had to be invented.)

I did not claim (or asked) that it was. What I said is that it is an
> important part of the infrastructure and that it should be maintained
> properly.
>

Are there any components for which that is not true?

At a glance none if the 2019 wishlist requests involved UploadWizard, so it
does not seem like the most pressing concern on editors' mind. And
strategically, doing structured data storage first and fancy contribution
and display features afterwards is a whole lot easier than going the other
way (something we learned at our own expense with MediaViewer).


On Sat, Mar 16, 2019 at 8:23 AM Strainu <[hidden email]> wrote:

> A large backlog by itself is not alarming. A growing one for
> components deployed to WMF sites is. It indicates insufficient
> attention is given to ongoing maintenance of projects after they are
> no longer "actively developed", which in turn creates resentment with
> the reporters.
>

It really doesn't. The backlog is the contact surface between stuff that
exists and stuff that doesn't; all the things we don't have but which seem
realistically within reach. As functionality expands, that surface expands
too. It is a normal process.

(We do have projects which are basically unmaintained. Those are not
typically the ones producing lots of new tasks though, since most relevant
issues have been filed already. And realistically the choice is between
having poorly maintained components and having far less components. Would
undeploying UploadWizard, for example, reduce resentment? I don't think so.)
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

Gergő Tisza
In reply to this post by Thomas Eugene Bishop
On Sat, Mar 16, 2019 at 5:37 PM Thomas Eugene Bishop <
[hidden email]> wrote:

> A bug fix was provided years ago but never accepted or rejected. It’s the
> first and last MediaWiki bug ever assigned to me. I’ve just unassigned
> myself.
>
> https://phabricator.wikimedia.org/T149639https://phabricator.wikimedia.org/T149639
> In cases like this, remarks like “Because you did not fix these bugs” and
> “... anyone is free to pick it up and work on it ... No further response
> needed” miss the point. When a bug fix is provided, but nobody with
> authority to accept or reject it ever does so, that’s a failure on the part
> of those who have authority, not on the part of those who are able and
> willing to fix bugs. Sure, volunteers are “free” to waste their time!
>

The code review backlog is a genuine problem (I'd say it's in the top 3
problems we have, along with lack of good documentation, and
well-structured testable code). It's entirely unrelated to the task backlog
and the other topics in this thread, though.
There has been plenty of discussion on it and various attempts at
addressing (you can see some in T78768 [1], or in various Wikimedia
Developer Summit sessions such as T149639 [2]).
Unfortunately without much result so far, but the problem is definitely no
lack of awareness. (I'd argue that lack of organizational focus /
commitment *is* a problem, so making your voice heard in the various
planning processes would be helpful. wikitech-l is not a great place for
that, though.)

You need to use and share your authority more effectively, to “be bold”
> with accepting and rejecting bug fixes. Authorize more people to accept or
> reject bug fixes. Assign each proposed bug fix to one such person, starting
> with the oldest bugs. Then hold those people accountable. You don’t lack
> volunteers, you lack volunteers with authority.
>

Being able to accept bug fixes effectively means being able to deploy code
to Wikimedia production, which has security and robustness implications. So
there are some limits on how widely we can distribute that authority.
That said, we are probably more conservative than we should be, and
nominating new reviewers [3] is one of the more useful things one could do.


[1] https://phabricator.wikimedia.org/T78768
[2] https://phabricator.wikimedia.org/T149639
[3]
https://www.mediawiki.org/wiki/Gerrit/Privilege_policy#Requesting_Gerrit_privileges
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

Strainu
In reply to this post by Gergo Tisza
În dum., 17 mar. 2019 la 23:22, Gergo Tisza <[hidden email]> a scris:

> On Sat, Mar 16, 2019 at 8:23 AM Strainu <[hidden email]> wrote:
>
> > A large backlog by itself is not alarming. A growing one for
> > components deployed to WMF sites is. It indicates insufficient
> > attention is given to ongoing maintenance of projects after they are
> > no longer "actively developed", which in turn creates resentment with
> > the reporters.
> >
>
> It really doesn't. The backlog is the contact surface between stuff that
> exists and stuff that doesn't; all the things we don't have but which seem
> realistically within reach. As functionality expands, that surface expands
> too. It is a normal process.

Except functionality doesn't expand for not actively developed
products, but the backlog does.

> (We do have projects which are basically unmaintained. Those are not
> typically the ones producing lots of new tasks though, since most relevant
> issues have been filed already. And realistically the choice is between
> having poorly maintained components and having far less components. Would
> undeploying UploadWizard, for example, reduce resentment? I don't think so.)

It's all relative: if UW would be undeployed in favor of a different
component that would cover some of the stuff lacking from UW, than I
don't think we'd see much resentment. I would personally love to see
regular code stewardship reviews for every deployed components which
haven't had one in 2-3 years. After a couple of such iterations, I'm
pretty sure we'd have a non-negligible number of extensions
undeployed. Would that lead to resentment? Sure, but I don't think the
level would be comparable. The main problem I see is there is no good
way to decide how important something is beyond usage metrics.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

Pine W
Hi,

First, I'll respond to Scott's comment that " A secondary issue is that too
much wiki dev is done by WMF/WMFDE employees (IMO); I don't think the
current percentages lead to an overall healthy open source community. But
(again in my view) the first step to nurturing and growing our non-employee
contributors is to make sure their patches are timely reviewed."

I'll make a distinction between two types of proposals:

a, Offload development work from WMF onto volunteers, and
b, Grow and support the population of developers..

The first type of proposal is likely to get a cold reception from me, but
I'm more supportive of the second. I don't know how many non-Wikimedia
organizations which use MediaWiki software have staff that contribute in
significant ways to WMF in the forms of software, time, or money, but
growing the significance of those contributions sounds like a good idea. I
also like programs such as GSoC and Outreachy, and for WMF providing
support for volunteer devs who create tools, bots, etc. on their own
initiative.

Second, returning to the subject of technical debt, my understanding was
that WMF staff were concerned for years about the accumulation of technical
debt, but in this thread I get the impression that WMF staff has changed
their minds. Am I misunderstanding something? If the consensus opinion
among the staff changed, how and why did that change happen?

Thanks,

Pine
( https://meta.wikimedia.org/wiki/User:Pine )
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

bawolff
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

On Mon, Mar 18, 2019 at 8:17 PM Pine W <[hidden email]> wrote:

> Hi,
>
> First, I'll respond to Scott's comment that " A secondary issue is that too
> much wiki dev is done by WMF/WMFDE employees (IMO); I don't think the
> current percentages lead to an overall healthy open source community. But
> (again in my view) the first step to nurturing and growing our non-employee
> contributors is to make sure their patches are timely reviewed."
>
> I'll make a distinction between two types of proposals:
>
> a, Offload development work from WMF onto volunteers, and
> b, Grow and support the population of developers..
>
> The first type of proposal is likely to get a cold reception from me, but
> I'm more supportive of the second. I don't know how many non-Wikimedia
> organizations which use MediaWiki software have staff that contribute in
> significant ways to WMF in the forms of software, time, or money, but
> growing the significance of those contributions sounds like a good idea. I
> also like programs such as GSoC and Outreachy, and for WMF providing
> support for volunteer devs who create tools, bots, etc. on their own
> initiative.
>
> Second, returning to the subject of technical debt, my understanding was
> that WMF staff were concerned for years about the accumulation of technical
> debt, but in this thread I get the impression that WMF staff has changed
> their minds. Am I misunderstanding something? If the consensus opinion
> among the staff changed, how and why did that change happen?
>
> Thanks,
>
> Pine
> ( https://meta.wikimedia.org/wiki/User:Pine )
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

Derk-Jan Hartman
In reply to this post by Pine W
>
> Second, returning to the subject of technical debt, my understanding was
> that WMF staff were concerned for years about the accumulation of technical
> debt, but in this thread I get the impression that WMF staff has changed
> their minds. Am I misunderstanding something?


Last year has seen a lot of focus on Technical Debt. WMF also has a core
platform team now, which finally allows a more sustainable chipping away at
some of the technical debt. Lastly our CI tools now help to gradually clean
up technical debt as well. All this has showed that fixing technical debt
works and can be done (even for MediaWiki). So this is why you observe a
bit more relaxed attitude to this. There are still loads of problems and
things that need fixing, but there is light on the horizon so people are
less panicky about it.

DJ


On Mon, Mar 18, 2019 at 9:17 PM Pine W <[hidden email]> wrote:

> Hi,
>
> First, I'll respond to Scott's comment that " A secondary issue is that too
> much wiki dev is done by WMF/WMFDE employees (IMO); I don't think the
> current percentages lead to an overall healthy open source community. But
> (again in my view) the first step to nurturing and growing our non-employee
> contributors is to make sure their patches are timely reviewed."
>
> I'll make a distinction between two types of proposals:
>
> a, Offload development work from WMF onto volunteers, and
> b, Grow and support the population of developers..
>
> The first type of proposal is likely to get a cold reception from me, but
> I'm more supportive of the second. I don't know how many non-Wikimedia
> organizations which use MediaWiki software have staff that contribute in
> significant ways to WMF in the forms of software, time, or money, but
> growing the significance of those contributions sounds like a good idea. I
> also like programs such as GSoC and Outreachy, and for WMF providing
> support for volunteer devs who create tools, bots, etc. on their own
> initiative.
>
> Second, returning to the subject of technical debt, my understanding was
> that WMF staff were concerned for years about the accumulation of technical
> debt, but in this thread I get the impression that WMF staff has changed
> their minds. Am I misunderstanding something? If the consensus opinion
> among the staff changed, how and why did that change happen?
>
> Thanks,
>
> Pine
> ( https://meta.wikimedia.org/wiki/User:Pine )
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

Andre Klapper-2
In reply to this post by Strainu
On Sat, 2019-03-16 at 17:22 +0200, Strainu wrote:
> That being said, their org stats are pretty awsome, is there any way
> to obtain similar stats from Phabricator/Gerrit (at least by email
> domain if nothing else)?

See https://www.mediawiki.org/wiki/Community_metrics

andre
--
Andre Klapper | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

John Erling Blad
In reply to this post by Gergo Tisza
> On Sat, Mar 16, 2019 at 8:23 AM Strainu <[hidden email]> wrote:
>
> > A large backlog by itself is not alarming. A growing one for
> > components deployed to WMF sites is. It indicates insufficient
> > attention is given to ongoing maintenance of projects after they are
> > no longer "actively developed", which in turn creates resentment with
> > the reporters.
> >
>
On Sun, Mar 17, 2019 at 10:22 PM Gergo Tisza <[hidden email]> wrote:
>
> It really doesn't. The backlog is the contact surface between stuff that
> exists and stuff that doesn't; all the things we don't have but which seem
> realistically within reach. As functionality expands, that surface expands
> too. It is a normal process.
>

This isn't quite right, it only hold in some kind of simplified and
idealized environment.

There are several axis, not only what exist. For example existing and
non-existing features might be on the same axis, while it is hard to
say that functional vs non-functional code is on the same axis. If you
say these two are on the same axis, "stuff that exists", then you end
up arguing fixing bugs would be a problem as it expands the feature
space, thus will increase the total space and then increase the
technical debt.

This will imply that introducing a critical bug will solve the
technical debt, as the contact space will collapse. Fairly an
acceptable solution! ;D

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

John Erling Blad
In reply to this post by C. Scott Ananian
On Sun, Mar 17, 2019 at 2:38 PM C. Scott Ananian <[hidden email]> wrote:
>
> A secondary issue is that too much wiki dev is done by WMF/WMFDE employees
> (IMO); I don't think the current percentages lead to an overall healthy
> open source community. But (again in my view) the first step to nurturing
> and growing our non-employee contributors is to make sure their patches are
> timely reviewed.
>   --scott

I find this argument strange, as it imply there is some kind of
magical difference between contributions from an employee and a
community member. There are no such difference. Both the employee and
the community member should take responsibility for the code base, but
that does not imply they should take the same actions on that code
base.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

John Erling Blad
In reply to this post by bawolff
On Mon, Mar 18, 2019 at 10:52 PM bawolff <[hidden email]> 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.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

bawolff
On Monday, March 18, 2019, John Erling Blad <[hidden email]> wrote:

> On Mon, Mar 18, 2019 at 10:52 PM bawolff <[hidden email]> 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
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

John Erling Blad
On Tue, Mar 19, 2019 at 12:53 PM bawolff <[hidden email]> 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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

Gergő Tisza
In reply to this post by Derk-Jan Hartman
On Mon, Mar 18, 2019 at 3:01 PM Derk-Jan Hartman <
[hidden email]> wrote:

> Last year has seen a lot of focus on Technical Debt. WMF also has a core
> platform team now, which finally allows a more sustainable chipping away at
> some of the technical debt.


Yeah. Having tech debt is never great but what gets people concerned is
when it just grows and grows, and management dismisses concerns because it
is always more important to have the next feature out quickly. We used to
have a bit of that problem, but IMO there have been lots of positive
changes in the last two years or so, and there is now a credible
organization-wide effort now to get debt under control (mainly looking at
the Platform Evolution program here). Having the core platform team also
helped a lot, and in my impression some other teams that had in the past
focused on fast feature iteration have also been given more space to do
things right.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

David Barratt
In reply to this post by John Erling Blad
All software development costs someone something. Software does not change
without someone paying something for it (even if that is just their own
time, time has value).

To that end, technical debt, is like any other software change. There is no
difference between solving technical debt, fixing bugs, or creating new
features. All of these changes must have a "business value" associated with
them. If you cannot justify the value of the change, why are you doing it?
If you can, then you know what it is worth.

A lot of technical debt has a business case that it makes future software
development slower. Or to borrow some of the examples from this thread, it
takes longer to find something in your home, if your home is not organized.
Likewise, it takes longer to fix bugs and develop new features if the code
is not organized and provides a pleasant developer experience.

It is up to individual developers to surface the issues that have the most
value to the business (from a technical or user perspective) and it is up
to the product owners to make a determination of what truly has the most
value to the business. In other words, what gets Wikimedia the greatest
bang for the buck? I am thankful that it is not up to me to answer that
question. :)

On Tue, Mar 19, 2019 at 11:49 AM John Erling Blad <[hidden email]> wrote:

> On Tue, Mar 19, 2019 at 12:53 PM bawolff <[hidden email]> 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
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

bawolff
In reply to this post by John Erling Blad
On Tue, Mar 19, 2019 at 3:49 PM John Erling Blad <[hidden email]> wrote:

>
>
> 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.
>

Nobody claimed they were. In fact, everyone said the opposite. I think
you're just misunderstanding the definitions of the words being used(?)


>
> > 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
>

Well lets make it explicit - If you want change, but refuse to say what
change (whether that be structural or whether that be specific bugs you
want fixed) then it is 100% your fault that the change doesn't happen.
Complaining people/orgs won't change but not saying how you want people to
change is just a waste of everyone's time.

Developers are people not telepaths.

--
Brian
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

Pine W
In reply to this post by Gergő Tisza
On Tue, Mar 19, 2019 at 4:16 PM Gergő Tisza <[hidden email]> wrote:

> On Mon, Mar 18, 2019 at 3:01 PM Derk-Jan Hartman <
> [hidden email]> wrote:
>
> > Last year has seen a lot of focus on Technical Debt. WMF also has a core
> > platform team now, which finally allows a more sustainable chipping away
> at
> > some of the technical debt.
>
>
> Yeah. Having tech debt is never great but what gets people concerned is
> when it just grows and grows, and management dismisses concerns because it
> is always more important to have the next feature out quickly. We used to
> have a bit of that problem, but IMO there have been lots of positive
> changes in the last two years or so, and there is now a credible
> organization-wide effort now to get debt under control (mainly looking at
> the Platform Evolution program here). Having the core platform team also
> helped a lot, and in my impression some other teams that had in the past
> focused on fast feature iteration have also been given more space to do
> things right.



Thanks very much for the explanations regarding that point.

One of my continuing concerns is that, as far as I know, no one has a way
of reliably quantifying the scale of the technical debt or measuring how it
is changing over time. It sounds like the internal view in WMF is that the
situation is improving, which is good to hear. However, I would prefer to
have a way to measure technical debt and how it is changing. If that
information is available then I think that making decisions about
resources, priorities, etc. will involve less guesswork. I think that this
proposal could align with WMF's work on code health.(See
https://www.mediawiki.org/wiki/Code_Health).

Pine
( https://meta.wikimedia.org/wiki/User:Pine )
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

David Barratt
>
> I would prefer to have a way to measure technical debt and how it is
> changing.
>

I think the entire software industry would prefer to have that, but as far
as I know, that type of measurement does not exist.

On Wed, Mar 20, 2019 at 4:23 PM Pine W <[hidden email]> wrote:

> On Tue, Mar 19, 2019 at 4:16 PM Gergő Tisza <[hidden email]> wrote:
>
> > On Mon, Mar 18, 2019 at 3:01 PM Derk-Jan Hartman <
> > [hidden email]> wrote:
> >
> > > Last year has seen a lot of focus on Technical Debt. WMF also has a
> core
> > > platform team now, which finally allows a more sustainable chipping
> away
> > at
> > > some of the technical debt.
> >
> >
> > Yeah. Having tech debt is never great but what gets people concerned is
> > when it just grows and grows, and management dismisses concerns because
> it
> > is always more important to have the next feature out quickly. We used to
> > have a bit of that problem, but IMO there have been lots of positive
> > changes in the last two years or so, and there is now a credible
> > organization-wide effort now to get debt under control (mainly looking at
> > the Platform Evolution program here). Having the core platform team also
> > helped a lot, and in my impression some other teams that had in the past
> > focused on fast feature iteration have also been given more space to do
> > things right.
>
>
>
> Thanks very much for the explanations regarding that point.
>
> One of my continuing concerns is that, as far as I know, no one has a way
> of reliably quantifying the scale of the technical debt or measuring how it
> is changing over time. It sounds like the internal view in WMF is that the
> situation is improving, which is good to hear. However, I would prefer to
> have a way to measure technical debt and how it is changing. If that
> information is available then I think that making decisions about
> resources, priorities, etc. will involve less guesswork. I think that this
> proposal could align with WMF's work on code health.(See
> https://www.mediawiki.org/wiki/Code_Health).
>
> Pine
> ( https://meta.wikimedia.org/wiki/User:Pine )
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

Pine W
:) Structured data exists regarding many other subjects such as books and
magazines. I would think that a similar approach could be taken to
technical debt. I realize that development tasks have properties and
interactions that change over time, but I think that having a better
quantitative understanding of the backlog would be good and would likely
improve the quality of planning and resourcing decisions.

To use an analogy, as far as I know there is no project management system
that reliably produces accurate estimates of the time and resources
required to complete large projects, but I think that attempting to use a
project management system is, in many cases, better than trying to execute
a large project without a project management system.

Pine
( https://meta.wikimedia.org/wiki/User:Pine )
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
12345