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 :-(