Hello,
I'm asking this here per advice from Cary Bass.
I would like to request an enhancement in the checkuser-l mailing list,
which would allow searching the topics and/or contents of archived mails for
specific terms. This is particularly useful on this mailing list, because
CUs frequently need to check the archives to review previous information
about IPs and socks.
I'm aware that our mailing lists are running on Mailman 2.1.9 (which is NOT
the latest version [1]). Having checked their website I'm sure such search
functionality IS NOT available in mailman, nor through a plug-in. They
advise using third-party search engines (like Google), but since checkuser-l
is not a public list, Google is not an option. They also suggest using some
patches [2] which are compatible with Pipermail, but whether they are
suitable in our case is beyond my understanding.
I'm sure I'm not the only one asking for this feature. I'd be grateful if
the request was taken into consideration.
Regards,
[1] http://www.gnu.org/software/mailman/index.html
[2] http://wiki.list.org/display/DOC/How+do+I+make+the+archives+searchable
As some of you know I'm working on a new uploader for MediaWiki, called
UploadWizard.
I wrote some preliminary docs about the PHP side of the design here:
http://www.mediawiki.org/wiki/Extension:UploadWizard/docs
(more docs, especially about the frontend, will be forthcoming as I
write them).
In particular I'd like to draw people's attention to how it adds new
ways of accessing files in the temporary "stash". Previously we've used
the stash only as a holding area for files that need some sort of
last-minute touch-up, like a new name. This design makes the "stash" an
important part of the entire upload process.
There are security implications to some of these new features. Roan
Kattouw has been reviewing this already, but I wanted it to have a wider
distribution as well.
1) The uploading user can view thumbnails of their own "stashed" files
via a new Special: page. It should not be possible for any other users
to ever obtain anyone else's temporary files, or for them to subvert
this system to do other mischief. However, it does rely on reading the
file out to the user using PHP, thus *potentially* opening the door to
reading other files. I think I've been thorough in eliminating this
possibility, but I'd like extra eyes.
2) In a similar manner, the uploading user can request metadata about
uploaded files before they are published.
The code is in a branch over here:
http://svn.wikimedia.org/svnroot/mediawiki/branches/uploadwizard
You particularly want to check out:
http://svn.wikimedia.org/svnroot/mediawiki/branches/uploadwizard/includes/u…http://svn.wikimedia.org/svnroot/mediawiki/branches/uploadwizard/includes/s…http://svn.wikimedia.org/svnroot/mediawiki/branches/uploadwizard/extensions…http://svn.wikimedia.org/svnroot/mediawiki/branches/uploadwizard/extensions…
--
Neil Kandalgaonkar |) <neilk(a)wikimedia.org>
Hi all,
Pulling out a subconversation from the collaboration thread....
On Fri, Oct 15, 2010 at 1:56 PM, Aryeh Gregor
<Simetrical+wikilist(a)gmail.com> wrote:
> The number one thing that
> volunteers are unhappy about is non-deployment of volunteer code.
> Why? Because the only reason for their participation is so that their
> code should be deployed. When their code is neglected while other
> people's code is deployed immediately, solely because those other
> people happen to work for Wikimedia, that will result in a great deal
> of frustration no matter what attitude anyone approaches it with.
One thing that would be extremely helpful in getting WMF focus would
be to get things organized on mediawiki.org to help us gain a clear
view of what is the queue. There are three lists on mediawiki.org
right now:
http://www.mediawiki.org/wiki/Review_queuehttp://www.mediawiki.org/wiki/Requests_for_reviewhttp://www.mediawiki.org/wiki/Requests_for_comment
Additionally, there's an list of items in Bugzilla (in no particular order):
https://bugzilla.wikimedia.org/buglist.cgi?keywords=need-review&query_forma…
It would be wonderful to have a shared view of not just the long list
of things pending, but some shared way of seeing an ordering. Even if
there's disagreement about the "right" order of the list, just having
an order to argue about would be huge step forward.
Is mediawiki.org the right place to keep track of the queue? If so,
is anyone here willing to do some wiki gardening and merge those three
pages above?
Rob
Hi,
First of all, sorry if this is the wrong list, I can't remember if
sysadmin stuff should go here or not.
Anyway, all the customers of the french ISP SFR can't access Wikimedia
websites. It seems to be a DNS issue, when I switched to Google's it
worked well.
Has anything been done on this level on our side that could have
generate this issue ?
I doubt it comes from us but one never knows.
Thanks a lot for your help.
All the best,
--
Christophe
Hi!
You are hereby all officially invited!
http://wikifestbln.org/WikiFest+BLN+2010
So far are confirmed participants from the following wiki engines:
MediaWiki, Semantic MediaWiki, DokuWiki, Foswiki, Tiki Wiki
I hope we can have as many wiki projects (wiki engines and wiki sites)
present as possible.
We have an awesome venue, so please do come!
Best regards,
--
Marc Laporte
http://MarcLaporte.comhttp://TikiWiki.org/MarcLaporte
Hey,
I'd like to introduce everyone to an extension called Validator [0] that I
wrote over the past few months and aims to facilitate parameter handling for
other extensions. I developed it for usage in the Maps and Semantic Maps
extensions, as I thought it would be nice to have a less messy way of
creating parser hooks. It's now at a point where it can be used by other
extensions, without having to worry about compatibility to much. For a more
detailed explanation of what Validator does, check out the "functionality
overview" section [1] on the extension page.
I encourage all extension authors to have a look at it, especially if you
are considering creating a new extension where you have to deal with
user-provided parameters, to see if this can help you. Feedback is welcome
:)
[0] http://www.mediawiki.org/wiki/Extension:Validator
[1] http://www.mediawiki.org/wiki/Extension:Validator#Functionality_overview
Cheers
--
Jeroen De Dauw
* http://blog.bn2vs.com
* http://wiki.bn2vs.com
Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69
66 65!
--
So that Aryeh doesn't feel like a lone voice, as he did last time.
Are you really saying here that agreement constitutes an operational problem?
Roan has posited that volunteers complaining constitutes a problem. I
suggest that *why* they're complaining constitutes the problem.
- d.
On 15 October 2010 20:58, Erik Moeller <erik(a)wikimedia.org> wrote:
> I fail to see how your repeated emphasis of escalatory comments helps
> to return us to a constructive and healthy discussion tone on the tech
> list. As far as I can tell, you're contributing to making the tone
> more negative and less healthy. Can you explain what you're hoping to
> accomplish?
>
> Erik
> --
> Erik Möller
> Deputy Director, Wikimedia Foundation
>
> Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
>
Hello everybody!
I have worked all the summer on interwiki transclusion in branch
iwtransclusion. It is nearly finished now: only small improvements
have to be made before this is merged to trunk.
However, my university work makes me very busy at this time and I
think I will have no time to finish the project in the next months.
I'm wondering if someone could take care of this, why not during the
upcoming hack-a-ton?
All my work is described here: [1]
The last improvements needed are:
* finishing to build-in the GlobalUsage extension
* create and use 2 tables globalnamespaces and globalinterwiki
(documented in the given link)
Of course, if someone is volunteer, I can give them a hand sometimes.
Thanks in advance
[1] http://www.mediawiki.org/wiki/User:Peter17/Reasonably_efficient_interwiki_t…
--
Peter Potrowl
http://www.mediawiki.org/wiki/User:Peter17