Luiz Augusto lugusto@gmail.com writes:
Firstly, thank you very much for enabling DPL on all Wikisources! [1] It is IMO a pity that this request was fulfilled based only in a direct request, but at least it is now enabled.
Please help us to develop Wikimedia contents in foreign languages simply giving 30 minutes each week to check those requests!
30 minutes a week would be less attention than they are currently getting.
The Berlin Hackathon, was especially helpful in taking care of some of these shell requests. Take a look at http://hexm.de/2w for a list of requests closed during the hackathon. Of special note is Bug #5220 (https://bugzilla.wikimedia.org/5220), the request to “Enable email notification on changes to user talk pages also on big wikis.” It has been left for YEARS, much longer than any other request you mention.
There is hope for every bug, no matter how old.
However, I admit I have been giving non-shell requests a bit more attention in my bugmeistering because the people with shell access are pretty good about dealing with the requests. For example, of the 20 shell requests opened this month, only 12 have not yet been dealt with, which means 40% of shell requests opened in the past two weeks are already completed.
By comparison, only 85 of the 256 shell requests created since the first of the have not yet been closed, so 67% of the shell requests opened this year are completed.
That said, many of the open requests are open for a reason. For example, the LiquidThreads request that you list:
25609 https://bugzilla.wikimedia.org/show_bug.cgi?id=25609 Enable liquidthreads for the Wikimedia Brasil wiki (waiting since 2010-10-21)
is open because Andrew's LQT rewrite is ongoing. Last time I checked in with Andrew on this, he was finishing up the backend rewrite. That was at Easter, though, and I haven't checked back in on the LQT project to see when we could start deploying it again.
You've made a good point, though, and I'll be working with CT Woo and the operations team to make sure these requests get attention in a more timely manner.
Mark.
Hi,
Just a couple of notes regarding your email:
However, I admit I have been giving non-shell requests a bit more attention in my bugmeistering because the people with shell access are pretty good about dealing with the requests. For example, of the 20 shell requests opened this month, only 12 have not yet been dealt with, which means 40% of shell requests opened in the past two weeks are already completed.
Why not establish a limit for requests that do not pose problems? Say, a month. You could concentrate only on the bugs that are older than that and hope that the shell team will empty the queue before they enter your report.
By comparison, only 85 of the 256 shell requests created since the first of the have not yet been closed, so 67% of the shell requests opened this year are completed.
Unless there is a good reason (like for LQT), I would say (from the user POV) 5 months for such a request is excessive.
That said, many of the open requests are open for a reason. For example, the LiquidThreads request that you list:
25609 https://bugzilla.wikimedia.org/show_bug.cgi?id=25609 Enable liquidthreads for the Wikimedia Brasil wiki (waiting since 2010-10-21)
Such info should be added to the bug when you visit it and updated as often as possible. Many people making site requests (me included) do not actively follow MW developpement. This means that we only see the end result - it takes lots and lots of time to have an extension activated on our wikis.
Strainu
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.
Firstly, thank you very much for enabling DPL on all Wikisources! [1] It is IMO a pity that this request was fulfilled based only in a direct request, but at least it is now enabled.
Please help us to develop Wikimedia contents in foreign languages simply giving 30 minutes each week to check those requests!
30 minutes a week would be less attention than they are currently getting.
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.
MZMcBride
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)
Brion Vibber wrote:
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.
Thank you for the polite and detailed response; I really appreciate it. I've replied to this portion of the post off-list.
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.
Yes, okay, specificity would help here. Let me lay out some examples of problems I've hit.
If you want to work with Wikisource, one if its fundamental tools is the ProofreadPage extension. There's no API for it. Seriously. So any outside developers / third parties wanting to work with its content in place are out of luck, unless they want to screen-scrape or try to hack something up.
If you want to work with / re-use Wiktionary's content, you'd generally want to split the content up by language. People who want to re-use Wiktionary's content generally want to create a free English dictionary or a free French dictionary or a free Spanish dictionary. The Wiktionary dumps don't split the words by language, meaning that anyone wanting to re-use this content has to go through each page and try to parse it to find the English definitions or the French definitions or the Spanish definitions. There have been attempts by Toolserver users to make this situation less horrible, but people are then relying on volunteers and their (questionable) code, rather than being able to rely on Wikimedia producing useful dumps. Outside developers / third parties once again get screwed.
If you want to work with any Wikimedia wiki's content on a large scale, you have to deal with database dumps. For reasons unknown, there are no longer HTML dumps, only wikitext dumps. And there's only one fully working parser (on Wikimedia's servers). So if you want to get the rendered page contents of a lot of articles, your options are to use ?action=parse via the API (this will only take about two months for every article on the English Wikipedia) or you can try to grab the rendered HTML from the Squid servers. This makes outside development incredibly painful, if not prohibitively impossible, for most people.
These are examples of fundamental and underlying issues that prohibit outside developers / tool builders / dreamers from taking content and running wild with it. If there isn't a stable groundwork for others, it's fairly difficult to build something on top of it. Laying that groundwork seems like what Wikimedia should be doing. Otherwise, in my opinion, Wikimedia should end the charade of supporting "sister projects" and be upfront with developers, readers, editors, and other contributors that these projects are simply not supported.
One idea for the future might be to make all Google Summer of Code projects focus on sites other than Wikipedia. As you note (and as anyone paying any kind of attention has realized), Wikimedia's priority is Wikipedia. There are plenty of resources behind Wikipedia, but the directed volunteer efforts (such as GSOC) could be directed at all non-Wikipedias.
MZMcBride
"Brion Vibber" brion@wikimedia.org wrote in message news:BANLkTi=faYP8EkGw4AoAg+J+-LKPz+N27Q@mail.gmail.com...
On Tue, May 17, 2011 at 3:56 AM, MZMcBride z@mzmcbride.com wrote:
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.
Again, it would be better to have a 'NEEDINFO' resolution enabled for us to use in this case.
-- brion vibber (brion @ wikimedia.org / brion @ pobox.com)
The default BZ configuration comes, AFAIK, with a REMIND resolution. This was briefly reenabled during the BZ4 upgrade, but was subsequently disabled again and the bugs I had closed with it reclassed as LATER. This resolution seems to be broadly what you had in mind -- "We can't do anything with this as it stands because we need you to provide something, the ball's back in your court, ping us if you still want something done" -- and I don't really understand why it was (re)disabled.
--HM
On Wed, May 18, 2011 at 8:20 AM, Happy-melon happy-melon@live.com wrote:
The default BZ configuration comes, AFAIK, with a REMIND resolution. This was briefly reenabled during the BZ4 upgrade, but was subsequently disabled again and the bugs I had closed with it reclassed as LATER. This resolution seems to be broadly what you had in mind -- "We can't do anything with this as it stands because we need you to provide something, the ball's back in your court, ping us if you still want something done" -- and I don't really understand why it was (re)disabled.
--HM
Because we don't like it, If a bug is open and awaiting information it should be OPEN, not RESOLVED LATER dashed away where no one will ever look at it again, most people don't like having later enabled either :p.
On 18/05/11 00:44, K. Peachey wrote:
Because we don't like it, If a bug is open and awaiting information it should be OPEN, not RESOLVED LATER dashed away where no one will ever look at it again, most people don't like having later enabled either
That is why there is an UNCONFIRMED state. Once the bug got confirmed and has enough information, it will be made NEW.
It map very well to organisation having several levels of support. The first level being the call center which can have bug confirmed with the customer / in lab: unconfirm -> new, and then confirm bug closing once QA verified it (verified -> closed).
We are not using all those steps though. So we merely make them disappear by marking them resolved. The original opener can still reopen it, another user will just open a new bug which is not a big deal.
On Wed, May 18, 2011 at 8:44 AM, K. Peachey p858snake@gmail.com wrote:
On Wed, May 18, 2011 at 8:20 AM, Happy-melon happy-melon@live.com wrote:
The default BZ configuration comes, AFAIK, with a REMIND resolution. This was briefly reenabled during the BZ4 upgrade, but was subsequently disabled again and the bugs I had closed with it reclassed as LATER. This resolution seems to be broadly what you had in mind -- "We can't do anything with this as it stands because we need you to provide something, the ball's back in your court, ping us if you still want something done" -- and I don't really understand why it was (re)disabled.
--HM
Because we don't like it, If a bug is open and awaiting information it should be OPEN, not RESOLVED LATER dashed away where no one will ever look at it again, most people don't like having later enabled either :p.
Who's "we"? I know that I, for one, really don't like having bugs open and assigned to me that I can't do anything about without further information. It clutters my list of unresolved bugs. For a number of years, that list has been utterly useless to me because there are so many bugs that I don't know what to do with.
On Tue, May 17, 2011 at 6:20 PM, Happy-melon happy-melon@live.com wrote:
The default BZ configuration comes, AFAIK, with a REMIND resolution. This was briefly reenabled during the BZ4 upgrade, but was subsequently disabled again and the bugs I had closed with it reclassed as LATER. This resolution seems to be broadly what you had in mind -- "We can't do anything with this as it stands because we need you to provide something, the ball's back in your court, ping us if you still want something done" -- and I don't really understand why it was (re)disabled.
For our purposes, REMIND and LATER are pretty much the same thing. My proposal was to get rid of REMIND and only use LATER, to avoid confusion.
-Chad
On Tue, May 17, 2011 at 5:37 PM, Brion Vibber brion@wikimedia.org wrote:
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.
http://wikisource.org/wiki/WS:BUGS
On Wed, May 18, 2011 at 9:45 AM, John Vandenberg jayvdb@gmail.com wrote:
On Tue, May 17, 2011 at 5:37 PM, Brion Vibber brion@wikimedia.org wrote:
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.
The issue in question is not "old bugs", but this one:
MZMcBride:
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.
MZMcBride:
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.
There were *many* bugs closed that weekend. Which included duplicating to similar bugs and also wontfixing. It's not unlikely that some of them shouldn't have been closed. If I closed some of them in that way, please let me know. That said, the line between a marginal feature and a wontfix can be quite narrow, and we don't have a formal procedure for voting when to reject a proposal.
wikitech-l@lists.wikimedia.org