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)? What a wonderful world that would be! Unfortunately, all too often I > feel that objective measures (such as "+1" on bugs, duplicates etc.) > have no effect on prioritization. > Leaving aside how objective those measures are, in my when the task is related to a product owned by a team, they are aware and take it into account. (Which does not necessarily mean they agree, of course.) A lot of production components don't really have an owner, though. (Or only do to the extent that there is someone who can be pulled away from their normal job if the thing catches fire.) That's just the reality of running the website we have with the capacity we have - the alternative would be undeploying things or not starting new projects for a long time. The Wikimedia movement happens to be in the middle of its strategic planning process, so if you want to argue for either of these things, this is a good time to do it. (Not a good place, though.) - UploadWizard (2 with high priority, 40 with normal, a few dozens > low, hundreds more untriaged): this is the project that got us out of > the "overloading the lang parameter for customizing the uploader" era, > the project that is used by millions of people every year, including > during every photo contest > UploadWizard is not in active development currently. If you want to argue that the Multimedia team should be reassigned to work on it (and drop the Structured Data on Commons project), or some other rearrangement should be made, that's a specific proposal that can be meaningfully discussed. (Probably not here, though - that's a matter of movement strategy, not a technical decision. So maybe better suited to wikimedia-l.) Saying that some project should be picked up, without saying what should be dropped to make space, is an easy thing to do. Not all that useful though. (As an aside, I'd love to see more people self-organize to get more say in how priorities are decided. If you look at the discussion pages on WMF annual plans, movement strategy and so on, they do not give the impression of a community that's seriously interested in its own future.) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
