Wikitech-l June 2010

wikitech-l@lists.wikimedia.org

81 participants
58 discussions

trackback.php suggestion
by ed neville 29 Jun '10

29 Jun '10

Hi All, Recently I had a thought about trackback.php to attempt to discard spam so I've made this minor alteration. Could be it reviewed and perhaps included? Thanks The purpose of this is to simply reject trackback requests when the source of the connection is ipv4 and stored in a RBL (I don't know how well maintained ipv6 RBL databases are). This requires $wgUseTrackbacksRBL==true to be added to LocalSettings.php Index: trackback.php =================================================================== @@ -43,17 +43,33 @@ $tburl = strval( $_POST['url'] ); $tbname = strval( @$_POST['blog_name'] ); $tbarticle = strval( $_REQUEST['article'] ); +$tbip = strval( $_SERVER['REMOTE_ADDR'] ); $title = Title::newFromText($tbarticle); if( !$title || !$title->exists() ) XMLerror( "Specified article does not exist." ); + +if( $wgUseTrackbacksRBL==true && substr_count( $tbip, ":" ) == 0 && substr_count( $ip, "." ) > 0 ) { + + $rbl_list = array( "zen.spamhaus.org", "dnsbl.njabl.org", "dnsbl.sorbs.net", "bl.spamcop.net" ); + + foreach( $rbl_list as $rbl_site ) { + $ip_arr = array_reverse( explode( '.', $tbip ) ); + $lookup = implode( '.', $ip_arr ) . '.' . $rbl_site; + if( $lookup != gethostbyname( $lookup ) ) { + XMLerror( $tbip . " is listed in " . $rbl_site ); + } + } +} + Thanks for your time. -- Best regards, Ed http://www.s5h.net/

2 2

Wikisource bugs
by Lars Aronsson 29 Jun '10

29 Jun '10

There is a lot of potential in Wikisource, but it depends heavily on the ProofreadPage extension and it has several bugs that are reported but don't get fixed. ThomasV is the main developer and perhaps he is the only maintainer? It would be in the interest of the Wikimedia Foundation to assign a salaried developer or two into developing a more robust framework for Wikisource, either by improving the existing extension or by integrating some or all of its functionality into MediaWiki proper. People everywhere have a need to make some PDF (or Djvu) document available on a website, page by page, with the ability to add categories and talk pages. This ability is what the ProofreadPage extension adds to MediaWiki. In my mind, it is as essential as the support for uploading JPEG images and automatically generating thumbnails. Adding multipage documents to a wiki should be a far more common need than adding mathematical equations. -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

2 1

Re: [Wikitech-l] [Wikisource-l] Wikisource bugs
by Lars Aronsson 29 Jun '10

29 Jun '10

On 06/28/2010 11:25 PM, Birgitte SB wrote: > Are you thinking of some bugs in paticular? I would like to see what > has already been said at bugzilla if you have the numbers. Force now to look, I'm surprised to find there really are only a few reported bugs in the ProofreadPage extension. Some of the bugs I've long waited for to be fixed are instead in the PDF/Djvu page extraction, which is not part of ProofreadPage, https://bugzilla.wikimedia.org/show_bug.cgi?id=21526 https://bugzilla.wikimedia.org/show_bug.cgi?id=23326 I have a long time frustration with how over-complicated ProofreadPage is with its extra namespaces, new tags and dozens of parameters that each newcomer needs to learn, and it spilled over yesterday when I registered https://bugzilla.wikimedia.org/show_bug.cgi?id=24168 If there are more bugs, they should be reported in Bugzilla. But what also really needs to be done is to reconsider if ProofreadPage really needs to be all this complicated. Maybe I should register that as a bug? I wish to clarify that my first post should not be read as a personal attack on ThomasV. We all want Wikisource to improve and grow, and we're working together towards that goal. -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

1 0

"Reject" button for Pending Changes
by Rob Lanphier 28 Jun '10

28 Jun '10

Hi everyone, There is mounting demand for a "reject" button (or "decline") in several conversations about Pending Changes: http://en.wikipedia.org/wiki/Wikipedia:Pending_changes/Feedback#Unapprove_b… ...along with a lot of confusion about "unaccept": http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:Pending_Changes_issues… http://en.wikipedia.org/wiki/Wikipedia_talk:Pending_changes#Unaccept_on_Ern… http://en.wikipedia.org/wiki/Wikipedia_talk:Pending_changes#I_don.27t_get_it http://en.wikipedia.org/wiki/Help_talk:Pending_changes#Can.27t_get_it_to_wo… The solution we've proposed is a "reject" button which would replace the "unaccept" button in most contexts: http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia:Reject_Pending_Revision However, there are some misgivings about implementing such a feature: http://flaggedrevs.labs.wikimedia.org/wiki/Wikimedia_talk:Reject_Pending_Re… In short, the worry is that a convenient "reject" button will cause editors to introduce changes they never intended to introduce. The way that we need to implement "reject" is to undo all edits between the rejected revision and the latest accepted revision. Before we plow ahead and implement this, we'd like to get some developer feedback on this. For example, let's say that there are three pending revisions in the queue. That means there is the latest accepted revision (we'll call "A1"), and three pending revisions ("P1", "P2", and "P3"). P3 is the latest pending revision, while P1 and P2 are intermediate pending revisions. The specification says that when viewing the diff between A1 and P3, the "reject" button is enabled. A more conservative school of thought says that the "reject" button shouldn't be enabled, because its possible that P1 was a valid revision that was vandalized by P2, and the only way to tell is to look at the revision history. However, this should be reasonably rare, and the diff remains in the edit history to be rescued, and can be reapplied if need be. A competing problem is that disabling the "reject" button will result in the same confusion we're already seeing today. Thoughts? Rob

6 17

Bugzilla Weekly Report
by reporter＠isidore.wikimedia.org 28 Jun '10

28 Jun '10

MediaWiki Bugzilla Report for June 21, 2010 - June 28, 2010 Status changes this week Bugs NEW : 121 Bugs ASSIGNED : 6 Bugs REOPENED : 17 Bugs RESOLVED : 81 Total bugs still open: 4580 Resolutions for the week: Bugs marked FIXED : 42 Bugs marked REMIND : 0 Bugs marked INVALID : 9 Bugs marked DUPLICATE : 9 Bugs marked WONTFIX : 11 Bugs marked WORKSFORME : 8 Bugs marked LATER : 3 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component UsabilityInitiative 10 Site requests 7 LiquidThreads 6 Vector Skin 5 Page rendering 3 New Bugs Per Product MediaWiki 22 Wikimedia 10 MediaWiki extensions 29 Wikipedia Mobile 2 Top 5 Bug Resolvers conrad.irwin [AT] gmail.com 11 agarrett [AT] wikimedia.org 9 roan.kattouw [AT] gmail.com 6 sam [AT] reedyboy.net 5 hartman [AT] videolan.org 4

1 0

Broken validation statistics
by Gregory Maxwell 27 Jun '10

27 Jun '10

Is anyone working on fixing the broken output from http://en.wikipedia.org/wiki/Special:ValidationStatistics ? I brought this up on IRC a week-ish ago and there was some speculation as to the cause but it wasn't clear to me if anyone was working on fixing it.

2 3

JavaScript error with Vector tab manipulation
by Nihiltres 24 Jun '10

24 Jun '10

Roan Kattouw wrote, at 20:33:44 UTC on 2010-06-23: > I think calling $j.collapsibleTabs.handleResize(); yourself should do it. Unfortunately, that doesn't fix the problem at all; that function returns the same error, breaking the code into which it's inserted in the process, as then the error is local to that code (rather than occurring in the collapsibleTabs routine). :( I seem to recall having tried that at some point, but it's been awhile since I've delved into the collapsibleTabs code to look for a solution. I don't think I understand the problem enough to solve it myself. > Either way, this is a bug in CollapsibleTabs and should be fixed. Is there an existing bug, or should I file a new one? Thanks, Nihiltres

2 1

Is there some extension for update a wiki page by member's email reply?
by Evel liu 24 Jun '10

24 Jun '10

Dear all, Is there some extension for update a wiki page by member's email reply? Thanks! Evel.

1 0

LdapAuthentication 1.2c released
by Ryan Lane 24 Jun '10

24 Jun '10

This is a bugfix release related to the previous 1.2b release. The following has changed: * Fixed issue with single domains, and non-auto-authentication domains being non-operational due to security fix in 1.2b * Fixed another issue with mail me a password not working properly To download this version, please use the extension distributor (http://www.mediawiki.org/wiki/Special:ExtensionDistributor/LdapAuthenticati…), select “Development version (trunk)”, and click “Continue”. Respectfully, Ryan Lane

1 0

Project management and issue tracking; Bugzilla vs Redmine
by Rob Lanphier 24 Jun '10

24 Jun '10

Hi everyone, Sorry for the email length here. Here's my quick summary: * Trying to figure out how to do good project management on Bugzilla, working with the Bugzilla community to juice it up * Failing that, we'd like to migrate off of it. Leading candidate: Redmine * Wiki page: http://www.mediawiki.org/wiki/Tracker/PM_tool And now, the (much) longer version: As you probably recall, Priyanka has been investigating our use of Bugzilla, and investigating whether or not it makes sense to keep using it, or migrate to something else. I'm helping her out with that evaluation now, and here's where we're at. We really want to have well-integrated issue management (both feature requests and bugs) along with project management. We've informally narrowed the choices down to 1) staying with Bugzilla, or 2) migrating to Redmine. I say "informally" because it's not as though there's been any formal consensus gathering process of any sort, and we know we need to really need to involve everyone in this process. Staying on Bugzilla would obviously be the least disruptive choice, and we'd prefer to stay with the devil we know rather than find out what Redmine or some other tracker doesn't have after a migration. However, looking at Bugzilla, as currently configured, from the point of view of a project manager, it really doesn't work very well. It's very difficult to provide a birds-eye view of how a project is progressing without building a separate manually-maintained wiki page with a project plan on it. While it seems possible to *cope* as a project manager with Bugzilla, it doesn't seem like the kind of tool that a project manager could grow to love, at least not how it exists now. Redmine has time management built in, and is pretty clearly designed as a project management tool generally. By way of example, here's the roadmap for the Redmine project itself: http://www.redmine.org/projects/redmine/roadmap It seems to favor old-school time management (with Gantt charts having better support than Burndown charts), but it looks like a versatile enough tool to adapt to many different project management styles. Most importantly, it has sensible defaults that we can count on others also building upon. Now, as I've alluded to, the problem may just be with our configuration of Bugzilla, which is pretty narrowly focused on just tracking bugs. We reached out to the Bugzilla developers on IRC, and I'm planning to follow up on the Bugzilla newsgroup: http://groups.google.com/group/mozilla.support.bugzilla/ As with pretty much any mature piece of infrastructure software, it is possible to extend it. For example, Max Kanat-Alexander pointed out the new extension interface in the latest version of Bugzilla, and believes it would be reasonably simple now to create a roadmap plugin. That's not the only thing Bugzilla is lacking to be a really good project management tool, so we'll need a little more than "add roadmaps" to get us where we ultimately want to be, but having that functionality is a good start. In order for Bugzilla to be a viable option for project management, the Bugzilla team would need to demonstrate that they're serious about creating something competitive in this area. Redmine isn't the only competition that appears to do better; JIRA is also better in this regard. While we may be the ones asking most directly right now, I've gotta believe that many other Bugzilla users are either hitting the same wall we are, or know something that we don't. Here's what we're planning to do: 1. Engage the Bugzilla community much more seriously about project management. Engage the Firefox developers to find out how they're making it work for them, as well as other large projects (e.g. perhaps GNOME). 2. Simultaneously engage the Redmine community and generally evaluate Redmine. Make sure we understand a lot better the good and the bad with it. For example, it appears on the surface that the query abilities aren't as sophisticated. We'll need to understand if that's going to be a problem for us. 3. If it looks like Bugzilla is on a rapid enough trajectory to becoming a great project management tool (with or without our help), then we figure out how to make that process go as quickly as possible. 4. If it looks like Bugzilla is not going to get there without an all-too-heroic effort on our part, or it looks like one of the alternatives is SO compelling that we really should make a switch, then we'll be floating a migration plan with you all. Here's the web page that discusses this: http://www.mediawiki.org/wiki/Tracker/PM_tool On that page, we get into some more detail about the pros and cons of each of the tools. I realize that most of the readers on this list probably are not project management tool connoisseurs, and you're probably more interested in Bugzilla for its bug tracking ability. That said, there's probably a significant number of you that want to be more in-the-loop about what WMF staff developers are up to. Having access to the tool we use for scheduling/planning will give you more visibility. So, here's what I'm hoping you all can help out with: 1. Take a really good look at Redmine, and see if you'd love/hate/be indifferent to a migration to that tool 2. Help with the process of fleshing out requirements/nice-to-haves on the wiki page above. 3. Help engage both the Bugzilla and Redmine communities if you've got an interest in this topic. Does this all seem reasonable to everyone? Let us know what you think. Thanks! Rob

9 12

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l June 2010