On Mon, Mar 30, 2009 at 09:17:54AM -0500, Olemis Lang wrote: > > On Sun, Mar 29, 2009 at 3:07 PM, Jeff Hammel <jham...@openplans.org> wrote: > > On Sun, Mar 29, 2009 at 12:18:30PM -0700, rupert.thurner wrote: > >> On Mar 29, 6:24 pm, Jeff Hammel <jham...@openplans.org> wrote: > >> > >> > The idea occured to me to setup a trac with bounties for plugin and > >> > other development work similar to RequestAHacks on trac-hacks but for > >> > paid work. While I'd love to do this...probably not right now as I > >> > don't have much free development time (although I could be persuaded). > > > > Just to throw out some things that have been going around in my head: > > > > * auction style bidding and back-room discussions should be discouraged > > > > * a potential client should post the desired hack (or a roadmap, if there > > is more than one phase) with a time-frame and the amount they are willing > > to pay. > > > > * once a client approves a developer for work on a project, the plugin is > > no longer open for others to work on > > > > Instead of thinking about reinventing the wheel ... why not to look > for a working example ?
Such as? This isn't reinventing the wheel, this is taking what I've observed on other sides as applied to the current needs. > > * is the resulting work open source? I would heartily say "yes", but I > > know there are different opinions on the matter. As far as I'm concerned, > > the client is paying for a solution to a problem, not for the software > > license. If it is useful to others, it should be publically available for > > the good of the Trac community > > > > +1 for FOSS ... the buyer should be paying for the seller time > dedicated to building the plugin they need ... and for customizing it > so as to meet further specific reqs demanded by the buyer ... > > > * the spec should be as precise as possible, though obviously several > > passes at discussion will probably usually be necessary to refine what > > exactly are the deliverables > > > > IMHO this should be left to the parties to be considered ... once they > agree, deal is done ... Yes, but, if the spec is vague like "build a mailing list for Trac", then the scope can be whatever. If I petitioned to build such a plugin, and someone else petitioned to do such a plugin, we might have different ideas on what could be done. Maybe my solution is hacky. Maybe their solution is elegant. Maybe my solution doesn't fit the client's needs at all. So I don't think this should be negotiated behind closed doors and in fact I would encourage only taking petitioners once something precise is left in place. This is for the protection of both the developer and the client to make sure they're on the same page. > There *MUST* be rules to clearly arbitrate interactions between > bidders and sellers ... control & infrastructure for delivering > payments ... and many other related issues ... Ideally yes, but I don't think anyone has the time and money to setup such an infrastructure. > ... so I insist, why not to use an already existing working site for this ... > ? > Such as? > > * needless to say, any sort of infrastructure is a means of connecting > > client and developer and it is up to THEM (not to this list, not to > > as-yet-nonexistant web site, etc) to ensure the contract is fulfilled. > > In case of conflicts this should be handled by an arbitration board > ... if a serious approach is to be followed ... ;) Again, this seems to involve resources beyond that which are available. > > In other words, no real legal protections are given, though of course if > > someone faults another person then the victim will probably want to note > > this in public forum. > > > > This doent help ... sellers dont want to waste their time and buyers > dont want to throw out their money ... ;) But this already occurs, it just occurs when (e.g.) people show up to #trac and ask for paid development on a plugin and they negotiate via private messages. I'm not ready to tackle the be-all-end-all of software bounties. I am ready to setup some infrastructure which is better than our no-infrastructure. > > * is post-install support required? can clients pay for installation/setup > > work? How many bugs and support hours are asked per hack? What quality > > assurance is required? > > > > This should be left to the parties to decide ... IMHO ... Indeed, but it should be noted that this is explicit. In my experience, clients often think they get free support. Naive, I know. > ... but I still think that there are enough general purpose (I mean > Trac and beyond ;) sites for doing this ... I am not sure about using > yet another one ... that doesnt even meets the barely minimal reqs ... Such as? > However if someone ever does something like this, and meets the barely > minimal reqs ... well that'd be fine ... ;) > > -- > Regards, > > Olemis. Jeff --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to trac-users@googlegroups.com To unsubscribe from this group, send email to trac-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/trac-users?hl=en -~----------~----~----~----~------~----~------~--~---
