Wikimedia Forum

Here's a possible new fundraising source that may be both practical and able to generate significant funds, submitted for consideration.

Aside from the annual fundraising drive which appeals to many Wikipedians, its possible to have a separate benefactor microdonation system linked to every article page. It would permit readers of Wikipedia articles to make payments to both the contributors of an article, and to Wikimedia itself.

I'd recommend involving an electronic payment company such as PayPal, Visa, Mastercard, Amex... (companies which I have no employment relationship with) to administer the actual processing of payments. We can believe that such companies can provide the electronic payment processing for Wikimedia on a pro bono or at cost basis, since it wouldn't likely involve a great deal of effort on their part because of the use of their existing infrastructure.

The Wikipedia encyclopedias have several stakeholders -let's reward the two principals. This would benefit both Wikimedia and the quality of its encyclopedic articles at the same time. The two most important stakeholders are, naturally, Wikimedia, which runs and enables the entire organization, and the editor/contributors who both create and upgrade its encyclopedic articles. A new system can benefit both stakeholders, and at the same time provide greater motivation for expansion of its articles, depth and quality, all without conflict to Wikipedia's traditional fundraising.

New microdonation system:

1) DONATION SYSTEM PROCESSOR: a donation processing agreement is coordinated with a company such as PayPal. The processor would receive the payments from readers, aggregate them and then bill them monthly to the readers that volunteer to make such payments. As per the procedure schedule and formula, the payments would be made to both the registered-contributors/editors and to Wikimedia itself.

2) ENROLMENT OF MICRODONATORS: the Wikipedia encyclopedia would offer readers, via a hyperlink, the opportunity to register themselves for microdonations, and then make such donations while reading its articles. Registration of benefactors would be handled by the processing organization, which would obtain valid credit card or bank account information from those wishing to donate. Doubtlessly, many readers have been impressed by the broad scope of articles available, and by the depth and quality of its many individual articles. Let's allow such readers the opportunity to provide a modest award to the article's contributors and to Wikimedia at the same time. The range of donations can be set with minimum/maximum limits: expressed in U.S. currency, perhaps 5 cents at the minimum, and perhaps 1ドル at the maximum, per article, that the reader wishes to award. For simplicity, such donations would be tax exempt: no formal donation paperwork would be issued regarding donations for income tax purposes.

If a reader found an article compelling and educationally satisfying to him/herself, the reader clicks on a micropayment button to make one-time donation payment, either for a default amount or for another amount within the min/max range. After confirmation, that payment data would be registered by the donation system processor. At the end of the month, the payment processor would aggregate the donation data and bill the benefactors' registered credit cards or other accounts. Ex: if a casual reader read 20 quality articles in a month, and then donated 10 cents for each one, that person would be billed exactly 2ドル.00 on his or her credit card or other account, paid to both the article's registered editors who wish to receive such payments, and to Wikimedia, as applicable.

3) ENROLMENT OF ARTICLE WRITERS AND EDITORS: contributor/editors would be permitted to register themselves if they wish to receive such payments.

• Payments could be make to valid PayPal, direct deposit bank accounts and possibly to credit card accounts.
• To reduce the operational costs, payments would only be made electronically, and would not be made unless the registered contributor/editors had such accounts, i.e.: no time-consuming or expensive payment methods would be utilized, such as mailed cheques.
• Registration of the editors/contributors would be entirely voluntary; they would receive such payments only if they personally take the time to register themselves.
• Any such payments would be classified as a contract service: no withholding taxes or other fees would be applied, and it would be up to the contributor/editors to register their own earnings if income taxes were applicable.
• If a minimal payment transaction fee were required by the payment organization or the bank or credit card company to handle the cost of the payment service, it would be deducted from the payment. If a registered contributor/editor were to receive a payment of 25ドル and a 15 cent service fee was required to cover the transaction, then he/she would receive a net payment of 24ドル.85. Wikimedia would obviously have the ability to veto the use of any payment service that proposed exorbitant rates for such payment transactions.

4) PAYMENT CALCULATIONS AND ASSIGNMENTS: Do not award contributors by the number of edits they make to an article that receives donations! Some contributor/editors (of the 'starving artist' category) might change their edit style to inflate the number of edits performed to create or upgrade articles.

a) Award the payments on the basis of the percentage of article's length that the editor has written which has not been reverted. If the hypothetical article 'The History of Pie' was written and upgraded by a total of three award-registered editors, and a combined total of seven unregistered/IP editors, and if editors A, B and C hypothetically wrote 20%, 15% and 10% respectively of that article, then at the end of the payment period Editor A would be awarded 20% of the aggregated payments collected, Editor B would receive 15%, Editor C would receive 10%, and the remaining 55% of the amounts collected would be awarded to Wikimedia itself.

b) The percentage each individual registered contributor/editor would receive would be calculated by the amount of editorial material he or she contributed, minus any materials reverted by others. If the case of 'The History of Pie', if Editor A had contributed 40% of the article, but 20% of his/her contributions had been reverted due to inaccuracies, then that person's net contribution to that article would be calculated at 40% - 20% = 20%, resulting in an award of 20% of the aggregated collections for that article.

5) NET BENEFITS:

• Readers who wish to reward article writers for the efforts would now have a vehicle to do so with;
• Article writers who have a need for some extra funding would be able to receive such payments;
• Article writers would also be encouraged to create more articles and expand existing ones: exchanging 'knowledge for change';
• Article writers would be encouraged to improve the quality of their articles, since the greater the quality, the greater the reward. Its exactly like busking: the more you impress and move your target audience, the more change they'll drop in your hat;
• Many writers will not wish to register themselves to receive such payments; those portions, as well as the portions performed by IP editors will default to Wikimedia. If the hypothetical The History of Pie article receives an aggregate total of 100ドル in donations in a one month period, and only 45ドル is awarded to the registered editors, Wikimedia would benefit by receiving the remaining 55ドル for that article;
• Finally, a certain percentage of unregistered IP editors may be encouraged to sign up for Wikipedia accounts! Hooray! More registered Wikipedians creates more Wikipedia involvement (hopefully of the positive type)—another plus!

For your consideration; feel free to contact me if I can be of help in refining the suggestion. Best regards: HarryZilber

Last year ITI khamariya Seepat Bilaspur Chhatisgarh upgraded by World Bank project and Chhatisgarh Govt. for training in COPA trade.

I had removed the question I posted previously because it is not well-suited for this forum. If you are interested in the title of this message, please visit my user talk page, Question) How to choose featured article(s) from different languages . — Preceding unsigned comment added by Cooldenny (talk • contribs) 23:53, 17 March 2011

I'm not sure if this is an appropriate place to post this, but I figured it would be worth a shot. By all means, delete this if it doesn't belong here.

I'm currently working on a project about participatory culture and media that is driven by user-generated content...like Wikimedia's several services and resources.

I'm looking for people who actively contribute to participatory culture to answer a 5-minute survey: http://www.surveymonkey.com/s/XSXG5B8

All help is greatly appreciated.

()

I have a question. At the Dutch wikipedia we try to find a solution for the "wrong link problem" which turns out when using the 'primary topic' disambiguation system. The 'What links here' tool can not be used in such cases since there are hundreds of links.

A known 'solution' is to work with a detour. Instead of linking directly to the page one can link to a redirect page. E.g.: a link to [[Amsterdam]] would be a link to [[Amsterdam (primary)|Amsterdam]]. In this way the 'What links here' tool can be used after all (because, ideally, no pages should link to 'Amsterdam' itself, they all link to 'Amsterdam (primary)').

However, by doing so, a rather ugly redirect notice is shown .

We find some of a solution for that problem. Namely this script:

addOnloadHook(fix_hoofdbetekenis);
//fix _(hoofdbetekenis) links
functionfix_hoofdbetekenis()
{
if(typeof(disable_fix_hoofdbetekenis)!="undefined")
return;
varels=document.getElementsByTagName('a');
for(variinels)
{
if(els[i].className=="mw-redirect")
{
varoldhref=els[i].href;
els[i].href=els[i].href.replace('_%28hoofdbetekenis%29','');// remove '_(hoofdbetekenis)' from URL
els[i].href=els[i].href.replace('_(hoofdbetekenis)','');// remove '_(hoofdbetekenis)' from URL
if(oldhref!=els[i].href)
{
els[i].title=els[i].title.replace(' (hoofdbetekenis)','');// remove ' (hoofdbetekenis)' from tooltip
els[i].title=els[i].title.replace('_(hoofdbetekenis)','');// remove ' (hoofdbetekenis)' from tooltip
els[i].className='';// unset redirect class
}
}
}
}

This script made it possible that this code: [[Amsterdam (hoofdbetekenis)|Amsterdam]] is internally transformed into a simple link to Amsterdam without that pages are included in the 'Whatlinkshere list'.

The only problem is that the script seems to be a bit to slow. When the link is already visited it took a second or so when the link turns out purple (this is because the redirect page is not really visited).

So my question is: do you know another way to make this work, eg a way to disable the "Redirected from..." message in some cases (by a code or so).

Greetings, Zuydkamp from the Dutch wikipedia.

Hi all

Can you advise me if it is possible to change the design/layout of the revision history page?

thanks

Hey guys I would like to know too!

I wrote up a set of suggestions about how to address global blocks and bans, and how to deal with chronically problematic editors who also do great work:

Global blocks and bans

1) [Technical] Implement cross-project messaging, status flags, and contribution-history review.

2) [Technical] Implement tools for blocking, and for granting flags, across multiple projects.

3) [Policy] Define a Dispute Resolution Committee to evaluate global ban requests and guide related Meta policy

Dealing with chronically problematic editors

4) [Technical] Create permanent options other than banning.

5) [Technical] Create activity reports that can be shared across projects

6) [Tech and Policy] Offer more nuanced ways to profile new users.

7) [Tech and Policy] Define ways to share checks on problematic users, including private data, across projects.

8) [Policy] Define the negative impact of toxic contribution.

9) [Policy] Define when 'clean starts' are appropriate, and how they should be carried out.

Details at Talk:Global blocks and locks#Global blocks and bans; comments and suggestions welcome. –SJ talk | translate  

I saw navbox that I want to translate to hebrew. The problem is that I can't align it to the right.

This is the navbox:

{{Navbox
|style=wide
|name=Products
|title=Products
|group1 = Resources
|list1 =[[Chemicals]]{{·}} [[Coal]]{{·}} [[Cotton]]{{·}} [[Grain]]{{·}} [[Iron]]{{·}} [[Oil]]{{·}} [[Wood]]
|group2=Consumer Goods
|list2=[[Ammunition]]{{·}} [[Armour]]{{·}} [[Beer]]{{·}} [[Book]]{{·}} [[Food]]{{·}} [[Fuel]]{{·}} [[House]]{{·}} [[Medicine]]{{·}} [[Transport]]{{·}} [[Vehicle]]{{·}} [[Weapon]]
|group3=Intermediate Goods
|list3=[[Paper]]{{·}} [[Power]]{{·}} [[Steel]]
}}

Please tell what to add to the navbox in order to align it to the right. Thanks!

'Tellicherry [ Thalasserry ] Heritage Quadrangle The Anglican Church [St. John’s] on the western side of the Tellicherry Fort standing on a small Cliff above the beach always fascinated me. When I was a child it was a "mysterious" place with over hanging creepers over the many tombs of the Britishers who lived and loved Tellicherry .and the Church desolate and standing forlorn with its gates locked up always.

Hon. Minister for Tourism, Government of Kerala Shri .Kodeyeri Balakrishnan took lot of interest and revived and revitalized the whole area. The Church and the surrounding place has acquired refreshing freshness and takes one back to the pristine days of the glorious period. Please see some snaps attached.Thanks and congratulations to Shri Kodeyeri.You can also meet Mr.Ajay kumar very enthusiastic Tour guide in the church premises,

I am yet to know of any ship wreck impacting the shores of the place it happened with such a powerful positive effects. Master Attendant Edward Brenan Esq. reached ashore the small town of Tellicherry .From that day onwards he loved this beautiful place with cliffs reaching up to the coast , populated by a friendly people. He then joined the East India Company and stayed on till he died here in this place. He funded and established a "FREE SCHOOL" to give children of all caste, creeds and colour a sound English Education". This institution later on became the Brenan High School and in 1890 was made the Government Brenan College. During the last century countless boys and girls passed out of this pioneering institution and occupied all walks of life, some great, and some normal. On the northern side of the fort he built a house for himself .After his death on the 17th Of August 1859, this was taken over by the East India Company for its Resident and when the British rule came , it became the "Sub - collectors Bungalow. Locally it was known as " Thukkidi’s Bungalow". Quote Mr.Ramachandran.C.K."The word thukkidi is supposed to have come from the Urdu word 'tukdi' which is the name for a section of the army. It harks back to Tipu's conquest of Malabar when he had established tukdis at various places like Cherplassery and Tellicherry. The administrative system was adopted by the British who continued with the practice of having a Malabar Collector stationed at Calicut and two tukdis (sub collectors) at Cherpalcherry and Tellicherry."

Edward Brenan before his death had donated funds for building a church close by to his Bungalow. To this fund, many had contributed and on 1869 Lord Napier established this St. John’s Anglican Church and Edward Brenan Esq.’s body was laid to rest here in the grave yard. Many people who has earned a place in the history of Tellicherry are also laid to rest here in this grave yard..Some are – Mr. MurdockBrown who established the well known extensive cardom estate in Ancharkandy. He is also credited to have introduced the cake in Malabar through Sri. Mambally Bappu who had established his ‘Mambally’s Royal Biscut Factory "in 1880 in Tellicherry. Some of Murdock’s family members are also buried here. Thomas Henry Baber Esq. who shot and killed Pazhassi Raja , after his term of duty as the Sub. Collector was over returned to England. After some time he came back to Tellicherry the place he cherished and died here.

We cannot ignore the start of all the causes of history which brought the English traders here to Tellicherry. The proximity to the land –Kottyam Territory comprising of present Muzhappilangad, Edakkad, Iruveri, Mavilayei, Chembilode, Ancharakandy, and the Periya area in Wayanad on which the first rated Pepper and Cardom grew in plenty. The French had established a trading post in Tellicherry and when it became a losing venture they abandoned it. The trouble created by the Britishers hastened there departure. In 1682 the French abandoned the post fully. Two British officers Mr. Chaise and Mr. Mitch Lou in the British trading post in Dharmadom approached Kolathri Prince and obtained permission to take over the abandoned French trading post. The first and most important trading post [1863 ] of The British was in Tellicherry. To safe guard the trade and the personnel the East India Company obtained permission from the local ruler, Vadakkan KoorThamburan to built a fort in Tellicherry. The cliff designated for the fort was known as Thiru Vel Appan Kunnu- [ Murugan son of Lord Shiva –always makes his abode in elevated place - the hillock ] and comprised of Punnol Poduval’s house ,Chaliyar [ Weavers] Street on the side of the hillock. Vadakkan KoorThamburan laid the foundations of the fort, which was completed in 20th August 1708..In the subsequent wars with Hyder Ali [Mysore wars] Tellicherry was the base of operation for the ascent of Wayanad Ghats.. Arthur [later Sir] Wellesley formulated his battle plans in this fort. The St.Joseph’s Boys high School and the Catholic Holy Rosary Church are adjacent. Kindly note that this write up is not the result of any extensive research but the result of casual reading. There is bound to be some corrections, All corrections are welcome

Premnath.T.M

Hi there, Two suggestions for improvement of wikimedia projects especially wikipedia:

1. Periodically build a standalone & offline version of the Encyclopedia along with a good installer and software suite, then advertise about it in the web site. I promise a lot of people and organizations will purchase it or even register for long time subscriptions. This can be a good resource for the foundation.

Yes, people are doing that, but informally. See Wikipedia 1.0 and related projects. –SJ talk | translate  

2. Put a link such as "Give us your suggestions" in the foundation web sites. For sure, a lot of wiki-readers have brilliant ideas for the foundation projects.

Good idea! Where on the page? –SJ talk | translate  

Cheers,

Majid Tajamolian

Hello! I've made several edits to a new proposal on the metawiki.

The idea was originally proposed by somebody else, as a means to take up the wiki community to do something productive towards the cause of governance.

http://meta.wikimedia.org/wiki/Talk:Civipedia#A_possible_scenario_and_the_question_of_expertise

Present Chinese Wikis:

• zh 中文,
• zh-classical 文言;
• zh-min-nan Bân-lâm-gú
• zh-yue 粵語

are registered with LANGUAGE codes in Wikipedia.

But what we find on zh, zh-classical and zh-yue are scripts (i.e. hani, hant and hans)!!

On the other hand *zh-min-nan Bân-lâm-gú is Min-nan-language phonetically transcribed/romanized.

What Wikimedia should do, is to combine Chinese script AND the languages which use Chinese script in sort of Interlineary version which gives the users the script (hani, hant, hans) AND the language in question. One could program the pages with the option to show

a) both script and transcription

b) only the script

c) only the transcription

Chinese Script based Wikis (and also Chinese Wikis like Min-nan which use only transliteration and omit Chinese script) are only of use (for mankind) if there is the option to habe both information (Chinese Script AND its pronunciation/transcription). Please see an example of my idea (constructed with template:hidden) [here]--Dudy001 08:23, 1 October 2011 (UTC) Reply

The respective Wikis should have as prefix then for example: (see Chinese written language and List of varieties of Chinese

• hani-zh
• hant-zh
• hans-zh

• hani-zh-yue
• hant-zh-yue
• hans-zh-yue

etc.--Dudy001 08:53, 1 October 2011 (UTC) Reply

Perhaps also - and Wikimedia could do this easily (with all its servers and computers) - with different transcription systems (i.e. the most common one's for a start: Pinyin (PY),

that means for the prefixes (see: transcription systems for Chinese languages

• hani-zh(PY)
• hant-zh(PY)
• hans-zh(PY)

• hani-zh-yue(PY)
• hant-zh-yue(PY)
• hans-zh-yue(PY)

etc. or

• hani-zh(Wade-Giles)
• hant-zh(Wade-Giles)
• hans-zh(Wade-Giles)

• hani-zh-yue(Wade-Giles)
• hant-zh-yue(Wade-Giles)
• hans-zh-yue(Wade-Giles)

etc. with hide/show option.--Dudy001 09:10, 1 October 2011 (UTC) Reply

Classical Chinese is completely diffferent from modern Chinese. In no way we can merge that with zh.wikipedia. On zh.wikipedia we already have automatic conversion between simplified and traditional Chinese, which by the way is your 'hans' and 'hant'. --Bencmq 09:17, 1 October 2011 (UTC) Reply

My proposal is not to merge Chinese scripts, languages and transliteration system. On the contrary what I want to say is, that one has to differenciate between:

1. Script (hani, hant, hans
2. language (zh, zh-yue, etc.)
3. pronunciation (Transcription systems)

and that all these (three) informations MUST be given in a Chinese Wiki to qualify as an encyclopedia for all (not only for intellectual Chinese (maybe 10% of the Chinese), who know to read and write (and pronounce) Chinese already. For all the other Chinese and learners of Chinese Chinese Wikis are - at the moment - of not much use. If this is not changed, the outreach programs will not have much effect. It's just like making an "Ancient Egyptian Wiki with only the hieroglyphs without giving their pronunciation in their respective different Old Egyptian languages/dialects!--Dudy001 07:20, 4 October 2011 (UTC) Reply

Each of them already have their own rules regarding those aspects

Mandarin allows for multiple scripts, Cantonese and Wu chose traditional, Min-Nan uses roman characters

Since they are written the reader will pronounce them as the reader would

"It's just like making an "Ancient Egyptian Wiki with only the hieroglyphs without giving their pronunciation in their respective different Old Egyptian languages/dialects" - A reader who is fluent in the language will know how to pronounce it

WhisperToMe 03:01, 21 October 2011 (UTC) Reply

This discussion has been moved to a subpage: see /Italian Wikipedia. —The preceding unsigned comment was added by Angr (talk • contribs) 06:41, 6 October 2011 (UTC)

Hello

Can I customize Wikimedia to make it look and work like www.wikihow.com ??

And is it easy to do it?

Thanks

Meta:Copyrights and GNU Free Documentation License refer to version 1.2, which I think is not legally possible. ;-) Discussion at Meta talk:Copyrights#Page outdated. John Vandenberg 02:11, 20 October 2011 (UTC) Reply

Hi, I would like to know your opinion on this: toolserver.org is server cluster operated by wikimedia (削除) foundation (削除ここまで) de, many of wikipedia tools are being hosted there, but if you look at many wikis which use it, you can see that many of them link to the tools like

http://toolserver.org/~user/tool

It probably looks very strange to the people who use wikipedia that wikipedia links it own tools somewhere outside from wikipedia (since ordinary users probably don't know much about the servers wikimedia and tools run on), actually I think it would be much better if there was a dns record in wikimedia.org dns like toolserver.wikimedia.org which was set to same ip's as toolserver.org is, so that the links would stay in wikimedia dns space. I know it's rather minor change but it would appear much better. It shouldn't be that complicated too. Any thoughs? Petrb 15:05, 21 October 2011 (UTC) Reply

There are security implications that I believe (although you should check) preclude this; it might even have been discussed in the past. Essentially, the toolserver is (by definition) running code that has not been vetted by the WMF sysadmins. If the toolserver gets a *.wikimedia.org DNS address, malicious (or malformed or insecure) code running from it can do nasty things like install tracking cookies that are run on all *.wikimedia.org domains, or steal global CentralAuth cookies, etc. Compromised toolserver code could also be used as a way to bypass the same-origin policy. These are much the same reasons why sites like Facebook and Google serve insecure content from different domains to their main site (http://googleusercontent.com and http://fbcdn.net, respectively). In short, I think this is technically unworkable, although it's worth checking with the sysadmins. Happy‐melon 15:45, 21 October 2011 (UTC) Reply

mw:Global session threat assessment. We were moved from shortly before SUL's introduction. At one point tools.wikimedia.org was an alias for tools.wikimedia.de, but I'm told this wasn't official sanctioned. Dispenser 16:18, 21 October 2011 (UTC) Reply

But what about having a redirect from tools.wikimedia.org/* to toolserver.org/* (a simple script located at tools.wikimedia.org which would redirect you), that would not be that better but it wouldn't have such issues, true is that I couldn't find it anywhere although I was thinking that it probably was discussed in past, just wasn't sure why it already isn't. Petrb 16:31, 21 October 2011 (UTC) Reply

In an older versions of Flash the cross-domain security check was done before resolving redirects. Its likely other venders also made the same mistake. So why increase the attack area? Additionally, WMF is spending 1ドル.5 million on Labs to overthrow the independently operated Toolserver. Dispenser 02:53, 22 October 2011 (UTC) Reply

Actually, a mistake like that in the JAVA runtimes was patched just 2 weeks ago, so yes there are other vendors with such trouble :D TheDJ 09:13, 22 October 2011 (UTC) Reply

Wmf is spending those money how? By emloying "trustworth" coders as replacement for semi-trusted community devs? That would be like throwing money out of window... There are people willing to do this for free so what for? Petrb 10:03, 22 October 2011 (UTC) Reply

No, they're building a virtual server stack that duplicates the entire cluster, but which is separated from the production servers so they can give semi-trusted community devs the ability to tinker with (and yes, potentially screw over) the whole architecture. Why use the toolserver's replicated database when you can write a MediaWiki extension and install it yourself on something that looks exactly like the production wikis? It's very exciting, but it probably won't completely replace the Toolserver, which is still a useful platform for hosting bots. But basically anything that usese the toolserver mainly for its replicated databases will be jumping ship to Labs eventually. Happy‐melon 11:03, 22 October 2011 (UTC) Reply

Hi. :) I found myself in position of having to use this system after User:Geoffbrigham asked that we broadcast word of the Terms of Use and Tilman Bayer (in his contractor position) sent me there. Fortunately, Tilman was available to talk me through part of the process, before he became unavailable midway through, because I found it very intimidating. It's a great system to get out important information, but I'm concerned that there may be people who would have good reason to use it (like Geoff or, well, me) who probably shouldn't monkey with it. For example, when I was trying to run a "test" email to a single account, as Tilman advised, using the same delivery access list as I was going to use per his recommendation, the bot did not immediately work. Being on a time crunch, I set the status to "Really start" as per the directions (he was away from IRC at that point), and he told me when he returned that I might have inadvertently caused the Bot to send my test message out to everyone in earlier versions of the "access list." This seems kind of high risk. :/ (For that matter, if I had not been actively chatting with Tilman in the beginning, I wouldn't have known to test the system at all.)

I'm wondering if it's possible to set up some kind of request system where staff and/or others who have good reason to spam messages can ask those of you who know what you're doing to help out with the hands on portion--maybe a "requests" page? While I hate having to impose on people, I think it might be best for the bot and the spammees. :) This really doesn't seem like something we want to get wrong. --Mdennis (WMF) 12:41, 22 October 2011 (UTC) Reply

About the "Really start" problem: As MZMcBride explained it to me, the risk is that the bot might be using an outdated recipients list when it is set to ignore Toolserver lag. This is not a big problem for e.g. the Signpost (where one will probably only miss one or two recent subscribers), which is why the Signpost publication instructions recommend overriding the Toolserver lag error with the "Really start" command. However, if one has recently made big changes to the recipients list, as in this case, the override should probably be avoided. The instructions at Global message delivery/Spam need to make that clearer.

I think it's a good idea to ask an experienced user to operate the bot (and not rushing it when doing it for the first time). I would have been happy to do it myself in this case if I had been notified in advance.

Your proposal makes sense. At the moment it doesn't seem that there would be too many requests, so I suggest simply using Talk:Global message delivery - I have put a note to that effect into Global message delivery. It has to be kept in mind that most users will probably not come with an already well-formed request, but will need help as well to write up and format the message, and to assemble a recipient list.

Regards, Tbayer (WMF) 16:05, 24 October 2011 (UTC) Reply

Thanks for updating the instructions. I'll pass that along. :) And I'll keep in mind next time a staff member comes to me for help that you may be available to assist. --Mdennis (WMF) 16:39, 24 October 2011 (UTC) Reply

The bot doesn't run instantly. It checks the "/Status" page every five minutes. So there will generally be a delay between when you tell the bot to start and when it will actually start. The instructions are fairly straightforward (to me, at least) and operating the bot generally only requires editing two pages ("/Spam" and "/Status"). If there are ways to make it friendlier, go for it. :-) Do be cautious of instruction creep, though.

On a personal level, I wrote the bot so that I wouldn't have to manually interfere with message deliveries. I have no intention of fulfilling outside requests to run the bot, as it runs directly contrary to the architecture I built. But others are likely much more accommodating. --MZMcBride 23:25, 24 October 2011 (UTC) Reply

Meta sysops are the first obvious users of the system, so I think that you can just put requests on WM:RFH. Nemo 20:06, 28 October 2011 (UTC) Reply

regards, -jkb- 10:10, 23 October 2011 (UTC) Reply

How avant-garde. --MZMcBride 23:41, 25 October 2011 (UTC) Reply

Sure. Thanks for the nice comparison. -jkb- 09:27, 27 October 2011 (UTC) Reply

This request for comment, created by Millosh more than two months ago, still need some opinions. It would be nice if people that did not give their opinion could express themselves. Thanks -- Quentinv57 ^(talk) 17:55, 25 October 2011 (UTC) Reply

Urgent! The government is trying to pass a blacklist bill that would shut down social networking and other user-generated content sites, like Wikipedia. To sign against it, go here: http://act.demandprogress.org/sign/pipa_house/?source=fb —The preceding unsigned comment was added by 68.225.53.160 (talk • contribs) 08:20, 26 October 2011‎ (UTC)

I suggest you inform yourself about the bill, before you buy the claim it could affect Wikipedia. Seb az86556 08:37, 26 October 2011 (UTC) Reply

I haven't seen any reference to the Foundation's May 2011 controversial content resolution at Wikipedia until recently, when it was invoked at Pregnancy and Muhammad. I've started a discussion at the enW Image use policy talk page to explore whether the resolution has implications for image use at enW. --Anthonyhcole 09:28, 31 October 2011 (UTC) Reply

Awhile ago, I created a toolserver tool which allows you to search through a user's contributions to a particular page, or through a range of pages (using wildcards). Until recently, this tool was only available on the English Wikipedia. I have now made a version available which works across all wikis. It is currently in testing on not live on my toolserver site yet. However, if you frequently use non-English Wikipedias, feel free to try it out and let me know if you find anything that doesn't work the way you expected it to. You can report bugs at en:User talk:Snottywong. Thanks! —SW— ^comment 23:59, 31 October 2011 (UTC) Reply

Why can't people who use the Public Library because they don't have their own computers get blocked from editing. I live in Tampa, Florida and I can't edit. The whole site is blocked forever.

71.41.38.234 15:21, 3 November 2011 (UTC) Reply

not for "forever," 6 months.

You can still create an account on a different computer and then log on from wherever you are. Seb az86556 16:37, 3 November 2011 (UTC) Reply

This is a proposal of Wikimedia Incubator admins (at least me, User:Danny B. and User:MF-Warburg) for a global user group "new wiki importer". This is needed 1) so that we don't have to ask for permissions each time a new wiki is created, and 2) to guarantee the work is done by experienced importers (in the last few new wikis, there were problems twice).

• Rights: import, importupload, editinterface, delete, undelete, move, autoconfirmed, editprotected, protect, noratelimit, skipcaptcha
• Wiki set (three possibilities):
  • opt-out using the global sysop wiki set
  • a separate wiki set, e.g. opt-out all existing wikis
  • opt-in and new wiki importers get the "globalgrouppermissions" right to add a new wiki to the set temporarily

What do you think? Regards, SPQRobin (talk) 22:36, 3 November 2011 (UTC) Reply

Either option 2 or 3. Seb az86556 03:04, 4 November 2011 (UTC) Reply

Not all Wikis have the same importing feature. You would have to create a universal standard, which will probably be difficult. Ottava Rima (talk) 03:44, 4 November 2011 (UTC) Reply

How do you mean? We import by file upload, which is the same everywhere. SPQRobin (talk) 07:59, 4 November 2011 (UTC) Reply

Nope. Each Wiki has only a small amount of things it can import from. I was able to use import on multiple Wikis and I confirmed this a long time ago with others. Each Wiki's import set is different. Ottava Rima (talk) 14:35, 4 November 2011 (UTC) Reply

No. There are two different ways to import, see Help:Import: directly from other wikis, which have to be set it the wikis settings (this is the import permission, which all sysops have), and importupload through an XML file created by special:export (this right only the importer group has). --MF-W 14:40, 4 November 2011 (UTC) Reply

The XML files are not easy to use, nor are they able to move files as you claim. en.wiki, for instance, cannot easily take XML files from a wiki it does not allow importing from. There is a limited set any importer can take from, and that is an indisputable fact that most people involved in importing realize. Ottava Rima (talk) 19:17, 4 November 2011 (UTC) Reply

• I oppose, since this may cause confusion. And I think it should come with the import usergroup on incubator. ~~EBE123~~ ^talk _Contribs 10:44, 4 November 2011 (UTC) Reply

  How could this cause confusion? The group will be limited to importing content into new wikis, as its proposed name says. How do you mean your 2nd sentence? Most people who regularly import to new wikis are Incubator importers/sysops. --MF-W 11:08, 4 November 2011 (UTC) Reply

  Re-imports are annoying and this will happen more often. I think that this should be gave with the import group on incubator. Or put it in GS since this is just adding import, and importupload. ~~EBE123~~ ^talk _Contribs 19:30, 4 November 2011 (UTC) Reply

• Question. What problems? Could you be more specific? Ruslik 12:27, 4 November 2011 (UTC) Reply

  nsowiki was imported using the wrong character encoding. So now all non acsii character are broken. Now this wiki is locked and must be reimported, but first roots must clear the database. Merlissimo 12:39, 4 November 2011 (UTC) Reply

  I learned, and this is just to say to not use TextRangler and Microsoft Office. Use Dashcode and TextEdit even though Dashcode crashes often. ~~EBE123~~ ^talk _Contribs 19:30, 4 November 2011 (UTC) Reply

• +1 option 2 perferred, so new wikis can decide themself when then want opt-out. At them moment stewards grand importers one month tempadminship. Often this is not enought, so the inital importers start a local vote for permadminship, althought most wiki need there help only for about half an year. Merlissimo 12:39, 4 November 2011 (UTC) Reply
• A good idea to both simplify and clarify the current (non-)process. Options 1 and 2 for the wikiset seem overkill to me: this not worth maintaining a wikiset or defining criteria or processes for opt-out, and if they still have to ask stewards to edit the wikiset every time then there's is no simplification. Hence I support option 3; we just have to specify that only new wikis can be added and that they have to be removed when the job is done and not more than 6 months (or whatever) later. Other things the policy should contain for the stated purposes (obvious but worth mentioning): the right is permanent (inactivity removal to be left to common sense), no more temporary importers will be added for new wikis. Nemo 18:05, 4 November 2011 (UTC) Reply

  If I see it correctly, option 2 will require one action by a steward to opt-out all current wikis, and then a steward action each time when a new wiki was created and the "job was done" to opt it out; option 3 will require a steward action after the creation of a new wiki to opt it in, and afterwards to opt it out. --MF-W 18:15, 4 November 2011 (UTC) Reply

• Would not it be simpler to add 'importuload' userright to global sysops? Ruslik 18:59, 4 November 2011 (UTC) Reply

No, because each new Wiki would need to determine its import set. It isn't as simple as some people have claimed. Ottava Rima (talk) 19:18, 4 November 2011 (UTC) Reply

@Ruslik: The importupload right should be used with care. So only people having expierence with importing and are very trustful should get this right. You can do many very, very bad thing having this right. Thats the reason why local admins do not have this right and local importupload can only given by stewards.

@Ottava Rima: the import set (defined by $wgImportSources) is only important for the import right. Here we are mainly talking about importupload. Having this right you can import everything you like. On dewiki i could import contribs of yours that you have never done anywhere (and i am having this right only because i'll never do that). Merlissimo 19:38, 4 November 2011 (UTC) Reply

I am not proposing to give it to local sysops, only to global sysops. In fact, all stewards already have it. "local importupload can only given by stewards"—this is not completely true as on some wikis the 'importuload' userright is a part of sysop package and on some wikis users can be assigned to the importer group by bureaucrats. Ruslik 19:48, 4 November 2011 (UTC) Reply

Okay, so if "import" and "importupload" are two different rights, then why would the proposed importer need both? Anyway, my comments were mostly about the import right (not importuload). Other people have mentioned problems with importuload. Ottava Rima (talk) 19:51, 4 November 2011 (UTC) Reply

Because the functionality of the "import" right is much easier and can't do as much "harm" as "importupload". And I don't see any reason not to add "import" as a right. SPQRobin (talk) 20:30, 4 November 2011 (UTC) Reply

You only need one or the other. The import right, as I pointed out, is limited and determined by the system. The other is long, tedious, and has lots of problems. Ottava Rima (talk) 21:10, 4 November 2011 (UTC) Reply

• +1 - an import-upload-group could be more efficient and quicker for new projects; if there will be a opt-in so the new wikis should be informed in time about it (the best: before creating the wiki), -jkb- 20:44, 4 November 2011 (UTC) - - - and yes: experienced users only should get the right, it si not for everybody -jkb- 20:45, 4 November 2011 (UTC) Reply

• Oppose - ill conceived, both import and importupload have flaws that this group would not be able to overcome. New wikis don't have the ability to have a strong consensus to determine where all they can import from and xml files can be dangerous, take too much effort, etc., to be worth while. This is a solution to a problem that doesn't exist. Ottava Rima (talk) 21:10, 4 November 2011 (UTC) Reply

do you really know what are you talking about? Regards -jkb- 21:19, 4 November 2011 (UTC) Reply

Probably far more than you do. I've used the Import feature on multiple Wikis dating back a few years. I'm not the only one who thinks that the proposal is extremely problematic and there is quite a bit of false claims from those who want the additional features. Ottava Rima (talk) 22:02, 4 November 2011 (UTC) Reply

These aren't additional features, they already exist and are being used. This proposal is just to save stewards some work in granting and revoking the rights, in order to simplify the creation of a 'new wiki'. --MF-W 22:11, 4 November 2011 (UTC) Reply

I said additional features, not new features. Please do not make up claims about other people's statements especially when you are trying to argue for something that seems utterly unnecessary and potentially very dangerous. Ottava Rima (talk) 01:50, 5 November 2011 (UTC) Reply

Excuse me, I did not mean to "make up" anything about what you said or not said. By saying "these aren't additional features" I wanted to express that the import/importupload rights are not some features that some users, power-greedy as they are, want to be added to them, but that these users (read: people who regularly import new wikis) in fact receive these rights already each time a new wiki is created. --MF-W 17:48, 5 November 2011 (UTC) Reply

Your own proposal says "new wiki importer" in the top, so it contradicts exactly what you are claiming here. You blatantly asked for a new user group. Why you are playing word games is beyond me, but it shows that you don't have a legitimate request. Furthermore, it has already been demonstrated that XML not only takes a long time for importing but that it is dangerous. You would have to have known that going into the request, so that alone shows that this request was really, really faulty. You need to withdraw this request and stop it. Maybe if you came to a discussion first, actually asked for something reasonable, and not played games which makes you appear really untrustworthy, then you could get help. But not only has it been proven that you don't need it, but that your actual request is almost scary. Ottava Rima (talk) 18:42, 5 November 2011 (UTC) Reply

Of course we do propose a new global group. I never said anything to the contrary. And what has been demonstrated here about XML imports, is your inability to understand what it really is as you are the only one here claiming it would be not working (that it can be misused is true, though, as also others said here). --MF-W 19:20, 5 November 2011 (UTC)/changed 20:06, 5 November 2011 (UTC)Reply

Multiple people above have pointed out problems with the XML importing. Your claims that they didn't are highly inappropriate and incivil. You need to stop. Ottava Rima (talk) 23:56, 5 November 2011 (UTC) Reply

And as a side note, your user page denotes that you have adopted a radical and dangerous anti-WMF political ideology, so even giving you anything close to the above privileges would be extremely risky. I think it would make more sense to give Greg Kohs full access to toolserver than the "White Bag Movement" the ability to import at wiki and upload XML files to potentially hundreds of Wikis without any oversight. Ottava Rima (talk) 18:46, 5 November 2011 (UTC) Reply

Ottava Rima, in the last one or two weeks you diffamed some users, mostly from the German WP, once even as a whole community ("...manipulated a lot of users...", "...There is a reason why all of the porn is coming from a handful of white males...", "...In Germany, there is a dying culture of nudism/exhibition...", "...against the pornographic content and are at odds with the German community...", "...The arguments on de.wiki ... were ... an attack and manipulated a lot of users....", "...It isn't a coincidence that only de.wiki protested ... I would estimate that the trouble makers amount to less than 300 people ..." and so on, all to be found on the page User talk:Sue Gardner). Now you try to continue here: "...your user page denotes that you have adopted a radical and dangerous anti-WMF political ideology...", "...discussion first, actually asked for something reasonable, and not played games which makes you appear really untrustworthy...", "...your actual request is almost scary..."... Don't you think you should stop it immediately? If you have some problems, so discuss it with your friends. But do not discredite very experienced users and even a whole community. Thanks. -jkb- 20:45, 5 November 2011 (UTC) Reply

Already proved you wrong and shown that your comments amount to nothing. See below for a 100% critique on why there is no legitimate reason to go through with this. Nothing else matters. Ottava Rima (talk) 23:56, 5 November 2011 (UTC) Reply

I guess you are still talking about transwiki or transwiki import; but this is on import upload, something else. I really do not believe you practitized import upload in the past and then on some more wikis (!) as the importers are very rare exceptions on the whole wp project. You most probably practized transwiki import. -jkb- 23:48, 4 November 2011 (UTC) Reply

Import upload is long, tedious, and you are not going to transfer over 100s of pages to a new wiki. Only a transwiki would make sense. However, transwikis need a set that would have to be community determined. Thus, neither possibility is practical nor acceptable. Others have already shown why. And trust me, you can look in my global contribs and see that I have many contribs on Wikis I've never actually edited on because I was involved in testing various things, which also meant I was involved in the importing of those pages. That is in addition to where I was involved with importing on two different projects. I also have incubator experience - beta.wikiversity - which was quite successful without any of the problems that could be from having people with a global import right and without any local say or the rest and with the possible problems associated as listed before. Ottava Rima (talk) 01:50, 5 November 2011 (UTC) Reply

It is indisputable that to upload via an XML file is not efficient, takes a lot of effort, and would not be done by anyone who wishes to move files from the incubator to a new wiki. The only logical approach would be to use the importer transwiki rights to quickly move over files. This does not need a new group. There are no arguments that can be made. There have been multiple people opposed to it. The proposal is unnecessary and completely unsound. Ottava Rima (talk) 00:00, 6 November 2011 (UTC) Reply

In fact, import via an XML is very efficient, takes little effort and is always used to move projects from the incubator to a new wiki. Ruslik 08:34, 6 November 2011 (UTC) Reply

Unless you are using an outside script, it takes quite a bit to download then reupload XML. And that allows for them to be edited, corrupted, etc. Transwiki is the only truly safe method, and also goes far, far faster in my experience. No one has made a convincing argument about XML, and I have talked to many people with backgrounds in importing besides myself who feel that XML is probably too dangerous to allow anyone to upload with in any situation. Ottava Rima (talk) 14:54, 6 November 2011 (UTC) Reply

"in my experience": that's good for you, but in my and others' experience, XML works better. "many people besides myself", I haven't seen anyone else complain here. SPQRobin (talk) 16:27, 6 November 2011 (UTC) Reply

Help me out here, as there seems to be a lot of polemic discussion around what is meant to be something that is simple in concept the initial configuration and population of data. Merging political with technical with grand aspects of "nay saying" just makes it difficult to separate out the components and we grind to "too hard/cannot be bothered/wtf/etc."

I believe that the proposal is for new wikis to have a global import group capacity. At this point, I believe that the clarification needs to be made:—

• is this configuration just for these wikis in their initial phases, or is this expected to be a permanent right allocation to the wiki? If this is only required with start up the wiki, when would it be turned off and by whom?
• Which mw:import method is looking to be done, and is this prior to going into wild? Or is it being done when the punters will also be unleashed? ie. if a complex method is being used that might hose data, are we minimising data loss from editors?
• Security issues. We have people at WMF who write the application, and can make more informed decisions than pretty well any of us. If they are comfortable with the process, and we can run a check across the data before going live, and they are still comfortable, then who are we to try to be more expert?
• Can this "import" look to be undertaken and complete before the vast bulk of the users are allowed in, or before a beta label is removed from the wiki. Removal of the beta/creation sign means that import has been done, testing undertaken and the risk of corruption is back to normal levels.

billinghurst sDrewth 07:01, 7 November 2011 (UTC) Reply

The idea behind this is that when a new language version of one of the Foundation's projects is given final approval, the pages of the "test wiki", which is required by Language proposal policy and hosted on Incubator, BetaWikiversity or Old Wikisource, will be imported to the new subdomain wiki. The current process is that a user (typically a sysop from Incubator) requests temporary import access to the new wiki on SRP, imports the pages, and then immediately notifies stewards once he is finished and sure that no pages are missing (this doesn't take longer than a few days, usually). - So also the proposed global group is only for the new wikis' starting period, too. In no case is there any justification to make it permanent. Stewards would in the future be asked to remove a wiki where the import is done from the wikiset instead of managing individual users' rights.

The import method that is used is that XML files created by Special:Export on Incubator are stripped from the prefixes, and then imported via Special:Import on the new wiki. Please have a look at incubator:I:Exporting, which is a detailed description of this (in some parts rather a longbreathed how-to).

Regarding your last question, this is usually achieved. New WMF wikis get this [1] as their initial main page; most users are also well-informed that importing (instead of e.g. copying the pages) is better for reasons of license and traceability of the page history; and the only edits that happen before the import is complete are user page creations. --MF-W 17:15, 8 November 2011 (UTC) Reply

Additional notice: the problem is that a sysop of the new project mostly doesn't have any experience with importing pages from one to another project (sometimes, there is no sysop at all as the procedure of voting and getting the rights can sometimes take a logner time). More over, when a sysop starts with a new project (I have this experience from more then one), he has another problems to solve than learnig importing. -jkb- 18:14, 8 November 2011 (UTC) Reply

This is the previous extent of a vote for the last major group like this. At the very least, we would have to have a long period of discussion, put forth an actual proposal, have a global RfC, etc. Why this is being pushed through with few people to see is beyond me. Ottava Rima (talk) 00:37, 6 November 2011 (UTC) Reply

No; global sysops have a large impact, while this proposal is only for making the technical process of importing new wikis easier. SPQRobin (talk) 16:27, 6 November 2011 (UTC) Reply

Saying that there is not as big of an impact does not mean that it doesn't affect multiple Wikis and must follow the rules. You don't get an exception to that. Ottava Rima (talk) 19:25, 6 November 2011 (UTC) Reply

The burden of evidence is on you, and there is no way to claim that you can download and reupload faster than using what is already built into the code (i.e. transwiki). Ottava Rima (talk) 19:27, 6 November 2011 (UTC) Reply

For the amount of pages we are talking about (usually several hundreds) it is faster. Another advantage is that the prefixes from Incubator can be removed before importing so there is no need to rename (and edit, in the case of wikilinks) every page afterwards. --MF-W 19:48, 6 November 2011 (UTC) Reply

The only way to do hundreds of pages of downloading and uploading via XML (because there is no other way to do XML than that) would require a script that would be fundamentally flawed, as has already been demonstrated in a previous oppose. This is a major problem and it is compounded by you guys not following the rules for proposals. This is not something you can pass in less than a year worth of discussion. Meta doesn't work the way you are trying to right now. You don't even have consensus and you tried to slip it by. You guys really need to do things the right way and actually listen to real concerns instead of acting the way you are acting. Ottava Rima (talk) 03:17, 7 November 2011 (UTC) Reply

I created the 'New wikis importer' global group based on the 'all existing wikis' opt-out wikiset. Ruslik 10:24, 8 November 2011 (UTC) Reply

Does Wikimedia take essays written in regards to cross-wiki involvement? I felt inspired, and I'd like to write an essay myself. WhisperToMe 01:37, 5 November 2011 (UTC) Reply

Certainly, if you have something to say that's general in scope, this is a great place for it. You might want to look at Category:Essays to see some of the things others have written. Often people will start by creating a page in user space before transferring it to mainspace. I don't think that's required, but it's a good way to give yourself space to fully develop an idea before inviting others to contribute to it. Hope this helps! -Pete F 06:00, 5 November 2011 (UTC) Reply

I have silently observed Wikimedia for many months.

It is the worst site ever and totally dominated by a feminist agendum which uses stats to 'prove' that women have no say.— The preceding unsigned comment was added by 58.179.235.156‎ (talk)

Does no one else find it ironic that quoted stats show that only about 9% of contributors to Wikipedia are women, whilst maybe 90% of comments are to do with complaining about this - as if it was the fault of males.

It isn't. For around 100 years, at least in the West, there has been little to stop women from doing anything, except for lack of interest.

No man forced Lady Gaga to be what she is. And no man ever forced women to buy womens magazines which thrive on scandal,trivia and gossip.

Wellhere is one woman who breaks the mould of both gossip and the perpetual whiners about women not getting a fair go - Ellen Brown - http://www.webofdebt.com/ — The preceding unsigned comment was added by 58.179.235.156 (talk)

I know what you mean. Women are now totally free to exploit themselves as pop-music sex icons. And we even let them vote (except in Vatican City, the dude's paradise). What more do they want? Kaldari 23:52, 7 November 2011 (UTC) Reply

Kaldari... that kind of humor is... weird. Seb az86556 23:56, 7 November 2011 (UTC) Reply

I just noticed that some Google Chrome advertisement distributed by Google AdWord, contains the different logos of Google products and unexpectedly the Wikipedia logo.

Screenshot (hit enter again on URL bar): http://image.bayimg.com/eakkgaadn.jpg

direct link (not always work): http://pagead2.googlesyndication.com/pagead/imgad?id=CNOEuYCcjPSXwQEQ2AUYWjIINcKFo_7spzI, http://pagead2.googlesyndication.com/pagead/imgad?id=CNLpqe_Vt7DdzgEQ2AUYWjIIBMV_3ndyqFg

Is this authorised by the Foundation, or it's an infringement? --Kiyokoakiyama 04:23, 8 November 2011 (UTC) Reply

Interesting question. I've forwarded a link to this item to the WMF legal team. By the way, are you aware that your screen shot leads to a "403 forbidden" error? Maybe you could upload it here, temporarily, until this issue is resolved? -Pete F 05:41, 8 November 2011 (UTC) Reply

http://bayimg.com/eakkgaadn , annoying referrer blocking --Kiyokoakiyama 06:12, 8 November 2011 (UTC) Reply

Done I checked with the Wikimedia legal team, and am pleased to report that this is properly licensed use :) -Pete F 18:25, 8 November 2011 (UTC) Reply

Hi. Could someone direct me to who-ever was the main ringleader who worked up the quality objective of the 5 year strategy plan? Thanks! 71.246.144.154 20:02, 8 November 2011 (UTC) Reply

• Wikimedia Forum
• Noticeboards
• Communication
• Meta-Wiki organisation
• Multilingualism

• Pages using deprecated source tags
• Pages with broken file links