On Tue, May 17, 2011 at 3:56 AM, MZMcBride <z(a)mzmcbride.com> wrote:
Mark A. Hershberger wrote:
There is hope for every bug, no matter how old.
As long as people stop resolving old bugs as "wontfix" simply because
they're old. I went through and re-opened quite a few bugs that were
improperly marked as resolved over the weekend.
People take time to register an account on Bugzilla, describe their issue,
and then wait, often for _years_, for their issue to get looked at, much
less worked on and resolved. I can't really stress enough how completely
unacceptable it is to go around marking these bugs as "wontfix" without any
explanation or simply because it's been a long time since the bug was
filed.
MZ, if you're aware of *any* specific bugs where this is an issue, please
let me or Mark know and we'll take a look at them.
For old shell requests, one issue is that old discussions and consensuses
may no longer apply several years later -- have the conditions changed? Has
there been huge turnover in the community? Will people be pleased that
something is done or angry that something they've never heard of suddenly
changed without their having any voice in it?
In this case generally what we'll try to do is *ping the affected community*
to double-check if the old conditions and decisions stand, and then go ahead
and do it. These won't generally be closed as WONTFIX without actually
attempting to get that info -- or if they are it's as an intermediate stage
along with a request to reopen if more info comes through.
A 'NEEDINFO' resolution would probably be better than 'WONTFIX' for this
case, and we should see if we can enable that. Ensuring that devs know where
to go to ask for a status & consensus update in case the original filer &
CC'd people are unavailable would also help to make these go more
consistently.
When it comes to 'this doesn't work as I expected' bugs, if there's no
apparent way to reproduce the bug, and the original filer doesn't respond,
then closing out is not unreasonable.
Again, it would be better to have a 'NEEDINFO' resolution enabled for us to
use in this case.
I actually took this to mean sister projects (non-Wikipedias), not foreign
language projects. If Wikisource has gotten 30 minutes
of Wikimedia
Foundation development time _this year_, I'd be shocked.
Wikisource could definitely use more attention; we're still thinking about
ways to keep some of the smaller projects more in the loop.
The primary method is by ensuring that folks can do site script & gadget
JavaScript development without bottlenecking through Wikimedia which as a
matter of mission has prioritized keeping servers running and Wikipedia
functional.
Wiktionary and Commons have created a *lot* of additional UI functionality
this way, without that bottleneck, and that's something I'm very happy
about.
Wikisource has a number of extensions that were targeted specifically to it
(classic DPL, labeled section transclusion, PagedTiffHandler, ProofreadPage)
which at least get some review maintenance but are mostly created &
maintained by volunteers. Making sure that they're up to date, modernized,
user-friendly, and well-performing is something that we at Wikimedia should
at least be supporting -- and I hope we'll be able to assign a little more
explicit time to making that happen. To date, they generally get maintenance
updates from volunteers but deployment doesn't get pushed, so the old
versions stay in place until a major upgrade with our current deployment
system.
But for the meantime, I can only say that it's important to accentuate the
positive -- find specific projects that need some effort, and help round up
people to help with them.
-- brion vibber (brion @
wikimedia.org / brion @
pobox.com)