[Foundation-l] Developer poll results
Anthere
anthere9 at yahoo.com
Wed Aug 25 17:09:41 UTC 2004
Possibly more readable on wiki :-)
here :
http://meta.wikimedia.org/wiki/Developer_payment_poll/results#Results_for_the_poll
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 at 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
More information about the foundation-l
mailing list