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