Le 10/04/2014 23:11, Dan Garry a écrit :
<snip>
As a team, we have responsibilities. For example, that
task that's on
there right now is a problem caused by our actions; we pulled that
extension for security reasons, then decided we couldn't reenable it due
to design issues. Therefore our actions have caused a very real
regression in our user experience. As the product manager, I find these
regressions concerning, and we have a responsibility to fix them.
Hello,
In this specific case, if the security is solved we can probably
reenable it despite its design issue unless that causes performances or
more security issues (or maybe it is flawed by design).
Right now, my only recourse to fix these user
experience regressions is
to ask politely for someone from the team to help me. I typically get a
lukewarm response to these requests. Meanwhile, I get a fair amount of
abuse directed at me by volunteers for not fixing these problems,
because I am the public face of the team and it (outwardly) looks like
we don't care to fix these relatively simple problems. Sure, it sucks
for us to do these random tasks, but it sucks hard for our users too. We
lose a lot of credibility with some of our volunteers for it.
I understand your pain. On the other hand I don't think our team has
any bandwidth left to get tiny changes in. Despite being named
'MediaWiki core' our scope is much larger than simply developing
MediaWiki. A lot of the simple development is happily delegated to
volunteers and we act as a gate to the production.
So yeah it certainly sucks to have nobody to respond, that is probably
because nobody has time to spend to write such features. I myself
landed 10 commits to core over the last 6 months, the longest one has
been actually written by Ori and the rest are tiny tweaks for tests or
the beta cluster.
So sure, I could spend half a day figuring out how to fix those micro
product tasks but our awesome volunteers will be more efficient than me
at that task.
So what I'm trying to do here is make it as easy
as humanely possible
for you guys, the overworked engineers, to pick these tasks up and get
them done. At the same time, I don't want to get sucked into maintaining
control over the task list, so
mediawiki.org <http://mediawiki.org> was
the simplest solution.
Fair, that is probably the easiest tool for you to maintain such a
backlog. I guess as long as you point folks to it constantly, there is
some chance that the entries will eventually be processed. I personally
tend to drop watch list notifications :-(
--
Antoine "hashar" Musso