I missed the report on last week's bug triage, so to keep that snafu from repeating, you're getting this report right away. You can see the notes we made during the meeting on etherpad: http://hexm.de/37
(Note that in this report I reference the weekend sprints I have posted to the list in the past a few times here. After some encouragement at the Berlin Hack-a-thon and elsewhere, I plan to revive them this weekend.)
=== Block notice when editing talk page of blocked user doesn't go away after block expires === https://bugzilla.wikimedia.org/27858
Besides the problem that I managed to reproduce on enwiki, I brought this bug up because of bawolff's comment that he “has never liked how we only modify some timestamps for timezone”
I will try to reproduce this particular bug again after setting my preferences – I think it really is a bug.
As far as the larger problem, MediaWiki's inconsistent time display behavior, I've created a tracking bug (https://bugzilla.wikimedia.org/29235 MediaWiki is inconsistent in how it displays time) under which I'll try to gather instances of this problem.
=== Allow different directionality (rtl/ltr) for user interface and wiki content === https://bugzilla.wikimedia.org/6100
Robla put a note on this bug that indicated in might have been fixed and then reverted. Confused, I brought it up again so that we could discuss what was really needed to fix this bug.
The revision indicated in Robla's comment was related to this bug, but was only a small part of fixing it. Discussion with other developers indicates that this isn't a trivial problem but would be a major new feature.
=== Upgrade fails "Unknown character set: 'mysql4'" === https://bugzilla.wikimedia.org/29102
I'm going to try to get Chad to fix this one. Depending on his availability, I may have a go myself.
=== Cannot remove watchlist junk, either in Edit Watchlist page or by editing raw watchlist === https://bugzilla.wikimedia.org/28936
I had trouble testing this, but it looks like it is a real problem with how watchlists work when pages are removed. Roan put some steps for reproducing this into Etherpad and I'll work on getting them into Bugzilla and, perhaps, making an easy test case.
=== Long external link (which exceeds 313 characters) crashes PHP in Windows === https://bugzilla.wikimedia.org/29197
This is probably an upstream PHP/libpcre bug, and, so far, only reproducible on Windows XAMP. We briefly discussed testing for this and warning about it during installation. We're working around it now by using different regular expressions.
=== Pages loading without formatting too often === https://bugzilla.wikimedia.org/29153
This seems to be a frequently reported problem with 1.17, but it doesn't seem to be easily reproducible. I've updated the bug asking if the reporter can reproduce this easily.
[If anyone reading this can reproduce the problem in a fairly consistent matter, please contact me.]
=== Implement a way for authorized users to use Special:PasswordReset on other usernames === https://bugzilla.wikimedia.org/29135
A valid feature request, but just that. T. Gries has provided a lot of details, so this makes a good one for me to promote for a weekend sprint.
=== Slowness in accessing English Wikipedia === https://bugzilla.wikimedia.org/29034
Someone from Canada weighed in on this last week. I brought it up during the dev triage in case someone there had an idea, but it looks like I need to find out the status from Ops.
=== protected page not protected. user can edit === https://bugzilla.wikimedia.org/29021
This looks like it is the result of an unclear log message or a misinterpretation of the message. We don't plan on taking any action.
=== Require token for watching/unwatching pages === https://bugzilla.wikimedia.org/27655
This is a bug to fix a CSRF issue. During the triage meeting, Krinkle told us that he and Reedy had been working on this but needed someone else to follow it the rest of the way. I assigned the rest of the work (making the the non-javascript fallback use a token) to Bryan.
=== width of <gallery> always 100% === https://bugzilla.wikimedia.org/27540
I have put an example of the issue here: http://hexm.de/3b.
This is another good candidate for a weekend sprint.
== Ancient bugs with recent patches ==
For this week's triage, I tried adding in some ancient bugs with recently submitted patches. My thinking was that someone has made an effort to fix these recently. I'll probably use these from now on for weekend sprints, but not bring them up in Triage meetings.
In any case here they are:
=== Suppressed edits still appear in Special:DeletedContributions and Special:Undelete === https://bugzilla.wikimedia.org/19725
=== lang and hreflang attributes for interwiki links === https://bugzilla.wikimedia.org/4901
=== Different diff-colors no to discriminate red-green color blinds === https://bugzilla.wikimedia.org/11374
(Krinkle actually started working on making a gadget for this after the Triage meeting.)
=== Email notification mistakes log action for new page creation === https://bugzilla.wikimedia.org/14901
(I'm going to commit the provided patches.)
=== $wgSharedDB PostgreSQL support === https://bugzilla.wikimedia.org/16794
(After spotting this series of patches, I think we may have found someone to help maintain the PostgreSQL support.)
=== WAI-ARIA landmark roles to improve accessibility === https://bugzilla.wikimedia.org/18338
(This needs a bit more research… does anyone with a screen reader want to be my guinea pig?)
Am 02.06.2011 04:33, schrieb Mark A. Hershberger:
=== Implement a way for _only authorized users to use Special:PasswordReset on other usernames === https://bugzilla.wikimedia.org/29135
A valid feature request, but just that.... a lot of details, so this makes a good one for me to promote for a weekend sprint.
Because the implementation would touch some sensitive areas (password/login), I refrained from patching and would like someone to give me hints, or to help directly there.
* Problem to be solved: User A can trigger a password-mail to any other user B by accessing (simply by accessing Special:PasswordReset and inputting username B into the field)
* Situation: When logged-in users visit Special:PasswordReset, they see an _emtpy_ input field for entering an arbitrary username.
The _empty_ field does not make sense, because:...
... read the cumulative summary on https://bugzilla.wikimedia.org/show_bug.cgi?id=29135#c6
wikitech-l@lists.wikimedia.org