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 <strain...@gmail.com> wrote: > În joi, 14 mar. 2019 la 22:23, Gergő Tisza <gti...@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 <strain...@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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
