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(a)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(a)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(a)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(a)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(a)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