On Fri, Mar 15, 2019 at 9:25 AM Strainu <strainu10(a)gmail.com> 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 <strainu10(a)gmail.com> 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.)