hi,
i am nearly got it to work, except search is not working. i have
tried different combinations of rewritrules, but to no avail. what i
use is given below, based on the entry in meta.wikipedia. obviously
i don't know mod_rewrite well enough to go much beyond.
i am using mediawiki 1.3.1 installed in /wiki/. the .htaccess file
is in /wiki/.
The LocalSettings.php variables are:
$wgScriptPath = "/wiki";
$wgScript = "$wgScriptPath/index.php";
$wgRedirectScript = "$wgScriptPath/redirect.php";
$wgArticlePath = "$wgScriptPath/$1";
Thanks in advance for your help.
saurav
-----
# first, enable the processing
RewriteEngine on
RewriteBase /wiki
# Verifying if user forgot to put trailling slash. If so, we'll rewrite to Main_Page
RewriteCond %{REQUEST_URI} ^/wiki$
RewriteRule ^(.*) /wiki/index.php [L]
# Don't rewrite requests for files in MediaWiki subdirectories,
# MediaWiki PHP files, HTTP error documents, favicon.ico, or robots.txt
RewriteCond %{REQUEST_URI} !^/wiki/(stylesheets|images)/
RewriteCond %{REQUEST_URI} !^/wiki/(redirect|texvc|index).php
RewriteCond %{REQUEST_URI} !^/error/(40(1|3|4)|500).html
RewriteCond %{REQUEST_URI} !^/wiki/favicon.ico
RewriteCond %{REQUEST_URI} !^/robots.txt
# Make sure there is no query string. /Adrian
# This gives "badly formed search query".
# gets /wiki/Special:Search?search=somequery&go=Go instead of
# /wiki/index.php?search=somequery&go=Go
RewriteCond %{QUERY_STRING} ^$ [OR] RewriteCond %{REQUEST_URI} ^/wiki/Special:Search
# Rewrite any article as wiki/index.php/article and stop
RewriteRule ^(.*)$ index.php?title=$1 [L]
--------
Jens Frank wrote:
> Modified Files:
> DifferenceEngine.php
> Log Message:
> BUG#244 Backed out changes done in Patch 1.33 due to major
> security problems. HTML tags were not escaped and it was possible to execute arbitrary javascript code
Can you give me an example of two article texts such that the diff
between them produces this security problem?
Thanks,
Timwi
1.3.2 fixes since 1.3.1:
* Fix namespaced page creation links when no go match
* When cookies are disabled, don't show login screen twice
* Install should no longer die when PHP is pre-configured to compress
output
* Fixed bug that caused long Japanese pages to time out with Tidy active
* When session.handler is set incorrectly, try automatic override
to 'files'
* Watch/Unwatch links back to the affected page instead of Main Page
* Upload link no longer displayed on Monobook if uploading is disabled
* Special:Allmessages faster, shows correct original text, works in
safe mode
Anyone still running the 1.3 beta releases is _strongly_ recommended to
upgrade to the current code due to numerous fixed bugs and a security
vulnerability in the betas with some PHP configurations.
Note that while MediaWiki through 1.1 required register_globals to be
on, 1.2 and 1.3 *do not*. If you have register_globals on, you should
turn it off unless you are absolutely sure you require it for some other
package. See http://php.net/register_globals for general information.
Release notes:
http://sourceforge.net/project/shownotes.php?release_id=264310
Download:
http://prdownloads.sf.net/wikipedia/mediawiki-1.3.2.tar.gz?download
Wiki admin help mailing list:
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Bug report system:
http://bugzilla.wikipedia.org/
Play "stump the developers" live on IRC:
#mediawiki on irc.freenode.net
-- brion vibber (brion @ pobox.com)
Hoi,
I have a 8878 big botanical glossary that I want to add to the wiktionary. I already have asked Andre Engels to help me out with preparing the upload and helping me out with doing things more easily aided by programs.
However some words are capitalised and some are not as they should be. I do not want to upload all these words before the capitalisation has been turned off for nl:wiktionary. It is just to much work to have it corrected at a later date.
At this moment the slim majority that prevents en:wiktionary to forego first letter capitalisation are some IP-numbers that have it for the Nayes. This "democratic" process prevents both nl:wiktionary and de:wiktionary from having the requested capitalisation turned off. In the discussions on en: it is stated that each project has the choise to decide on this issue. This is however not the case as the programmers want to have all wiktionaries the same way.
In order to have some more discussion on the subject, I send this message both to the wiktionary and wikitech list. I also send it to Jimbo Wales as he does not monitor the wiktionary list afaik. (I spoke with him on sunday..). Please, let us discuss this issue. The nl:wiktionary is on 3123 words, we will already have a big job to get things working again after the transfer. With time this will only increase and again, I will not upload the glossary and have to do these eventually as well.
Questions:
*How are we goint to resolve this issue?
*How can we turn capitalisation off, preferably in a fased way?
*Are there ways to help out with programs?
*How long are we going to discuss this issue before coming to a workable decision. NB not only for the wiktionaries but also the system maintenance?
Thanks,
GerardM
On Sat, Aug 28, 2004 at 04:16:43PM +0200, Marco Krohn wrote:
> On Saturday 28 August 2004 06:06, Jens Ropers wrote:
> > If you doubt the standards of our editorial review mechanisms, go try
> > and introduce some decidedly un-encyclopaedic (unproven, contentious
> > and/or unacademic, etc.) information into an article of your choice.
> > Then check back and see how long your contribution will remain in the
> > article. My confidence is high that -- depending on how much this
> > contribution falls short of encyclopedic standards -- you will find
> > your contribution challenged on the respective article's discussion
> > page (where you will likely be asked to provide references for your
> > claims) or outright removed.
>
> we just had someone on the de mailinglist who purposely modified four articles
> and introduced a mistake in each of them. He also told us which articles he
> modified and claimed that none of the mistakes was detected by now. I checked
> three of the articles he was right with his claim.
>
> In the german article about "consumer surplus" the error was there for about 9
> (!) days before I removed the nonesense. In other articles the errors were
> there for more than 9 days.
>
> I agree with most of what you wrote, but I think it is a mistake to believe
> that we have any kind of review system which is on par (wrt error
> elimination) with a real peer review. At least my experience is that the
> probability for finding a mistake in Wikipedia is by far higher than for
> Britannica.
I'm seeing a lot of mistakes in Wikipedia too. It seems to be have a lot more
mistakes than it used to.
Imagine a wiki without a Recent Changes page - the error can stay in it for
days or even weeks before it gets corrected. Such a wiki wouldn't work well.
But that's almost the situation in Wikipedia today - because the Recent Changes
is so huge, very few people will check all articles, and as the topics of articles
become more specialized, chances that non-trivial error will be spotted in RC
are getting lower and lower.
Articles monitoring helps, but not that much.
I think we just have to divide RC into reasonably-sized parts.
We should group categories into some related standarized sets (without standarization
some of the categories would be much more likely to end underchecked), provide RC
for each of those sets, and a huge RC for articles without categories,
from which the edits in the articles would be categorized for later review
by people competent in given area. RC in all categories could stay,
but it would probably be only used for things like obvious vandalism
and newbie experiments (not like it's much different today).
Possibly more readable on wiki :-)
here :
http://meta.wikimedia.org/wiki/Developer_payment_poll/results#Results_for_t…
Greetings :-)
---------
1 Results for the poll
Are you, or have you been in the past, involved in
development of MediaWiki or maintenance of the
Wikimedia servers?
12 people answered directly to the poll I had
additional partial answers from 5 more people on irc,
ranging from 1 sentence to 1 hour discussion.
Some people did not answer to all questions, or on the
contrary went to greeeeeat lengths :-) I tried to sum
up very much for the public report. I also removed all
what appeared to me possibly an ambarassing answer in
public. I left names when it does appear to me public
information unlikely to be problematic to distribute.
If so, can you briefly indicate which specific
activities you have done (maintenance of servers,
performance improvement, development of features,
debug, interface, "hotline" etc)
MMA: Feature development.
EMO: maintenance of servers, performance improvement,
development of features, debug, interface, "hotline"
etc.
Timwi : minor (bug fixes)
EZA : Programming:
* International Statistics
* TomeRaider version (which is pretty popular).
This was a major undertaking as I wanted to get it
right (different versions for Pocket PC, Palm and
EPOC, homegrown math formula rendering engine,
extensive unicode support, patching up invalid html
where ever possible, etc)
EasyTimeline most recent project, still some loose
ends (UTF-8 soon, unicode font support for ja: zh: etc
later this year). Some Wikipedias have already
embraced it, Germans made 40 timelines in a month.
TST : code, but most of my time server administration
and helpdesk work on #mediawiki.
Looxix
* Bug repport and sorting.
* Search recise information for bug repport.
* Test if a bug is really solved.
* Interface translation
TAW : Developement: math system and some other
changes, some bugfixing. Some administration, mostly
for Polish Wikipedia, Polish Wiktionary, and Kashub
Wikipedia. I'm doing technical support on Polish
Wikipedia. Plus geographical plugin
X13 : performance improvement, development of features
Tom : Some bugfixes for Mediawiki, two or three bots
for pywikipediabot, the webshop and high IRC activity.
GWI : Concept, installation, maintenance of squid
servers, MW/Squid integration,
development/implementation of apache load balancing,
writing/maintaining log analysis software, #mediawiki
support, Monobook skin system, parser performance
testing and back-to-regex after tokenizer performance
problems, user/site-wide style system, xhtmlization of
the parser, HTML tidy integration for xhtml
compliance, bug fixes etc
Hashar : Developped a few features, lot of bugfixing,
code optimization, code organisation. :
Dammit : Mostly database stuff, porting to PostgreSQL,
some debugging, some fixes :
JeLuF : bug fixing, thumbnail features, code cleanup,
single login :-), sysadmining the server farm
Which tasks, if any, really ought to be done, but
currently are not?
* parser speedup and performance (wiki syntax
description): 3
* database schema redesign to allow for faster
queries and to have a consistent CUR and OLD table
scheme, important for directly linking to specific
revisions which currently is only possible in the OLD
table : 4
* systematic review of all database queries for
performance and scalability : 1
* db performance (undefined) : 3
* full internationalization of mediawiki (i.e.
multiple languages in one installation, both in terms
of content and UI; completely redesign interlanguage
links to avoid massive redundancy between wikis) : 1
* per user langage setting (allowing to access
en.wikipedia.org with a french interface for ex).: 1
* Clean up of LanguageXX.php files to store all
translateable text in the MediaWiki: namespace for
example is needed for user-selectable UI language : 1
* image sharing across projects : 1
* single sign-on (Wikimedia Commons) : 2
* redesign file uploading and image pages; current
image page system is unintuitive and redundant
(captions duplicated on pages and in text) : 1
* To have (more or less) public rsync for the
images and bring up new projects like wikicommons or
Wikipedia for deaf : 1
* instead of storing every revision of every page,
store incremental diffs with interleaved complete
revisions as CVS and other version control systems do
in order to decrease storage space by an order of
magnitude or two : 1
* redesign discussion system from the ground up so
that talk pages, mailing lists and forum can be
synthesized into one system : 1
* implement web of trust system in order to allow
for user-based filtering of RC : 1
* Switching to UTF8 all projects : 1
* real-time fundraising system for all Wikimedia
sites : 1
* Opening up WikiMedia source base by improving
documentation (in source code, but also overall design
spec) : 1
* Easy mirroring worldwide for safer data : 1
* Clean refactoring and rewrite : 1
* Fixing bugs from sourceforge bug list : 1
* structuring/prioritising feature requests : 1
* None : 1
* Very hard to know : 1
Are there any tasks that you would like to get
involved with but have not yet done so?
* Parser speedup : MMA
* external editor / WYSIWYG support : EMO
* make template syntax consistent and fix bugs :
EMO
* "watch newly created articles" : EMO
* per page bans : EMO
* cookie-based blocking : EMO
* search in page histories : EMO
* protected page redesign... : EMO
* Database redesign : Timwi
* New database shema : Has
* Server administration : Dam
* Bugzilla : Timwi
* Finish geographical module : TAW
* Yes, but not described : Tom
Others want to be less involved or declared already
too busy.
If so, what is preventing becoming more involved with
those tasks?
Among answers listed, lack of time is a hit.
Some mention
* lack of money (and indicate they would be
motivated by money)
* need to gain trust from peers to have more
access
* one mentions limited access rights
Is there anyone that you would like to be more
involved with certain tasks? If so, which tasks?
* EMO : Brion for the database redesign
* Many developers in writing plugins and
extensions as in Moin, not reallypossible in MW
currently. Needs a really modular framework that's
held together by events or similar : GWI
* Everyone in the dev / sysop team do that on
their spare time as a hobby. I am not sure we want to
force anyone to be more involved. : Has
Some of the answers given were removed.
Did you find it easy to join the development team? Did
you receive appropriate guidance to allow you to start
helping? Do you feel it is easy now for newcomers to
get involved?
I thought it best to summarize opinions gave on this,
since it went from the hardcore developers to the
current newbies :-)
Globally, most recent people did not feel that easy to
join, though there are some variations. The bad points
mentionned are
* welcoming newbies is not a priority
* source code, patches posted by newbies tend to
be ignored or do not receive attention.
* it is not easy to send patches
* mediawiki is specific to one site, so makes it
harder to experiment,
* a complicated and little documented code
* lack of modularity of the software, making it
difficult for a newbie to work on a independent issue
* lack of documentation
* lack of guidance
* there is an unsufficient system design document.
* confused bugbase, which makes it difficult for
newbies to define what should be done or could be done
* poorly advertised, poorly structured and poorly
prioritized to do list (new features and feature
enhancement)
However, most mention that they were helped by
knowledgeable developpers, that being given CVS write
access was highly appreciated and joining irc very
helpful.
It is also mentionned that making it harder for
newbies is also safer for the application.
Some mention they chose standalone projects on
purpose.
what do you think would help new developers to "get
in"?
* Code more readable and software more modular so
that other applications use it
* Bugzilla, so that developers without CVS access
can give their patches
* Better advertised, structured and prioritized to
do list.
* Better documentation of sources (could give much
credit for a newbie willing to start doing this, and
be much informative to them) :
* A more complete system design document
* IRC to answer questions and build the trust
* that the developer provides good code
* More information and guidance on what needs to
be done
* More general wikipackage for mediawiki to be
used by other sites :
* Clean, short code and a good plugin architecture
as in Moin, event subsystem to further modularize the
thing (currently being worked on in Moin)
Was there anything in particular that you found helped
you to join in?
* CVS access : 2
* Wikitech : 1
* IRC : 4
* Knowledge of english : 1
* Php: Has
Are you proud of what you are currently doing?
* Yes : 7
* Not really : 1
Do you feel your work is undervalued or
under-recognized?
* No : 6
* Think that it is likely new developers feel
unrecognised : 1
* I do not really care : 1
* Yes a bit : 1
* I don't care, I just do it for me, if it's
improving the project then
* it got value and will be recognized somehow : 1
If you are now less involved with the development team
than you were previously, what made you decrease your
contribution there?
* Lack of time :
* Proposed features were discussed to death on
mailing lists :
* Time and money :
* Other external essential activities :
* I need to decrease participation, because my
real life suffers from it
* Holidays
* Waste of time on messy code, which may not have
a future. Little appreciation. Need to earn money
(student) :
* Summer time ! Not really willing to pass 10Hours
per day behind the screen when it's sunny outside :o)
:
* Dayjob and personal life, Wikimedia distracts me
:
What is the best reward for your good work, or what
way would you prefer to be rewarded?
* Quoting irc: <someone> thanks hashar for your
help !
* People using my work, and enjoying it :
* People using the work :
* Money would be helpful :
* People enjoying me, and working with me,
discussing my work and feeling good friends :
* Being able to brag at how much money I made from
the task : Timwi
* Appreciation (mails or comments not being about
bug report or criticism are especially helpful) ):
* Appreciation, as long as other more essential
needs do not come in front :
* When something that needs to be done is done :
(money and appreciation are not very important)
* Recogntion (developer of the week) :
* Perhaps honoring from the Foundation, good in CV
:
* Money and naming/recognizing the contributions
on a dev page and in the release notes, similar to the
linux kernel release notes :
* Wikipedia running (and food when I need it) .
Do you think any of the following could help? Thinking
only of technical considerations, please rate the
following on this five point scale from A to E.
* A. Yes, I am convinced that could help a lot. I
strongly support
* B. Yes, it might help eventually. I slightly
support this
* C. I don't know if this will help. I neither
support nor oppose this
* D. No, I think it will not be helpful. I am
slightly opposed to this
* E. I am strongly opposed to this option, whether
helpful or not
1. Having paid staff (permanent, full or part time,
for example a sysadmin). (Ie, paying someone for
rather loosely defined activity)
* A : 5 (1 mentions sysadmin/DBA)
* B : 4 (2 mentions sysadmin) - but money could be
better spend on servers
* C : 2 (1 says would force hierarchy and decrease
motivation)
* D : 1
* E: 1 (a developer)
2. A system of bounties or similar. For example, a one
off contract for a specific task, such as the
development of a feature.
* A 3 (one indicates that we should have a good
committee to decide what is important to do)
* B :3 (call for tender)
* D : 5
* D/E : 1 (bad for volunteer culture, plus jalousy
for those where no bounty are placed)
On irc,
* 2 more opinions were neutral
* 4 more opinions were slightly opposed.
One suggests here that the next bug / request tracker
will have a vote feature, users can vote for bugs they
want to get fixed this way developpers will be able to
focus on user most wanted fixes
3. An award system : nomination of a "developer of the
month" (for a special thank you time) with an
explanation of why. This could be advertised on IRC
with a paypal link on the fundraising page.
* A : 0
* B : 4
* C : 3 (some because they do not care) (1 :
usually poorly informed decision. Would prefer a more
general wikipedian of the month (editor and moderator
included) (1 does not want that for him)
* D : 2 (underrecognition and loss of motivation
of non winners)
* E : 2 (no prioritization, plus tension among
developers, boring, because it would be brion4ever) !
4. Another award system. For example, once a year,
between one and three developers could receive an
award of the "best developer of the year", possibly
with a price of hardware or of money, and thank you
notes splashed everywhere.
* A : 0
* B : 4
* C : 3 (2 just did not care)
* D : 2
* E : 3 (1 elitist)
5. A "get to know me more" system : A special "know
more about our developers" page, where each developer
may explain how he contributed to the project, add a
paypal link, webpage link etc. This could be
prominently linked to from the fundraising page.
* A : 3 (1 yes ! The community will then be able
to know more about the guys behind mediawiki. I really
strongly support that. It could even be part of the
wikimediafoundation page :o)
* B : 3
* C : 4 (why not, but little impact expected - but
liberal access. With contributions list)
* D : 0
* E : 1 (I can use user page)
6. Professional training to some of the developers if
the Wikimedia Foundation could secure free or reduced
price training.
* A : 0
* B : 2
* C : 3
* D : 3 (hard to implement - usually self
training, courses are expensive � would prefer self
allowance for book purchase or online registration -
already available on the net))
* E : 3
7. Make our third global press releases oriented
toward development issues, in order to attract new
contributors for software and hardware issues. Focus
on tech news site for promotion.
* A : 0
* B : 3 (probably not very helpful, but worth
trying. No side effect)
* C : 7 (probably wont have much effect -
* D : 2 (normal people would not understand)
* C : 1
* E : 1 (audience is too small)
A comment reflecting others: the more the software
will be used the more peoples will be interested in
developping it. Just focus on announcing that
wikipedia is using the freely available MediaWiki
software giving examples of other use (such as
wikitravel). That will attract new users of the
software thus leading to more developpers
8. A meet-up for developers to work together
occasionally (in Germany perhaps, with round of beers
paid by the foundation :-))
* A : 5 (very appreciated. 1 is not sure it would
help, but would be nice - 2 are worried about Tim and
Brion issue, 1 strongly support the paid round of
beer)
* B : 5 (but 1 fear it would be expensive)
* C : 0
* D : 0
* E : 1 (this 1 is german...)
9. A b ig clean up of the development pages on Meta,
and clearer paths to help new developers to "jump in".
* A : 3 (1 especially extended documentation for
the software)
* B : 6
* C : 1
* D : 0
* E : 1 (do not delete anything, but clearer paths
would be good)
10. Nomination of "organiser(s)" whose role would be
to clean up the list of tasks to do, clarify
priorities, go around asking who could do that,
attract volunteers etc...
* A : 3
* A/B : 1
* B : 4 (1 but not nomination -> voluntary
proposition)
* C : 5 (would not help much, could generate
tension)
* D : 1 (could lead to tensions)
One said not dedicated organisers, but dev should
learn to handle : task management tool for example
Others
MMA : When discussion about a feature to be
implemented starts, set an 'end date' for the
discussion :
EMO : "Bounty system" is really misleading, what is
needed is an open call for tender system where a
steering committee appointed or elected by the
foundation in cooperation with the dev team makes a
list of high priority tasks, and developers can then
declare under which conditions they would be willing
to complete these tasks, e.g.
* "I would be willing to do this for free, but
only by November 2005"
* "I would be willing to do this at a rate of
$20/hour"
* "I would be willing to do this for $500/month"
The committee would then negotiate the best possible
contracts/agreements with the developers.
1 said : developers (though very busy and under
pressure) should make an effort to answer questions
and inform (servers status, servers stopped for
maintenance tasks, new features, ...)
TAW : mediawiki should be used by more users. More
users=more developers
GWI : Name a tech/user contact person (similar to
organizer above, but not quite the same) that would
communicate things from #mediawiki to the users (takes
a lot of time otherwise), bundle requests, explains
rationales behind design decisions etc
GWI : Release notes as above :
Would you be interested to make a living directly or
undirectly from Wikip�dia ?
* Why not, but I�ll do the job anyway : 1
* Yes : 3
* Why not, but no strong position : 1
* I would regret that this happen : 1
* No : 1
* Not directly : 1
* No : 1 (should be kept volunteer)
* Yes : 1 (trying with the wikireaders)
* Yes : but task based or time based : 1
* No, I am lacking a lot of experience in
development : 1
If the Board were to hire staff, what type of staff do
you think would be most helpful?
* One sysadmin, one secretary : EMO
* Sysadmin : EZA
* Sysadmin/DBA : TAW
* Someone taking care of things for which no one
is interested (clean up code, bug report, feature
request). New features should be left to volunteers. :
MMA
* On call sysadmin : X13
* 24/7 sysadmin : Tom
* A sysadmin or developer with moderation
abilities. Senior experienced person.
* No need for staff : Has
* Sysadmin : Dammit
* Illustrators : TST
* Legal advisor : LOO
Do you think staff should be hired internally or
externally? (ie, someone already volunteering, or
someone who is not a participant)
* Internally : 6
* Externally : 6
Why externally : general answer is "to avoid tensions"
Why internally : general answer is "we have the
capabilities among us"
If the Foundation were hiring, would you consider
applying for a development position?
* No : 6
* Yes : 1 (but no move to USA)
* Why not, but the Foundation currently has much
more pressing needs (hence, long term thought) : 1
* Why not : 1
* Yes : 1 (for task based such as bounties)
* Yes, Sysadmin : 1
Erik did not answer.
How would you summarize your view on the proposed
bounty system? Strongly support / support/ neutral/
opposed/ strongly opposed/ undecided.
* Strongly support his proposal but is unclear
whether we are talking about his system below, so did
not answer following questions : EMO
* Strong support : 1
* Support : 1 (strongly his system, but would
support any type of system. Would prefer developer
community to set priorities, but board decision would
be fine)
* Support : 1
* Neutral : 2
* Neutral : 1 (irc)
* neutral/opposed : 1
* neutral/opposed : 4 (irc)
* Opposed : 1
* Strongly opposed : 2
If opposed, please briefly indicate why
* Will introduce competition, so pressure, hence
remove the fun : 1
* Loss of the gift culture : 3
* I know not of any project where it worked : 2
* at least, until other options have been tested
Consider that the steering committee would have a
major impace on any success : 1
If the Board decided to use a bounty system, would you
try to get involved to get some of the bounties?
* Yes, but for tasks I was planning to do anyway :
1
* Yes : 3
* Probably not, unless I planned to do it anyway
(could be faster) : 2
* Not specifically : 1
* No : 1
* Undecided : 2
On irc,
* Probably yes : 3
* Undecided : 2
Do you feel your motivation level would be increased
or decreased through the use of a bounty system?
* Increase a lot : 1
* No change : 1
* Undecided : 1
* No : 3
* Will appy to the bounty only if he agree with
the general development direction : 1
* Certainly not increase : 1
* Possibly decrease : 1
If you are opposed to a bounty system, would its
implementation cause you to decrease your level of
contribution?
* Increase : 1
* Probably no difference right now, possibly
decrease in the long term : 1
* No change : 2
* Undecided : 2
* Irrelevant : 1
Please cite three tasks that you feel would be well
suited to a bounty system.
* Redundant fixes/updates :
* Enhancements like having one installation for
many wikis or even *Installing and custimizing
mediawiki for other projects :
* Parser rewrite/speed optimization, feature
rewrites/porting, caching, network filesystem RAID
implementation, Differential storage :
* Caching algorithms.
* Parser performance.
* Automated interfaces :
* full internationalization of mediawiki (i.e.
multiple languages in one installation, both in terms
of content and UI; completely redesign interlanguage
links to avoid massive redundancy between wikis) :
* database schema redesign to allow for faster
queries and to have a consistent CUR and OLD table
scheme, important for directly linking to specific
revisions which currently is only possible in the OLD
table :
* real-time fundraising system for all Wikimedia
sites :
* systematic review of all database queries for
performance and scalability :
* redesign discussion system from the ground up so
that talk pages, mailing lists and forum can be
synthesized into one system :
* image sharing across projects :
* and single sign-on (Wikimedia Commons) :
* redesign file uploading and image pages; current
image page system is unintuitive and redundant
(captions duplicated on pages and in text)
* instead of storing every revision of every page,
store incremental diffs with interleaved complete
revisions as CVS and other version control systems do
in order to decrease storage space by an order of
magnitude or two :
* implement web of trust system in order to allow
for user-based filtering of RC :
Others consider it is not good for anything, does not
work, have no opinion or are not informed enough to
say.
Given that we would roughly evaluate the number of
hours for a task, how much do you think should be
given for a bounty (ie, amount of money per hour)?
Alternatively, how much would you suggest the
Foundation should offer for the tasks you mentioned
just above?
* No answer : several
* Should be decided by the developer community or
board : 1
* WMF should offer a price to attract developers
from underdeveloped countries : 1
* Given the amount of time and our budget, it
would be just a symbolic reward : 1
* Waste of money, as it does not work : 1
* Depends of type of task : 1
* 5-10 euros : 1
* Depends, roughly between 5-15 dollars per hour :
1
* Depends : 1
What do you think would be the largest benefit of
implementing a bounty system?
* Getting stuff done that are not done :
* Increase motivation :
* Central steering of priorities :
* Amount of contributions will be up
* Motivation and a point for externals who want
special features :
* Will steer development in a certain direction :
* None
What do you think would be the largest harm caused by
a bounty system?
* abusing the system
* competing with unfair methods :
* leaving because of (felt or real) pressure to
work :
* not joining because the development is no longer
"free" :
* joining soley because of the money; then better
hire someone for real
* People leaving, but no one consider doing that,
so this is not an issue :
* Loss of the gift culture :
* Having developpers focusing only on largely paid
tasks forgetting the lowest one :
* Decrease in quality of contribution :
* Disruption of the community
* Loss of volunteer feeling, competition :
* No answer :
* Can drive people away if they do not agree with
the development route
Do you have your own pay pal account?
* Yes : MMA, EZA
* No : Timwi, but intend to
* No answer : EMO (ant : but I think he does)
* No : LOO
* No : Taw
* Yes : X13
* Yes, Tom
* Yes : GWI
* Yes : Has
* No : Dammit
Would you be interested in having a little bio about
you and your achievement on WMF site ?
* No : 2
* No : 1 (a link to my user page)
* Yes : 7
Some wish that all dev are listed. Some just want the
name listed with a link to their page
Would you be interested in having a link on the site
whereby users could donate money to you via this
account
* Yes :6
* No : 1 Put a "give to wikimedia foundation" link
instead :o)
One mention the link should be for all developers with
a paypal
One mentions that small sums is better than WMF giving
huge sums and exterting implied central control of
work
Would you be interested in receiving professional
training ?
* Yes : 3
* No : 8
One mentions it would be hard to implement. Others
consider themselves welltrained or that training is
available on the net.
If developers were to be awarded special prizes by the
Board, would you prefer to receive money or hardware?
* Money : 5
* Books or online subscription : EZA
* Hardware : 2
* Money or donated hardware : 1
* Money (perhaps to give it back to the
foundation) : 1
Are there any ways of improving organization that you
feel you can commit yourself to right now? For
example, cleaning up pages, writing documentation,
coaching newbies, writing technical press releases,
improving the bug tracking system, setting up a "tech
news" reporting page, playing the pom pom girl?
* No really : 2
* Bugzilla, then fixing bugs : Timwi
* No. Already spending too much time on it :-) :
EZA
* A new bug tracker : Has
* Sort the bug tracker : LOO
* Development : X13
* Documentation : Tom
* Writing clean code for next generation software
for Wikimedia : GWI
A task management thing wich allow several sub task
per task ex:
* Task #1 : documentation writing
o sub-task #1 : installation under windows
o sub-task #2 : skin documentation
* Task #2 : database shema
o sub-task #1 : new proposition
o sub-task #2 : MediaWiki code migration
o sub-task #3 : migration tools
o sub-task #4 : code testing (Has)
Documentation should be my commitment (answer
technical questions on info(a)wikipedia.de) : Tom
Answer questions on #wikimedia. (sorry... I lost the
name of this one :-()
[edit]
2 Comments
A few words (because I cant help...)
About getting newcomers
The idea of a press release oriented toward technical
issues was generally not perceived useful
* not enough audience for this topic
* Most developers consider the issue is not to get
*more* developers, but to have those currently around
more involved and more efficient.
However, several wish that the mediawiki code be more
modular, for the software to be used by other sites,
which would attract new developers.
This suggest as well that more advertisment of the
software itself be done.
About welcoming newcomers
What about
* setting up a sort of official committee (ie,
that a couple of names are officially listed as people
willing to guide new people)
* improving the welcome page (how to become a
mediawiki hacker - which could be more informative)
* very quickly orient newbies to irc
* set a page listing all developers, and
explaining what they did on the soft or the hard, so
as to help newcomers figure out who to contact and to
who talk to for a specific idea
* fix the absolutely frightening
http://meta.wikimedia.org/wiki/MediaWiki_1.3_comments_and_bug_reports
Here is the future key page :
http://meta.wikimedia.org/wiki/How_to_become_a_MediaWiki_hacker
It could have a link toward
* the bug list (cleaned up)
* a list of planned features (really planned
features, with status of development)
* some ideas of tasks which need to be done (hey,
look at the update here :
http://meta.wikimedia.org/wiki/Development_tasks)
About guiding newcomers
I would like to mention one thing about guidance. In a
project such as Wikipedia, it is best to be bold if
one want things to proceed. And it is those who dared
being bold or who had a strong opinion on what they
wanted to do who had little problem getting
integrated. On the other hand, some developers would
prefer more guidance, and apparently, those feel
unwelcome. I would dare to suggest that since we are
different and will always stay different with regards
to such personal pecularities, it would be best that
some developers take the time to think of tasks they
can suggest to those willing to get more guidance.
Toward newbies, it would be good that some developers
take the time to nurture the newbies a bit more till
those are able to manage things alone. Teaching always
take a bit of personal time, there is a fear of
responsability to commit the code of another one, but
it is beneficial in the long term to have yet another
one in the team. Unfortunately, it is not everyone who
likes to do that...anyway...
About recognition
I would like to set two pages listing many of you
* one page on meta would explain in details what
you have been doing in the soft. It could really be a
technical page, meant more to help internal people
know you better, contact you, thank you when they like
a feature and no not who worked on it specifically. It
might be a page of exchange between all of us
* one page on wikimedia. I would like that some
have the possibility to put a short bio of them,
perhaps quickly explain what they did (less tech
details please), possibly put links to a personnal web
site, add a paypal link so that they could receive
financial appreciation. Anyway, the point might also
be to help you perhaps to get a job if needed, or to
impress your mom, just as you wish.
About money
I think there are two issues at hand here.
First, we could perhaps organise the gathering of a
general amount of money which could be used to finance
general costs of developers, such as travel costs for
a meeting in Germany. This is little controversial and
there was thought given on the topic. I think more
will be said on the matter latter.
Second, money in exchange of tasks. This would be
money directly paid by the Foundation to thank some
developers for their work.
The board is willing to give it a try. I can't say we
embrace the concept entirely (I guess none of us is on
the strong oppose nor on the strong support). So, we
are willing to do a trial period, and this for a
limited number of tasks. I would recommand that
* a proper committee of developer is set, with a
large group to discuss and a smaller one to take
decision
* that each suggestion made above is considered,
explained in decent words (for non developers to
understand), if interesting : estimated in terms of
time of development (with possibly financial
suggestions) and that developers interested in the
task are identified. It would be nice as well, that
validation of the task is planned and estimated. Well,
this is all your job, but we ain't give money on
smoke.
At the end of the trial period, we will estimate the
benefits and the drawbacks. These will not be only
technical, but social as well, and the opinion of the
whole community is welcome. We wait for a feedback,
now, during the trial as well as at the end of the
trial. We will not proceed along the trial if there is
serious opposition from the community on the whole
:-). We consider there are possible benefits as well
as dangers in the whole idea, so we wish to insist
that this is only a temporary decision.
Thank you all for your participation :-)
Anthere 16:41, 25 Aug 2004 (UTC)
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
Warning: Yeat Another Crazy Idea of Mine ahead. If you're sick of these
(by bitter experience;-) delete this mail *now*.
Still here? Great!
OK, we all know that the current parser, while working, is not the final
word. It is kinda slow due to multi-pass, the source is confusing, and
there are some persistant bugs in it, like the template malfunctions.
I therefore suggest a new structure:
1. Preprocessor
2. Wiki markup to XML
3. XML to (X)HTML
Let me go through these. The preprocessor would basically do the
template and variable stuff; dumb text replacement, like a C/C++
preprocessor. It would generate the complete wiki-markup text, which is
then carefully chewed by the to-XML-coverter. The XML output is then
converted into HTML/XHTML for display.
Why have this XML step in there? Couple of reasons.
I think of XML which can be generated from the wiki text /without any
knowledge of the rest of the database/. The converter will not check,
"does this article exist" or "is this an internal link, an image, an
interwiki link, or what?". It should only convert "[[this|or that]]" to
"<wikilink page='this'>or that</wikilink>". Also, it should produce only
valid XML, no matter the input.
IMHO that would separate the actual *parsing* of the wiki markup from
its *meaning*. There are useful methods, functions, libraries
and-what-not for dealing with XML.
To have a few points working in favor of this idea:
* The wiki parser (#2) can be clean, brief and efficient without
worrying about the context of the page; it can focus on parsing wiki markup.
* The XML-HTML-converter (#3) can focus on the pure context of the page:
make a normal link, stub link, thumbnailed image, or a category or
interwiki link, etc.
* Both can be developed and maintained independently. To make thumbnail
display behave differently, I won't have to look at the dirty wiki
markup parsing at all ;-)
* We could have a decent XML output function at no cost.
* Other wikis, used to a different syntax, could easily switch to
MediaWiki by adapting the wiki-to-XML module.
For wiki-to-XML, we could even use an external parser. I am currently
toying around with one in C++ (yes, another one, and yes, one could
probably write it in two lines of Perl. So, go ahead!;-)
I *do* realize that this would mean a great change in our current
software. Therefore, I do not demand for this to be implemented in 1.3.1 :-)
But, in the long run, I strongly believe that this is the way to go. The
performace loss from doing two steps instead of one might even be
compensated for by increased performance of each specialized part. The
value of making the parser more modular, however, should IMHO not be
underestimated.
Magnus
P.S.: Hurricane "Charley" - Britannica's last hope... ;-)
Proposal:
Let's list the number of total user contributions next to all the user
names in the [[Special:Recentchanges]] list.
Rationale:
This will make it easier to focus on new users who may not yet be
familiar with what's acceptable and what not.
While it is true that there is no straightforward relation between a
bigger number of contributions and contribution quality, it can by and
large however be assumed that if a user regularly submits substandard
and/or mischievous contributions then the community probably knows
about that user.
So despite the shortcomings, seeing a user's number of total previous
contributions in the Recent changes list would be a step forward.
see: http://bugzilla.wikipedia.org/show_bug.cgi?id=245
-- Jens [[User:Ropers|Ropers]]
www.ropersonline.com
Hi.
What progress has been made on new parsers for the week that I was gone?
Is Magnus Manske still working on his? What about the BisonGen one
(sorry I forgot whose that was)? Has anyone done any work on mine?
If the answer to all those is 'no', is there still interest in myself
finishing mine?
Greetings,
Timwi