Upon reading other people comments, I think that we might have a dual solution for developers reward, which could be at the same time * just a thank you note * a mean to help them get a job, or just more traffic on a site they like * potentially, some money
As suggested in meta, first we could set a page on the wikimediafoundation website.
This page would be a list of all developers involved in wikimedia technical matters (if they want to be there *of course*).
Each developer name could be along with a short bio (or link to a personal website), and description of their most relevant activity in wikimedia as developers (everyday hardware maintenance, bug correction, mailing list handling, performance issues, software development, liaison with board etc...).
Each developer could put here a proeminant link for donations (paypal system).
=> This would help for developers development recognition (as many development activities are just invisible to most editors), and give them opportunity to advertise this for ousiders. They might also get some donations from editors who appreciate their
Second, once a year, we could have a couple of special awards for developers. I was thinking of for example : * award for hardware maintenance or improvement * award for software development * special award to thank a special dedication to some features recommanded by the board.
These awards could be heavily advertised and of course, proeminently announced on the wikimediafoundation website. They might also result in a little gift (such as money or hardware for example). Hardware gifts might be gifts offered to the foundation by hardware corporations.
It might be nice that this is the opportunity to thank people who put a lot of time in some activities, which are not very visible.
What do you think ???
__________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail
Anthere wrote:
Upon reading other people comments, I think that we might have a dual solution for developers reward, which could be at the same time
- just a thank you note
- a mean to help them get a job, or just more traffic
on a site they like
- potentially, some money
As suggested in meta, first we could set a page on the wikimediafoundation website.
This page would be a list of all developers involved in wikimedia technical matters (if they want to be there *of course*).
Each developer name could be along with a short bio (or link to a personal website), and description of their most relevant activity in wikimedia as developers (everyday hardware maintenance, bug correction, mailing list handling, performance issues, software development, liaison with board etc...).
Each developer could put here a proeminant link for donations (paypal system).
Hello,
I like this idea. The community will know who is behind the mediawiki software. Maybe we should set up a template to be filled by developpers like:
Name (nick): Country: Activities: Bio:
Second, once a year, we could have a couple of special awards for developers. I was thinking of for example :
- award for hardware maintenance or improvement
- award for software development
- special award to thank a special dedication to some
features recommanded by the board.
These awards could be heavily advertised and of course, proeminently announced on the wikimediafoundation website. They might also result in a little gift (such as money or hardware for example). Hardware gifts might be gifts offered to the foundation by hardware corporations.
It might be nice that this is the opportunity to thank people who put a lot of time in some activities, which are not very visible.
In the case a developper is tired of "working for nothing" that might give him a boost, maybe set it twice per year.
I personally doesn't need to get any reward although I will certainly reward gwicke for his monobook skin.
Don't forget lot of important works aren't seen by users like all works wich is done on servers or deep in the MediaWiki engine.
Anthere wrote:
Second, once a year, we could have a couple of special awards for developers. I was thinking of for example :
- award for hardware maintenance or improvement
- award for software development
- special award to thank a special dedication to some
features recommanded by the board.
Depending on the details of this, I am afraid this could turn out rather detrimental. I don't know about others, but I know I wouldn't even begin to get involved in the development if it takes a ridiculous amount of dedication just to be recognised. (Not saying it would actually -- but if these awards are displayed prominently, it would make that impression.)
Timwi
Timwi wrote:
Anthere wrote:
Second, once a year, we could have a couple of special awards for developers. I was thinking of for example :
- award for hardware maintenance or improvement
- award for software development
- special award to thank a special dedication to some
features recommanded by the board.
Depending on the details of this, I am afraid this could turn out rather detrimental. I don't know about others, but I know I wouldn't even begin to get involved in the development if it takes a ridiculous amount of dedication just to be recognised. (Not saying it would actually -- but if these awards are displayed prominently, it would make that impression.)
Timwi
Hmmmm, Timwi.
If we had *only* developers having a *ridiculous* dedication to the project, working on it perhaps 15 mn per week at most, releasing totally crappy new features, ugly skin, or if the servers were down 2 hours per day, I agree we would have to nominate three people for *ridiculous* involvement. And it would be very detrimental to say them thank you for their so-low involvment.
If they were SO bad and SO lazy, I even tend to think they would not deserve even 2 cents bounties :-)
I have good news ! I am convinced there are *more* than 3 people who *really* deserve to be proeminently thanked. So let's agree to judge propositions for what they are, and to consider by default that our developers are great guys, okay ?
Anthere wrote:
Timwi wrote:
Anthere wrote:
Second, once a year, we could have a couple of special awards for developers. I was thinking of for example :
- award for hardware maintenance or improvement
- award for software development
- special award to thank a special dedication to some
features recommanded by the board.
Depending on the details of this, I am afraid this could turn out rather detrimental. I don't know about others, but I know I wouldn't even begin to get involved in the development if it takes a ridiculous amount of dedication just to be recognised. (Not saying it would actually -- but if these awards are displayed prominently, it would make that impression.)
Hmmmm, Timwi.
If we had *only* developers having a *ridiculous* dedication to the project, working on it perhaps 15 mn per week at most
I meant the other kind of ridiculous. Ridiculously much. Perhaps 6 hours per day.
Timwi
Timwi wrote:
Anthere wrote:
Timwi wrote:
Anthere wrote:
I meant the other kind of ridiculous. Ridiculously much. Perhaps 6 hours per day.
Timwi
Ahhhh. Oki. Understood. Well... having one's name in a hall of fame is not so bad :-) Even for an editor it takes a *ridiculous* amount of dedication to get one of the very very very few reward which are currently so scarcely distributed. I see not where is the difference. Well, Timwi, I think having at least recognition is one way to thank people, because this is one of the thing that please *some* people. And I guess it is less controversial that *paying* people as a mean to thank them.
This discussion is a big waste of time. If somebody wants to provide bounties, they should put their money where there mouth is and say what they want done and what they're willing to pay for it -- either there will be bites or there won't.
Sheldon, has anyone taken you up on your offer to pay for some enhancements to login creation/verification?
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
If somebody wants to provide bounties, they should put their money where there mouth is and say what they want done and what they're willing to pay for it -- either there will be bites or there won't.
There is nothing wrong with wanting to centrally organise these offers, nor is there anything wrong with allowing the community some say over what the Wikimedia Foundation itself should offer.
Timwi
Timwi wrote:
There is nothing wrong with wanting to centrally organise these offers, nor is there anything wrong with allowing the community some say over what the Wikimedia Foundation itself should offer.
Wake me when the discussion becomes substantive rather than speculative.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
Timwi wrote:
There is nothing wrong with wanting to centrally organise these offers, nor is there anything wrong with allowing the community some say over what the Wikimedia Foundation itself should offer.
Wake me when the discussion becomes substantive rather than speculative.
I think it necessarily has to be somewhat in the subjunctive - "if the Foundation were to spend money on software development, how should it go about that?" Right now the discussion is like a bunch of staffers in the West Wing kicking around ideas, looking for something good enough to take to the boss.
One thing that I think people have danced around is who's motivated by what. If someone can't afford to do a piece of work for free, but will do a great job for $500, they're not being evil or immoral; that person has just put a price tag on their time. It's then up to the Foundation to decide whether it wants the work badly enough to pay up, or to wait for somebody to donate their time.
It seems like it would be easy enough for the Foundation to put up a list of wanted features with approximations to how much they're willing to pay. The harder part is to negotiate for the work; the more-capable people might charge more, but going cheaper could result in an encyclopedia trashed by bad coding. But fundamentally it's the same process as negotiating for hardware.
Stan
On Tue, 27 Jul 2004 14:10:16 -0700, Stan Shebs shebs@apple.com wrote:
It seems like it would be easy enough for the Foundation to put up a list of wanted features with approximations to how much they're willing to pay.
I think the first step should be: put up a list of wanted features, period, and advertise it, without the bounty system. Bounty can always be added later.
Currently, as I percieve it, one of the barriers to entry for new developers is not knowing what to work on.
Yes, I know there's a bug system and I know there are wiki page that list a lot of ideas on what can be done. But those things are chaotic and unprioritized i.e. looking at them I don't really know which bugs/features are regarded as highly desirable and which ones are just blue sky ideas that wouldn't even be accepted into CVS when done.
What is missing is a farily short (say <10 items at any given time), prioritized list of bugs/features that are known to by highly desirable/high priority but not done. At least I'm not aware of such list.
This list could be done now, without waiting for the outcome of the bounty discussion. It's a pre-requesite to a bounty system anyway and in my opinion that's something that has a chance to help and carries no risk (except of time spent by an individual who knows what those tasks are to prepare this list, publish it somewhere, evangelize and maintain up-to-date (assuming that it works and things from those list get implemented)).
Krzysztof Kowalczyk | http://blog.kowalczyk.info
Krzysztof Kowalczyk wrote:
On Tue, 27 Jul 2004 14:10:16 -0700, Stan Shebs shebs@apple.com wrote:
It seems like it would be easy enough for the Foundation to put up a list of wanted features with approximations to how much they're willing to pay.
I think the first step should be: put up a list of wanted features, period, and advertise it, without the bounty system. Bounty can always be added later.
Currently, as I percieve it, one of the barriers to entry for new developers is not knowing what to work on.
Yes, I know there's a bug system and I know there are wiki page that list a lot of ideas on what can be done. But those things are chaotic and unprioritized i.e. looking at them I don't really know which bugs/features are regarded as highly desirable and which ones are just blue sky ideas that wouldn't even be accepted into CVS when done.
What is missing is a farily short (say <10 items at any given time), prioritized list of bugs/features that are known to by highly desirable/high priority but not done. At least I'm not aware of such list.
This list could be done now, without waiting for the outcome of the bounty discussion. It's a pre-requesite to a bounty system anyway and in my opinion that's something that has a chance to help and carries no risk (except of time spent by an individual who knows what those tasks are to prepare this list, publish it somewhere, evangelize and maintain up-to-date (assuming that it works and things from those list get implemented)).
Krzysztof Kowalczyk | http://blog.kowalczyk.info
I agree :-)
Krzysztof Kowalczyk wrote:
I think the first step should be: put up a list of wanted features, period, and advertise it, without the bounty system. Bounty can always be added later. [...] Yes, I know there's a bug system and I know there are wiki page that list a lot of ideas on what can be done. But those things are chaotic and unprioritized i.e. looking at them I don't really know which bugs/features are regarded as highly desirable and which ones are just blue sky ideas that wouldn't even be accepted into CVS when done.
Of course, if we had BugZilla instead, this would be trivial. With BugZilla, you can give each bug a priority, and then you can directly link to a list of all bugs with a given priority. This is just an example; there are hundreds of thousands of ways of cataloguing/categorising bugs in BugZilla.
Maybe instead of the Bounty system, I should volunteer to help install BugZilla on Wikimedia instead?
Currently, as I percieve it, one of the barriers to entry for new developers is not knowing what to work on.
That's certainly a part of it, too, yes. If we set up BugZilla and find that it was a miracle cure, there will no longer be a need for payments and rewards.
What is missing is a farily short (say <10 items at any given time), prioritized list of bugs/features that are known to by highly desirable/high priority but not done. At least I'm not aware of such list.
Of course, it would be easy for the People In Charge™ (Board of Trustees, say) to make sure that the number of bugs with top priority is kept at a certain maximum, and the direct link I mentioned above will always be valid.
Timwi
Timwi wrote:
Of course, if we had BugZilla instead, this would be trivial. With BugZilla, you can give each bug a priority, and then you can directly link to a list of all bugs with a given priority. This is just an example; there are hundreds of thousands of ways of cataloguing/categorising bugs in BugZilla.
Maybe instead of the Bounty system, I should volunteer to help install BugZilla on Wikimedia instead?
I'll point out that you *can* set priorities on bugs in the SourceForge bug tracker and sort the list by priority.
However Bugzilla isn't a bad idea; I've seen some nicer-looking Bugzilla installations around (Gnome's and Red Hat's are fairly pleasant), and there are some problems with our current setup that could use fixing. Our servers don't fall over quite as often as they used to, so I'm not too worried about eggs-one-basket syndrome.
Things that should get solved with the bug tracking:
1) Clear, easy searching. While you can search on SF, it's kind of difficult and non-obvious. We get a *lot* of duplicate reports, and the easier it is to make people search first, the fewer we have to wade through.
2) Login integration with the wikis. A lot of people just don't leave a way to contact them or just leave a WikiName without logging in for the system's e-mail reports, and it's hard to get more information back from them about hard to reproduce bugs. We could force people to log in to SF before reporting, but this is an additional pain in the ass. If peoples' wiki logins could carry over more or less automatically this would be very helpful.
3) Cross-linking. Bugzilla's hyperlinks in the comments are a big help; we could add an interwiki setup to link more easily from the wikis to bug reports as well. Marking duplicates in Bugzilla is also a lot easier.
The main other issue is just getting people to keep up with the reports. This is grunt work, unfortunately.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
- Login integration with the wikis.
Hm, how would that work? BugZilla login names are e-mail addresses.
But if you have an idea of how to do this, I'd be very pleased to hear!
The main other issue is just getting people to keep up with the reports. This is grunt work, unfortunately.
What exactly do you mean by that?
If you mean monitoring a Wikipedia (or Meta-Wiki) page for bug reports and carrying them over to BugZilla, I'll volunteer to do that.
Timwi
Timwi wrote:
Brion Vibber wrote:
- Login integration with the wikis.
Hm, how would that work? BugZilla login names are e-mail addresses.
But if you have an idea of how to do this, I'd be very pleased to hear!
Many wiki user accounts include e-mail addresses, and they already have passwords.
Hypothetically, Bugzilla's authentication could be extended to use different usernames (ie 'eo:Brion VIBBER'). I don't know how closely it's tied to using e-mail addresses in the front-end, so that might be too difficult.
The main other issue is just getting people to keep up with the reports. This is grunt work, unfortunately.
What exactly do you mean by that?
If you mean monitoring a Wikipedia (or Meta-Wiki) page for bug reports and carrying them over to BugZilla, I'll volunteer to do that.
I mean reading them, assigning priorities to them, claiming them, clearing out duplicates, fixing them, and clearing them out once they're fixed.
-- brion vibber (brion @ pobox.com)
Stan Shebs wrote:
Brion Vibber wrote:
Timwi wrote:
There is nothing wrong with wanting to centrally organise these offers, nor is there anything wrong with allowing the community some say over what the Wikimedia Foundation itself should offer.
Wake me when the discussion becomes substantive rather than speculative.
I think it necessarily has to be somewhat in the subjunctive - "if the Foundation were to spend money on software development, how should it go about that?" Right now the discussion is like a bunch of staffers in the West Wing kicking around ideas, looking for something good enough to take to the boss.
Well, I listen :-)
I hear that current situation is not efficient, and that bounty can make it more efficient.
So, I wonder what else could make processus more efficient (and already, several goog ideas have been thrown around by several people)
And I wonder if bounties would really make it more efficient as claimed.
I think it is perfectly correct some development would be speed up compared to others, because of the financial motivation to work on one task rather than another. So, in that sense, it would be more efficient.
There has been a lot say these days on how much efficient it would be. I guess it depends a lot on the developer himself. But I trust that generally, the job would be just as good.
However, success should not be measured only for its technical consequences, but its social as well. Consequences on the developer himself, who switch from the "we recognise your value", to "we appreciate you reached the value we had set". A Control somehow. Consequences on other developers, since some are strongly opposed to the principle, this might mean major dissension possibly.
Finally, consequences on the tissue of the community. I tend to think that most caritative organisations, one day or another, get some paid staff to get a few things rolling, while still very strongly relying on a full set of volunteers. I guess the balance to achieve makes this very difficult. And even more difficult for us, who are on the internet, so likely to receive many hours of help from volunteers. Compared to most organisations, we will not be able to define "paid as full time" and "volunteer as from time to time".
I think we all are giving very work, and we are numerous to give a number of hours hardly reasonable :-) The last thing we want is to alienate a set of the community for the "sake" of another group. The last thing I want to hear is, as an argument for bounties, "we should pay developers, because *they* give so much time and energy, that they really deserve it". Many arguments for bounties are good, but this one is just not. Because it immediately set a comparison with the other groups and instill the idea that developers give more time and more valuable time than others. This is a very bad idea. An editor without any software to edit with, is no one. A tech maintaining servers on which nothing is going on, is no one. A developer improving a software that no one is using, is no one.
We have different tasks, but all of these tasks are important. And for a body, spending 4 hours connected on the net, is 4 hours. So, the interest of using bounties should be balanced with both technical and social success.
One thing that I think people have danced around is who's motivated by what. If someone can't afford to do a piece of work for free, but will do a great job for $500, they're not being evil or immoral; that person has just put a price tag on their time. It's then up to the Foundation to decide whether it wants the work badly enough to pay up, or to wait for somebody to donate their time.
Yes, I also agree there is nothing immoral with that at all. This just reflects different personal needs.
It seems like it would be easy enough for the Foundation to put up a list of wanted features with approximations to how much they're willing to pay. The harder part is to negotiate for the work; the more-capable people might charge more, but going cheaper could result in an encyclopedia trashed by bad coding. But fundamentally it's the same process as negotiating for hardware.
Stan
Though there are some exceptions (such as perhaps setting up the dues system, which is likely to interest the foundation first hand), I think this should not be a top down decision.
It is not to the foundation to decide which features are the best. It is first to the editors and daily activity, to reveal needs. Then to developers to analyse the problems, and come up with propositions/solutions. Then to developers to estimate their solution (prerequisite, how many of hours, requirements, when could they take care of it, how much they would ask to do it...).
Depending on this information, the foundation might decide that apparently feature A is much more needed that feature B, and might use means to push development of this feature first.
On Tue, 27 Jul 2004 13:08:59 -0700, Brion Vibber brion@pobox.com wrote:
Sheldon, has anyone taken you up on your offer to pay for some enhancements to login creation/verification?
Are the details of what needs to be done for this thing are written down somewhere? I.e. if I wanted to contribute this code WikiMedia (to be clear: as an unpaid volounteer), how do I find out what exactly needs to be done?
Krzysztof Kowalczyk | http://blog.kowalczyk.info
How does the Parser recognize whether or not an article title containing a slash is a subpage or a normal top-level article?
For example [[Nip/Tuck]] (a U.S. television show) in Wikipedia does not generate an automatic "upward" link to the [[Nip]] article (which exists), as it would if it were a subpage.
Just curious.
Matthew Trump
Matthew Trump wrote:
How does the Parser recognize whether or not an article title containing a slash is a subpage or a normal top-level article?
For example [[Nip/Tuck]] (a U.S. television show) in Wikipedia does not generate an automatic "upward" link to the [[Nip]] article (which exists), as it would if it were a subpage.
There's a global setting for which namespaces to perform subpage processing in; article namespace is excluded.
-- brion vibber (brion @ pobox.com)
wikitech-l@lists.wikimedia.org