On Tue, May 17, 2011 at 3:56 AM, MZMcBride <z...@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) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
