În joi, 14 mar. 2019 la 22:23, Gergő Tisza <gtisza(a)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(a)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