Perhaps a better example would be the Drupal community who has a total of ~1,071,600 issues and ~282,350 of those are open https://www.drupal.org/project/issues and they have several organizations https://www.drupal.org/organizations working on the software.
I do not understand how a large backlog is a problem. It is not an indication of anything.
On Fri, Mar 15, 2019 at 12:25 PM Strainu strainu10@gmail.com wrote:
În joi, 14 mar. 2019 la 22:23, Gergő Tisza gtisza@gmail.com a scris:
About backlogs in general, Chromium is probably the biggest open-source Google repo; that has currently 940K tickets, 60K of which
are
open, and another 50K have been auto-archived after a year of inactivity. (As others have pointed out, having a huge backlog and ruthlessly closing tasks that do not get on the roadmap are the only two realistic options, and the latter does have its advantages, no one here seems to be in favor of it.) We have 220K tasks in total, 40K of which are open, so that's in the same ballpark
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.
On Wed, Mar 13, 2019 at 3:02 PM Strainu strainu10@gmail.com wrote:
The main problem I see with the community wishlist is that it's a process beside the normal process, not part of it. The dedicated team takes 10 bugs and other developers another ~10. I think we would be much better off if each team at the WMF would also take the top ranked bug on their turf and solve it and bump the priority of all the other bugs by one (e.g. low->medium). One bug per year per team means at least 18 bugs (at least if [1] is up to date) or something similar.
Community Tech is seven people and they do ten wishlist requests a year. (Granted, they do other things too, but the wishlist is their main
focus.)
So you are proposing to reallocate on average 1-2 months per year for
every
team to work on wishlist wishes. That's about two million dollars of
donor
money. How confident are you that the wishlist is actually a good way of estimating the impact of tasks, outside of the narrow field where editors have personal experience (ie. editing tools)?
I'm 99.9% sure the wishlist is relevant in at least half the categories (Admins&patrollers, Bots&Gadgets, Editing, Notifications, Programs&Events, Watchlists, Wikidata, Wikisource, Wiktionary) and very likely (80%) also for Anti-harassment, Categories and Maps.
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.
[2] https://www.glassdoor.com/Salary/Wikimedia-Foundation-Salaries-E38331.htm
UploadWizard is not in active development currently.
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. I also said I will try to come up with a more detailed critique later on and see if it has any result.
Strainu
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l