Loading...
 
Skip to main content

Development

Forum List Topic List

Forums » Development » Tiki Bounty System
 
Thread actions
Print this page
  • Print all pages

    • Tiki Bounty System

    Posted by nyloth posts: 5 ☆ ☆

    Hi all,

    Like many other open source projects, I think we should add a bounties system
    to dev.tw.o (for those who want to use it, which need to have no impact on
    others).

    Facts are :
    - Many people are using tikiwiki and they have many needs. Some of them (and
    I'm convinced they are quite a lot) may be able to pay for those needs to be
    developped,
    - Many developpers need funds to invest them more in tikiwiki,
    - It's not so easy, for the moment, for those two groups of people to
    contact each other,
    - Many developments are done in different companies or organizations but are
    not send back to the community. This is not a problem, but It would be better
    if we could convince more people that it is better for us and for them to
    share new feature developments, since they will benefit from the existing
    community (bug fixing, compatibility with code evolution, etc.)

    We could greatly benefit from bounties. For example, this may :
    - show that more and more companies are involved in tiki development and
    have some budget for it (which is something important for many companies when
    choosing a product),
    - motivate some developpers and convince new developpers to join our
    community,
    - more quickly reduce our bug and wish list

    Xavi has already done a wiki page to put some bounties there, but :
    - Wiki is not, IMO, the right tool to handle bounties,
    - Not enough developpers are aware of this page,
    - It will probably not really start / work unless we really promote bounties
    (e.g. a link to something like bounties.tikiwiki.org , on tw.o portal ... or
    at least something accessible from tw.o or dev.tw.o menus)

    Sylvieg also reported to me that Bitweaver has a bounties system (
    http://www.bitweaver.org/wiki/Bitweaver+Bounty ) that is not very active, but
    I think this may be because they don't have a huge enough community and user
    base, unlike Tikiwiki.

    There is some websites that are specialized in bounties
    (bountycounty.org, ...), but my proposition is to have our own system, begin
    with something really simple (better have something simple than nothing) but
    more adapted than a wiki page.

    I think we could now :

    - Use our own trackers to manage bounties :
    * either in dev.tw.o, by adding new fields to our 'Tiki Tracks' tracker,
    * either in a new bounties.tikiwiki.org tracker

    - Promote bounties (see above : link on tw.o, ...)

    If the choice is made to use our trackers, we could use existing data types
    ('Feature request', 'Bug', ...) or add a new data type "Bounty".

    Comparing to what we already have with our dogfooded tracker buglist, this is
    what I propose to add :

    - Sponsor (company, organization, ...) [text input][S],
    - Proposed amount (in dollars only, for the moment ?) [text input][S],
    - Deadline for developpers to make a bid [date][S],
    - Deadline for the development to be done [date][S],
    - "Current bids" + ("My bid" [text input] OR "Accept bid" [radio]) [A],
    - Additionnal comments for sponsor [textarea input][S],
    - Additionnal comments for developper [textarea input][D]

    [S] : sponsor editable field only (could be different from the one who
    submitted the request ?)
    [D] : developper editable field only (by the developper mentionned
    in "assigned to")

    [A] : editable by everyone for his own proposal (except the sponsor). For each
    one who made an offer in his "My bid" text input, it will be appended to the
    auto-generated list of "Current bids", which will be shown above "My bid".
    The sponsor will not have a "My bid" text input, but radio buttons available
    just after the end of the "Deadline for developpers to make a bid" to choose
    one of the current bids (or to choose no bid at all).

    [A] is, I think, the main point that will need some small developments to be
    done in tikiwiki code.


    I'm not in favor to handle money transactions through tikiwiki, and we have no
    paypal option for now. I think developpers and sponsors can simply contact
    themselves and choose together what fits them the best.

    Note that since some developments may be required, depending on how it will be
    implemented or not, it will probably not be available in 1.9.x ... and then
    not in dev.tw.o before 1.9.8 has been released.


    Comments and ideas are welcome. I'm volonteer to invest time to work with
    other interested people (sylvieg, xavi, marclaporte ... ?) on this project.

    Reads: 4791
    Posted by Nelson Ko posts: 44 ☆ ☆ ☆ Canada

    I have concerns on bounty system especially with some of the more detailed implementation methods you suggested below (see below for more info). This is not to say they can't be addressed through taking a more careful approach, though.

    These are my main concerns with a bounty system. Think of them as risks that must be managed with moving in this direction.

    Risk 1 : "Customers" with the most money may not be the best ones. They may be less loyal, or may push you in ways which are tangential to a broader base of users (which improve code testing), or more involved customers (in terms of contributing code/docs) and so on.

    Way to address 1: Must be careful not to enter slippery slope of letting money direct development. To do this, err on the side of caution - i.e. avoid institutionalizing money matters. Personal contracts between community members are sanctioned and even provided some free publicity like through page like this http://tikiwiki.org/tiki-index.php?page=TikiMarketPlace (or even something better), but not institutionalized.

    Risk 2: End up attracting developers that are interested more in money than in being part of a community, or developers who have little knowledge of open source ways. De-personalizing of relationships leading to community fragmentation.

    Way to address 2: We don't want some kind of impersonal bounty system. We want one where the people who are providing bounties and receiving bounty are part of the community and have commitment to it, not outsiders. We want people to be valued by their involvement, not for the money they bring.

    Now in response to nyloth's points.

    > - Many people are using tikiwiki and they have many needs. Some of them (and
    > I'm convinced they are quite a lot) may be able to pay for those needs to be
    > developped,
    >
    > - Many developpers need funds to invest them more in tikiwiki,

    Agree. Personal contracting is already being done. And I have also offered bounties but I only offer them to people I trust understand that money is not the most important thing.

    I suggest one of us can lead the creation of a Tiki developers network (TDN) with a website and identity separate from tw.o that can be linked to http://tikiwiki.org/tiki-index.php?page=TikiCommunity. The people will overlap across both groups, but the separation helps to address my concerns.

    > - Many developments are done in different companies or organizations but are
    > not send back to the community. This is not a problem, but It would be better
    > if we could convince more people that it is better for us and for them to
    > share new feature developments, since they will benefit from the existing
    > community (bug fixing, compatibility with code evolution, etc.)

    I do not think the bounty system directly addresses this, and may in fact confuse the issue. The way to tackle this problem is to have a separate section on a tw.o site for patches and users - the user community. This is more work, but I believe is worth the effort as a separate activity. No need to mix in the bounty system into this. Someone else could lead this, preferably a very advanced power user not necessarily a dev.

    > - show that more and more companies are involved in tiki development and
    > have some budget for it (which is something important for many companies when
    > choosing a product),

    This can be taken care of by the user community I mentioned above. We are not the "company-sponsored" type of open source project. We are more diverse - many smaller companies (like me) and self-employed joined together type. The information for who is involved as users should be available as part of the user community. As for bounties, that should exist on the TDN.

    > - motivate some developpers and convince new developpers to join our
    > community,

    External TDN website may help in this, to avoid risk number 2. It will also help provide better mentoring of new devs. e.g. The devs who are also in core and in TDN can identify new devs who have potential to be more involved in core. Open source projects scale only with concentric circles - we need more of these circles.

    > - more quickly reduce our bug and wish list

    We don't want to "bountify" bugs. Ironically, this might actually discourage bug fixing overall if people only fix bugs that are bountied.

    >
    > Xavi has already done a wiki page to put some bounties there, but :
    > - Wiki is not, IMO, the right tool to handle bounties,
    > - Not enough developpers are aware of this page,

    do a tracker on the TDN site (which I assume will run Tiki 😊 )

    > I think we could now :
    >
    > - Use our own trackers to manage bounties :
    > * either in dev.tw.o, by adding new fields to our 'Tiki Tracks' tracker,
    > * either in a new bounties.tikiwiki.org tracker
    >
    > - Promote bounties (see above : link on tw.o, ...)

    Once it goes beyond a wiki page, it will start to look institutionalized and slippery slope may happen. I strongly suggest TDN site be not on tw.o domain. Linking is less of an issue then.

    >
    > If the choice is made to use our trackers, we could use existing data types
    > ('Feature request', 'Bug', ...) or add a new data type "Bounty".
    >

    No. Not existing trackers, please.

    Finally, I am willing to help in this Tiki Developers Network site.

    Posted by nyloth posts: 5 ☆ ☆

    > I suggest one of us can lead the creation of a Tiki developers network (TDN) with a website and identity separate from tw.o that can be linked to http://tikiwiki.org/tiki-index.php?page=TikiCommunity. The people will overlap across both groups, but the separation helps to address my concerns.

    dev.tw.o may be a good place for this. And we already have the bugtracker there.
    I'm not against this proposition, but this implies much more work comparing to what I was suggesting...

    > > - Many developments are done in different companies or organizations but are
    > > not send back to the community. This is not a problem, but It would be better
    > > if we could convince more people that it is better for us and for them to
    > > share new feature developments, since they will benefit from the existing
    > > community (bug fixing, compatibility with code evolution, etc.)
    >
    > I do not think the bounty system directly addresses this, and may in fact confuse the issue. The way to tackle this problem is to have a separate section on a tw.o site for patches and users - the user community. This is more work, but I believe is worth the effort as a separate activity. No need to mix in the bounty system into this. Someone else could lead this, preferably a very advanced power user not necessarily a dev.

    In fact I was not precise enough.
    My idea was that the bounty system website could help to convince developpers to send back their tiki code to the community.

    Or, maybe, as for Horde project's bounties, we may have to establish some rules implying that a developper has to commit his code in the CVS and his code has to be well accepted in the community, in order to claim the bounty...

    Btw, the idea that you should already be tikiwiki developper (i.e. ou can commit on tikiwiki CVS) to make a bid for a bounty, seems me a good idea.

    > This can be taken care of by the user community I mentioned above. We are not the "company-sponsored" type of open source project. We are more diverse - many smaller companies (like me) and self-employed joined together type. The information for who is involved as users should be available as part of the user community. As for bounties, that should exist on the TDN.

    Ok with that.

    > External TDN website may help in this, to avoid risk number 2. It will also help provide better mentoring of new devs. e.g. The devs who are also in core and in TDN can identify new devs who have potential to be more involved in core. Open source projects scale only with concentric circles - we need more of these circles.

    Well... I personnaly have, as you, a huge preference to avoid impersonal bounties. This is why, as mentionned above, we may have to reduce the list of users that can make a bid to tikiwiki developpers. And this may be done for existing dev.tw.o trackers.

    But what you are suggesting is not only a bounty question. Your risk number 2 already exists without bounties. I think this is another topic to open if you want.

    > > - more quickly reduce our bug and wish list
    >
    > We don't want to "bountify" bugs. Ironically, this might actually discourage bug fixing overall if people only fix bugs that are bountied.

    You're completely right. In fact I should have written: "- more quickly reduce our wish list" 😉

    > do a tracker on the TDN site (which I assume will run Tiki 😊 )

    Ok for trackers. Not completely against TDN-specific website, but not convinced that dev.tw.o is not enough.
    My four main questions with a TDN-specific website are :
    - Why not benefiting from dev.tw.o trackers ?
    - Who will host it and pay for it ?
    - Who will adminitrate it ?
    - Won't people be loosed with all our *.tw.o websites ?

    For the first question, I can precise that people may want to sponsor an existing wishlist item send by someone who didn't want to pay for... With a new website, this sponsor may send a new tracker item on the TDN website. This may produce duplicated wishlist items (one on TDN, the other on dev.tw.o) or, worse (e.g. a developper that doesn't matter to be paid could not check TDN bounties and develop the wished item while another developper was trying to finish it to claim a bounty...)

    This is why I prefer to use only dev.tw.o (but I'm open 😉)

    > Once it goes beyond a wiki page, it will start to look institutionalized and slippery slope may happen. I strongly suggest TDN site be not on tw.o domain. Linking is less of an issue then.

    I don't that think slippery slope may happen with a simple link on tw.o portal ...

    > Finally, I am willing to help in this Tiki Developers Network site.

    Great 😊


    Posted by Marc Laporte posts: 1643 ☆ ☆ ☆ Canada

    Hi Nyloth,

    +1 to the general project.



    > Many developments are done in different companies or organizations but are
    > not send back to the community. This is not a problem, but...


    I think this is a big problem.
    "No problem should ever have to be solved twice. Creative brains are a valuable, limited resource. They shouldn't be wasted on re-inventing the wheel when there are so many fascinating new problems waiting out there."
    http://www.catb.org/~esr/faqs/hacker-howto.html#believe2

    With 450+ items on our wishlist, do we really want to waste resources?
    http://dev.tikiwiki.org/tracker5

    I have seen too many times where developers fix things and because they come or are invited too late to share their code, it ends up being too much work to merge and that code is effectively lost forever.

    I think Tiki is better than the average project to share code. However, I think we can do even better.


    The #1 point I want to address is "It's not so easy, for the moment, for those two groups of people to contact each other"

    Not so easy?

    It is outright difficult. Say a new user comes along (let's call him John), checks out the rated feature page (http://doc.tikiwiki.org/Features), tests TikiWiki and likes it. John concludes that Tiki is almost ideal for his needs but would like some improvements on feature X and Y. (which are rated C or D). John could work on it himself (he used to code a little), or he could have it done by someone working for him. But he thinks it would be much simpler/future-proof to hire whomever wrote that feature and work out something directly. Say John wants enhancements to the newsletter, he should first try to work something out with Sylvie who did that last major upgrade of that feature.

    With or without money, the interaction between users/power users and developers has historically been difficult. Why? Because unless you spend a lot of time with Tiki (on IRC, mailing lists, etc), you can't know who does what. The vast majority of other CMS/Groupware systems have a small core and most of the features are available via a 3rd party module system. It makes it very easy to identify who works on what. I have a friend who is a "module developer" for Xoops. He routinely gets requests for enhancements and part of his growing business is funded by these. And he contributes these enhancements in the next version.

    Some open source projects have "maintainers". Again, it makes it easy to coordinate bugfixes, enhancements, bounties, etc.

    In Tiki, the only way to know who developed a feature is to know the file names of the features and checking the CVS history to see who worked on it. And for the untrained eye, it's not easy to know who did significant work on the feature vs some minor bugfixes.

    Some developers will be happy to get feedback, bounties, etc about their features.
    Some developers wrote that feature a long time ago and are no longer active in Tiki (so don't want feedback)
    Some developers are still active but don't want feedback (too busy, etc)

    What concerns me: I am very happy that some people get paid to work on Tiki. Let's just keep an eye open for some botched code which answers the bounty (and the person gets paid) but since it's crappy code, someone else ends up cleaning up the mess later on. (unfinished features, difficult to merge up, etc) Being worried about this should in no way, shape or fashion slow down or hinder putting in place a bounty system. However, if ever we do run into problems later on, let's be proactive in the communication with the developer to make sure things are harmonious. (and we should be doing this, with or without bounties). In fact, the bounty system should encourage & promote the idea of harmonious code which will be part of the main Tiki distribution.

    I see the bounties as an extension of the wishlist. People can now vote on tracker items. Next step is to have a pledge system. I pledge $20 to solve this bug, etc. I favor using dev.tikiwiki.org, either extending current "Wishlist" tracker or adding another tracker which serves to add "meta-data" to current trackers. If we can't do within 1.9.x, then, it's a good reason to Dogfood 1.10 😊

    If it's on another site completely (to handle money, etc), I hope the technical information about the bounty are still on dev.tikiwiki.org, which should be the master wishlist for everyone helping Tiki become better. So it makes it easier for community members to comment/enhance/discuss a bounty.

    I am looking forward to reading everyone's ideas on this topic.

    Thanks!

    M 😉

    Posted by Nelson Ko posts: 44 ☆ ☆ ☆ Canada

    Before continuing, I do want to say I am +1 on the bounty system in principle. However the location bothers me.

    I would like to comment further on the advantages and problems of the following options (I am not saying that the problems cannot be addressed):

    1- attach to current wishlist tracker (bounties as direct extension of wishlist)

    Main advantage: visibility, integrated, can see bounty info at one glance.

    Possible problem 1: Some feature requests are very important from a code perspective, but not particularly attractive from a bounty perspective. The important stuff is left undone or delayed.

    Possible problem 2: Some feature requests are very important to the community (as reflected by the voting), but receive low bounty. Others are needed only by someone who happen to be rich (hence high bounty but low voting). This could get awkward.

    Possible problem 3: I think bugs should not be bountied. Even pledge of $20 to solve bug might cause crowding out of intrinsic motivation to fix bugs. This is my gut feel and also supported by economic theory that predicts crowding out. See http://www.slideshare.net/nice/crowding-effects-how-money-influences-open-source-projects-and-its-contributors/ By having all the bugs/feature requests and bounties together, the likelihood of crowding-out of intrinsic motivation could be very high.

    2- bounties on separate site (no information on bounties on dev)

    Advantage 1: The community has a stronger moral obligation to fix or add those requests that are not high bountied but still important. If you have the bounty information too close (using option 1), even if you don't say it, it might imply some kind of moral statement that bounty value is a good gauge of importance, which is not in many cases.

    Advantage 2: Developers who work on important but low-bountied items are perceived as more highly valued if bounty information is not on dev. Otherwise, it may look to the less enlightened viewer that less-well-bountied == less important which is totally not true.

    Advantage 3: There may be developers who prefer not seeing what others are earning all the time. It may be a distraction from their intrinsic motivation.

    Possible problem 1: Poor visibility leading to developers not knowing that there is in fact a bounty for an item. The good case would be that the dev does something important. The bad case is the nothing else is done.

    Possible problem 2: Too many sites, causing confusion.

    Possible problem 3: More work, more cost.

    3- bounties on separate tracker in dev (this is a compromise between the above 2 options)

    This helps to address the problems in option 1, but IMO, still insufficient. The "moral values" element concerns me deeply. I'm afraid we will give the impression that cash determines what's important, which is not true.

    I look forward to more comments and suggestions.

    Posted by Marc Laporte posts: 1643 ☆ ☆ ☆ Canada

    > Possible problem 3: I think bugs should not be bountied.

    If bugs are not bountied, what would be approximate volume of bounties would you expect from a new system?

    Ex.: number of active bounties when system is at maturity, or number of "awarded" bouties per year, etc. ?

    M 😉

    Posted by Nelson Ko posts: 44 ☆ ☆ ☆ Canada

    > > Possible problem 3: I think bugs should not be bountied.
    >
    > If bugs are not bountied, what would be approximate volume of bounties would you expect from a new system?
    >
    > Ex.: number of active bounties when system is at maturity, or number of "awarded" bouties per year, etc. ?
    >
    > M 😉

    Well, there are 428 items in the tracker now that are flagged Bug, Bug:Usability, or Feature Request. (about 60 in June, and 30 in July but July is only half gone)

    132 are Bug:Usability, and 182 are feature request. There are overlaps as stuff can be flagged in more than one section. Also, exactly what exactly is a bug or a feature request can sometimes be debatable. This could be a problem in "making bugs non bountiable".

    Anyway, even if we just take 182/428*60 = 26 feature request per month. If just 15% bountied, that would be 4 bountied per month. At maturity, the proportion will be much higher.... say 50% = 13 per month.

    Posted by Marc Laporte posts: 1643 ☆ ☆ ☆ Canada

    > Even pledge of $20 to solve bug might cause crowding out of intrinsic motivation to fix bugs.

    Would there be a pledge system anyway?

    Posted by nyloth posts: 5 ☆ ☆

    > 1- attach to current wishlist tracker (bounties as direct extension of wishlist)

    This option is clearly my prefered choice 😊

    I like the idea that everything is in one place, that you could offer a bounty for existing tracker items, etc.

    I dislike the idea that option 2 would also imply to manage another website, that we may have duplicated items, that people will be a bit lost


    > Possible problem 1: Some feature requests are very important from a code perspective, but not particularly attractive from a bounty perspective. The important stuff is left undone or delayed.
    >
    > Possible problem 2: Some feature requests are very important to the community (as reflected by the voting), but receive low bounty. Others are needed only by someone who happen to be rich (hence high bounty but low voting). This could get awkward.


    I'm sure we can find a solution to minimize or revert problems 1 and 2. We juste have to decide what to do, but there is a lot of solutions. For example, supposing we manage bounties in dev.tw.o tracker5, we could :

    - force the tracker to refuse bids from developpers for a bounty if there exists non-bounties tracker items that are more important

    - add information "need a sponsor" on some very important trackers items (automatically or not), in order to incite sponsors to pay for some important stuff, since they don't see only bounties but also this stuff. I agree that sponsors tend to pay only for visible functionnalities, but some of them are also ready to pay for important things to be sure that the product will be healthy and have a long life.

    - limit (by project admins ? by community votes ? by ) the list of developpers who can offer a bid / reply to a bounty to only those who often takes care of non-bounty items. There is also many solutions to manage this kind of short list : based on project admins decisions, based on firendship network, based on votes, based on the number of non-bounty tracker items already recently closed, ...


    We can even choose to implement more than only one of this kind of idea.

    Btw, if we suppose that we have a good system to affect priority to bugs that really reflects reality (through projects admins, main developpers, votes, ...), I then have a preference for the first example, since :

    - It's completely effort-less (i.e. automated),
    - It's not subjective,
    - We clearly impose that money is not the most important thing,
    - We may incite sponsors to help high priority bugs to be solved if they want their other less important developments to be done through the bounty system,
    - This does not privilege some developpers

    We may specify a more flexible rule. For example :
    - no bid accepted for bounties if there is higher priority tracker items of priority > 8,
    - no bid accepted for bounties if there is higher priority tracker items that includes bugs (not new features),
    - no bid accepted for bounties if there is higher priority tracker items, except if the bounty has a high vote score,
    ...


    > Possible problem 3: I think bugs should not be bountied. Even pledge of $20 to solve bug might cause crowding out of intrinsic motivation to fix bugs. This is my gut feel and also supported by economic theory that predicts crowding out. See http://www.slideshare.net/nice/crowding-effects-how-money-influences-open-source-projects-and-its-contributors/ By having all the bugs/feature requests and bounties together, the likelihood of crowding-out of intrinsic motivation could be very high.

    Ok, I agree with you on tha fact that we should avoid bounties for bugs.

    This has to be discussed (and marc to be convinced 😉 ), but this is not so related to the choice of dev.tw.o. You won't be able to avoid bounties offer for bugs in another website. Even if you have no 'Bug' category, people will be able to describe a bug as a new feature request.

    We can choose (if this is what we want), on dev.tw.o, to develop this system to be not usable / hidden for bug items.

    Posted by Nelson Ko posts: 44 ☆ ☆ ☆ Canada

    Some nice ideas nyloth. I like some more than others - need time to digest. Those that require a lot of rules I will avoid. Rules have the disadvantage of becoming stale over time and may become a construct to prevent the community from moving forward in future.

    I was going through the slide deck I linked to one more time and one thing stood out, which is the answer the the question "Who are we trying to attract with this?". The answer provided there is "People who are into the community long-term, not short-term". I think this is probably the most important consideration in how we design this.

    My original idea of separate site was based on the premise that in the event a lot of "short-term" types hang out there, at least there is a buffer between that and the goings-ons on dev.tw.o. It provides a filter, sort of, to reduce the noise level. On the other hand, I agree that a separate site may cause people getting lost and confused.

    Perhaps, we can start with a carefully designed system on dev that provides adequate filtering/hiding etc..., and where bounties will only apply to the development branch (unless it is a mod). The reason not to open it up to the stable branch (unless it is a mod) is because people who work on development branch and who sponsor development branch activities are by definition more "long-term". As for mods, they is already a well-defined separation which I think is adequate. What do you think of this?

    Posted by Nelson Ko posts: 44 ☆ ☆ ☆ Canada

    Or actually, I think even mods must work with the development branch to qualify for bounty. I think this focus on "long-term" is very important, and we want to make sure these mods don't lose support when version changes.

    > Perhaps, we can start with a carefully designed system on dev that provides adequate filtering/hiding etc..., and where bounties will only apply to the development branch (unless it is a mod). The reason not to open it up to the stable branch (unless it is a mod) is because people who work on development branch and who sponsor development branch activities are by definition more "long-term". As for mods, they is already a well-defined separation which I think is adequate. What do you think of this?

    Posted by Xavier de Pedro posts: 1817 ☆ ☆ ☆ Catalan Countries

    Hi: This is a nice, important (and long) discussion 😊

    I mostly agree with all comments, and I like the most nyltoh's suggested solutions for the possible problems exposed.

    Nevertheless, I want to extend the discussion for things not directly related with money, but related to the thread a problem behind:

    we need to improve the communication system between coders "willing to work on others' itches" (I take mose's term) and power users requesting bug fixing os suggesting/requesting feature enhancements. And maybe, the same way back: coders which don't find time for documenting or bug testing, and users (power users or simple new users who agree with the system) to work on those coder's itches.


    This could be helped through present tw features (Contribution and Action log):

    • When a RFE or bug fixing request is shown, the amount of voluntary work for the community (coding, bug fixing, bug reporting, documenting...) could be a "plus" criteria to be taken into account. Money should be a plus, but not the only motivation for coders to take care of bugs, documenting, feature enhancements... Another motivation could be to help others which help TW community.


    I like helping in bug reporting and documenting (when I find time for it, like in the last month) , since I felt this is one clear way to retribute back to TW community for the nice work done so far with the free software and community creation.

    So I've been intrinsically motivated to help and invest time to TW community (bug reporting and documenting), because I know many people did that before and I could benefit from that cooperative work. And this way, others can benefit also from my voluntary work. Moreover, I could benefit from teaching Tikiwiki usage, being paid from my Catalan local government to teach free software for people that can suffer from the digital divide in our society. And I earned quite a lot of money for the tim invested (the code was working, and I mostly worked to document it in Catalan).

    If I had known that TW was only created by paid coders on a paid job basis, as well as others being paid to document, mostly money-driven community, I guess I wouldn't have dedicated such amount of time to it in the last months, and least intensively, in the last years.... (answering forums support requests from time to time, and documenting a little bit from time to time). Why should I? But since I knew many people had contributed for free, so did I with my spare time.

    I think that something similar could happen with coders, when I (or others) submit bug reports or RFE with a high value of priority for my own opinion (for my own interest for the non-profit Tiki sites I admin). Coders might will to help back for free on their spare time, to non-paid contributors to TW community. And the coders which need to be paid (or when the coders neeed to be paid) for bug fixing, feature enhancing, etc., they would mainly take into account the possible bounties offered. I understand that some coders do their best to live on TW coding (which is very fair and compatible, at least, with free software development): we all have to pay bills, etc.

    As an example, Nyloth recently thanked to me and sylvie for reporting an issue/bug with a feature that nyloth very was concerned with (I guess 😊. I imagine that coders also want to give feedback to users who also give feedback to the community. Payed feedback, or quantity and quality of effort/contribution dedicated to improve TW community.

    So this measure of contribution size and/or quality should be taken into account (imho) in such an improved system (not only for payed bounties, but also to motivate community helpers to keep doing so).

    Btw, as mentioned above, we have such feature pretty ready in 1.10 (Contribution + Action log, for the basic features in Tiki: wiki, forums and comments, among others). And probably soon (several weeks, expected), on trackers also (thanks to sylvie, which accepted to work on that (payed job).

    So that, imagine that coders want to have people helping new users at TW community requesting help through the forums, and wiki page comments (and tagging that as "help request" through the contribution feature). Some users invest their time to help new users... They could use contribution feature to select that they were helping other users requests ("helping users", or at least attempting it).

    Total amount of number and size of such contributions of that type, could be shown also in the user's info mouseover box (not coded yet), as a valuable way to indicate the more common type of contributions of that user. And this information, when seen in dev.tw.o/tracker5 , could help coders to consider taking also this RFE or bug report into consideration (regardless of bounty offered for them or not). In fact, it could be a way to make it easier for people to decide to wheter work on others itches or not. (coders on power user's itches, documenters on coder's documenting itches, etc.)

    And this way, also, would promote users and coders with long term support for TW community...

    For the other issues stated in this thread:
    I would vote for the system in dev.tw.o (extending tracker5). I hate duplication of work, and making users be confused on too many places to send their comments, rfe, bug reports, etc.

    (I prefer to avoid having lists of wishes for possibly payed work (depending on estimation of expenses coders and our budget left) in many sites spread in different places...

    > We may specify a more flexible rule. For example :
    > - no bid accepted for bounties if there is higher priority tracker items of priority > 8,
    > - no bid accepted for bounties if there is higher priority tracker items that includes bugs (not new features),
    > - no bid accepted for bounties if there is higher priority tracker items, except if the bounty has a high vote score,
    > ...

    And I like a lot the idea of filtering who can claim for bounties, and when bounties can be claimed, in case they are set up, in the same line that nyloth suggested... (if karma feature was one, I would vote to increase all of you your karma! 😊

    Btw, a complementary measure to be shown in score info (shown in user's mouseover) is forum activity, and trackers activity.

    And of course, a way to show the numbers of bugs fixed by that users (using contribution feature on trackers, even if it's not coded yet). Sylvie would be automatically given the nice credit she deserves for her continuous work she does, as many of you also do (I know Sylvie's case the most; sorry, not that much your cases, yet 😊.

    > > Possible problem 3: I think bugs should not be bountied. Even pledge of $20 to solve bug might cause crowding out of intrinsic motivation to fix bugs. This is my gut feel and also supported by economic theory that predicts crowding out. See http://www.slideshare.net/nice/crowding-effects-how-money-influences-open-source-projects-and-its-contributors/ By having all the bugs/feature requests and bounties together, the likelihood of crowding-out of intrinsic motivation could be very high.
    >
    > Ok, I agree with you on tha fact that we should avoid bounties for bugs.

    I don't have a clear idea about this. I trust you all on what you decide (I do this "delegated voting..." suggested in http://vivarto.com/Nornorna 😊 .

    Well, my 2 cents...

    P.S.: Or maybe, we could make use of the Community Currencies system coded by mose a couple of years ago?
    http://cc.tikiwiki.org/Mod+Community+Currencies