Wow, this thread has become quite huge (which is a good problem to have!). Trying to repond to a few messages in a single email.
În dum., 10 mar. 2019 la 01:23, Dan Garry (Deskana) djgwiki@gmail.com a scris:
I'm confused by this. I didn't mention volunteer teams taking over projects at all, and I don't think that'd work except in very rare and limited circumstances. I was talking about people helping with bug triage on Phabricator.
Got it. Glad we agree that project maintenance is the responsibility of the WMF. :) Bug triage (and even solving) is a great way of implicating volunteer developers, the problem is what do you do with bugs on projects where there are no volunteers. My take is that the paid teams that have ownership of those products should offer a certain degree of maintenance at least to widely deployed extensions (i.e. on all versions of a project). The (negative) example I like to give is Content Translation, were all bugfixes on v1 were stopped until v2 was developed, process that was delayed by at least a year if not 2 compared to initial estimates. During this time tech ambassadors were simply left with the task of explaining to users what they can do to save their work (hint: nothing). That just shouldn't happen.
The projects belong to the community at large, not just the technical subcommunity. They are the ones affected by the bugs and also they are the ones that need our support. So why should they be ignored in taking this decision?
I'm confused by this too. I wasn't talking about ownership of the Wikimedia projects, I was again talking about the bug backlog, which anyone is welcome to get involved in simply by registering an account.
Me too. Prioritization should involve (as much as possible, and certainly more than now) people reporting bugs, regardless of their ability to provide a patch for the bug they file. If we can go further into the communities, even better.
My proposal is to begin the discussion here: how can we better relay issues that areSee above - "anyone is welcome" is not enough. more important to communities than new features? How can we have a "community whishlist for bugs"?
The community wishlist explicitly accepts requests to fix bugs, as well requests for new features. So, is what you're asking for some process to supplement that?
A totally new process is not needed nor desirable. Improvements could be easily done that would improve the overall results.
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.
As a side note, even this process has degraded over time: check out how empty is the list for 2017 [2] compared to 2016. [3]
[1] https://meta.wikimedia.org/wiki/Template:Wikimedia_Foundation_departments [2] https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2017/Results [3] https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2016/Results
În dum., 10 mar. 2019 la 07:42, Victoria Stavridou-Coleman victoria@gocolemans.com a scris:
Re reading this now on the ground in Austin, reminds me not to send emails in a hurry from an airplane! So trying again - hopefully more grammatically sound this time!
The Tech Engagement team (which includes Wikimedia Cloud Services) in the Tech department is investing in a developer advocacy team who I hope will (amongst other things) speak on behalf of the communities that are affected by tech debt.
That should help, as long as they speak within the normal development process and not in parallel. Looking forward to seeing the official announcement.
În dum., 10 mar. 2019 la 02:28, bawolff bawolff+wn@gmail.com a scris:
Regarding:
My proposal is to begin the discussion here: how can we better relay issues that are more important to communities than new features? How can we have a "community whishlist for bugs"?
Well fundamentally it starts with making a list.
Change happens when stuff is measurable, and people can work towards a goal. Failing that, change happens when people can be held accountable. Objective measures are needed.
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.
if you for example knew how much time WMF currently spends on bug fixing, and you have an idea of how much time you think they should be spending. Even if management doesn't agree with your proposal, it would at least be specific enough to debate.
I have no way of finding that, do I? If there is one, I would be very curious to learn of it.
În lun., 11 mar. 2019 la 16:58, Bartosz Dziewoński matma.rex@gmail.com a scris:
In my experience WMF teams usually have a way to distinguish "bugs we're going to work on soon" and "bugs we're not planning to work on, but we'd accept patches". This is usually public in Phabricator, but not really documented.
Yes, and also not uniform between teams and prone to change on each team reorg. Having a list would would be great, but I'm not sure how maintainable it is. Would you like to start one? ;)
În mar., 12 mar. 2019 la 01:29, John Erling Blad jeblad@gmail.com a scris:
It seems like some projects simply put everything coming from external sources into deep freezer or add "need volunteer". If they respond at all. In some cases it could be that the projects are defunc.
No deployed project should be considered defunct. But I agree with others - naming them would help. Let me start: - ContentTranslation v1 (obsolete now, has been unmaintained for 2 years while in production) - 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
I encourage you all to add more examples.
Thanks to all who chimed in on the subject. Strainu