Developer payment poll/results

Results of the poll Developer payment poll done in july 2004. Anthere

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. plus two anons who answered just the day after....

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): 4
• 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) : 4

• 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
• Clean up of code : 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
• Ease of customization : 1
• Easy mirroring worldwide for safer data : 1

• Clean refactoring and rewrite : 1
• documentation for site admins and clarifying comments in

the code for people tweaking the code or writing extensions : 2

• Fixing bugs from sourceforge bug list : 2
• 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
• Special import and other things
• Writing codes rather than doing server admin.

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
• motivation

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) : 2
• 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)
• The new developer should have an idea of what he wants to do

Was there anything in particular that you found helped you to join in?

• CVS access : 2
• Wikitech : 1
• IRC : 5
• Knowledge of english : 1
• Php: Has
• Working on specific (defined) issue : 1

Are you proud of what you are currently doing?

• Yes : 8
• Sometimes : 1
• Not really : 1

Do you feel your work is undervalued or under-recognized?

• No : 7
• 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).
• "Virtue is its own reward" but I like other things too. Being told we're doing a good job is _nice_. Getting a few dollars on PayPal is _nice_.
• Possibly money, but mostly helping getting good references

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 : 6 (3 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 :5 (call for tender) - but not all are sure it would work
• C : 1
• 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 : 5 (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) (the team is too small, it will always be the sames)
• 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 : 5 (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 : 6 (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 : 6
• 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 : 8 (probably wont have much effect -
• D : 3 (normal people would not understand) (I fear newbies not knowing what to do)
• 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 : 6 (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 : 1
• D : 0
• E : 1 (this 1 is german...)

9. A big clean up of the development pages on Meta, and clearer paths to help new developers to "jump in".

• A : 4 (1 especially extended documentation for the software)
• B : 7
• 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 : 4
• A/B : 1
• B : 5 (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 : 4
• 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
• Not now : 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 : 7
• Externally : 6

Why externally : general answer is "to avoid tensions"

Why internally : general answer is "we have the capabilities among us"

Interesting and summarizing comment : External hiring risks culture clash and non-acceptance from the volunteers. Internal hiring will get a known quantity, and also is likely to fetch lower rates since we're already stupid enough to do this for free. ;) Some people have expressed the opinion that hiring an existing volunteer will merely shuffle priorities rather than getting more work done, to which I have two reactions: first, it's *important* to shuffle priorities because some things really are more important (or are to the foundation). Second as volunteers we're holding down day jobs or going to school or just have other things to do; hired staff may be able to free up more time and more importantly has a requirement to work even when it _doesn't_ sound like fun. Things aren't always fun, and while we do put in a lot of work, reliability will get more important as time goes on and the stakes increase.

If the Foundation were hiring, would you consider applying for a development position?

• No : 7
• Yes : 2 (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 : 3 (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 (irc)
• Neutral : 2
• Neutral : 0 (irc)
• neutral/opposed : 2
• neutral/opposed : 3 (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
• people holding back for money

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
• Possibly yes : 2
• 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
• Increase : 1 (I would feel less pressure to worry about unpleasant

things (cost of work to me) if I knew someone else was going to do it. And who knows, I might want to do one of those things and get some $$$. :)

• No change : 1
• Undecided : 1
• increase for paid tasks, decrease for free tasks
• 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  :
• Would get things done at low expense : 2
• 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 : 2
• 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
• Spending money unecessary
• claims of corruptiont
• attraction of different types of people into development, which would

scare away other devs

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 : 3
• No : 1 (a link to my user page)
• Yes : 8

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 :7
• No : 1 Put a "give to wikimedia foundation" link instead :o)
• Not yet : 1

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 : 5
• No : 8

One mentions it would be hard to implement. Others consider themselves welltrained or that training is available on the net.

Most yes are not very strong yes.

If developers were to be awarded special prizes by the Board, would you prefer to receive money or hardware?

• Money : 6
• Books or online subscription : EZA

Note: my suggestion was to provide all frequently contributing technical folks with a modest fixed allowance for technical study materials, not as a price for a tendered job (!), for instance an oneline subscription to e.g. http://safari.oreilly.com/ Erik Zachte

• Hardware : 2
• Money or donated hardware : 1
• Money (perhaps to give it back to the foundation) : 1
• if good hardware (prices) by the WMF, then hardware, otherwise, software.

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
  • sub-task #1 : installation under windows
  • sub-task #2 : skin documentation
• Task #2 : database shema
  • sub-task #1 : new proposition
  • sub-task #2 : MediaWiki code migration
  • sub-task #3 : migration tools
  • sub-task #4 : code testing (Has)

Documentation should be my commitment (answer technical questions on info@wikipedia.de) : Tom

Answer questions on #wikimedia. (sorry... I lost the name of this one :-()

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)

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): 4
• 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) : 4

• 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
• Clean up of code : 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
• Ease of customization : 1
• Easy mirroring worldwide for safer data : 1

• Clean refactoring and rewrite : 1
• documentation for site admins and clarifying comments in

the code for people tweaking the code or writing extensions : 2

• Fixing bugs from sourceforge bug list : 2
• 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
• Special import and other things
• Writing codes rather than doing server admin.

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
• motivation

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) : 2
• 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)
• The new developer should have an idea of what he wants to do

Was there anything in particular that you found helped you to join in?

• CVS access : 2
• Wikitech : 1
• IRC : 5
• Knowledge of english : 1
• Php: Has
• Working on specific (defined) issue : 1

Are you proud of what you are currently doing?

• Yes : 8
• Sometimes : 1
• Not really : 1

Do you feel your work is undervalued or under-recognized?

• No : 7
• 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).
• "Virtue is its own reward" but I like other things too. Being told we're doing a good job is _nice_. Getting a few dollars on PayPal is _nice_.
• Possibly money, but mostly helping getting good references

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 : 6 (3 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 :5 (call for tender) - but not all are sure it would work
• C : 1
• 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 : 5 (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) (the team is too small, it will always be the sames)
• 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 : 5 (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 : 6 (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 : 6
• 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 : 8 (probably wont have much effect -
• D : 3 (normal people would not understand) (I fear newbies not knowing what to do)
• 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 : 6 (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 : 1
• D : 0
• E : 1 (this 1 is german...)

9. A big clean up of the development pages on Meta, and clearer paths to help new developers to "jump in".

• A : 4 (1 especially extended documentation for the software)
• B : 7
• 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 : 4
• A/B : 1
• B : 5 (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 : 4
• 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
• Not now : 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 : 7
• Externally : 6

Why externally : general answer is "to avoid tensions"

Why internally : general answer is "we have the capabilities among us"

Interesting and summarizing comment : External hiring risks culture clash and non-acceptance from the volunteers. Internal hiring will get a known quantity, and also is likely to fetch lower rates since we're already stupid enough to do this for free. ;) Some people have expressed the opinion that hiring an existing volunteer will merely shuffle priorities rather than getting more work done, to which I have two reactions: first, it's *important* to shuffle priorities because some things really are more important (or are to the foundation). Second as volunteers we're holding down day jobs or going to school or just have other things to do; hired staff may be able to free up more time and more importantly has a requirement to work even when it _doesn't_ sound like fun. Things aren't always fun, and while we do put in a lot of work, reliability will get more important as time goes on and the stakes increase.

If the Foundation were hiring, would you consider applying for a development position?

• No : 7
• Yes : 2 (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 : 3 (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 (irc)
• Neutral : 2
• Neutral : 0 (irc)
• neutral/opposed : 2
• neutral/opposed : 3 (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
• people holding back for money

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
• Possibly yes : 2
• 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
• Increase : 1 (I would feel less pressure to worry about unpleasant

things (cost of work to me) if I knew someone else was going to do it. And who knows, I might want to do one of those things and get some $$$. :)

• No change : 1
• Undecided : 1
• increase for paid tasks, decrease for free tasks
• 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  :
• Would get things done at low expense : 2
• 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 : 2
• 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
• Spending money unecessary
• claims of corruptiont
• attraction of different types of people into development, which would

scare away other devs

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 : 3
• No : 1 (a link to my user page)
• Yes : 8

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 :7
• No : 1 Put a "give to wikimedia foundation" link instead :o)
• Not yet : 1

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 : 5
• No : 8

One mentions it would be hard to implement. Others consider themselves welltrained or that training is available on the net.

Most yes are not very strong yes.

If developers were to be awarded special prizes by the Board, would you prefer to receive money or hardware?

• Money : 6
• Books or online subscription : EZA

Note: my suggestion was to provide all frequently contributing technical folks with a modest fixed allowance for technical study materials, not as a price for a tendered job (!), for instance an oneline subscription to e.g. http://safari.oreilly.com/ Erik Zachte

• Hardware : 2
• Money or donated hardware : 1
• Money (perhaps to give it back to the foundation) : 1
• if good hardware (prices) by the WMF, then hardware, otherwise, software.

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
  • sub-task #1 : installation under windows
  • sub-task #2 : skin documentation
• Task #2 : database shema
  • sub-task #1 : new proposition
  • sub-task #2 : MediaWiki code migration
  • sub-task #3 : migration tools
  • sub-task #4 : code testing (Has)

Documentation should be my commitment (answer technical questions on info@wikipedia.de) : Tom

Answer questions on #wikimedia. (sorry... I lost the name of this one :-()

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)