Nice idea for freelancers! Willing to help, but don't know how to bridge this to qt-project.
Cheers, Dhi Aurrahman 2012/3/16 <[email protected]>: > Sorry to toppost. > > To Peters concern about "Nokia", This idea of enabling patch bidding(or > 'bounties' as Quim calls it) might fall under the Qt Project umbrella, which > is distinct and separate non-profit organization and Nokia could not be > responsible for any activities between participants. I believe > facilitation or integration of bounties at some level by the Qt Project > infrastructure could actually be of real value to the community. I accept > some of Quim's points and agree that dealing with actual accounts/payments > must not be part of the Qt Project so lets push that to a 3rd party. I also > understand that theres no way to guarantee a merge – but I say I would say > it would encourage better quality in JIRA if payers expected clarity about > what they plan to pay for. The fact is that the farther away from the code > you go, the less streamlined and more cost is added to a development > effort. > > I know the proposition of integrating finances directly into open source > development is heresy but Im throwing it out here because I envision, if > done subtly, it could provide a catalyst for fixes and features and offer > interesting metrics back to the community(hey what value are votes?). It > could foster satisfaction in the Qt user community within the Qt Project > context instead of forcing organizations to translate needs into RFQ's, > manager speak, sales meetings, and other such cost generating overhead. It > would definitely reduce the barrier to entry for small efforts that might > never get done through a partner and thus encourage the Qt freelancer > community to be more dynamic and visible. Frankly, its more efficient and > keeps control closer to the developer level. In this sense it could add a > lot more than simply paying money for large scale development in the way > that formal engagement with partners currently works. > > I'll touch base with Peter directly on his ideas to get started but if > anyone else is interested please share your thoughts! > > Best Regards, > Adam > > > From: ext Peter Winston <[email protected]> > Date: Fri, 9 Mar 2012 18:24:04 -0500 > To: <[email protected]> > Cc: Adam Weinrich <[email protected]> > Subject: RE: [Marketing] Bidding for patches > > Hello Adam, > > This is a really interesting problem, it's great to hear you bring this up. > Getting this right would both turbo charge open governance, and developer > adoption. > and I’m ready to start! > > However, I understand Quim’s point that the commercial support aspects > (regardless of the mechanism) should be kept separate from qt-project. > Anything that Nokia does, runs the risk of being seen being an > “endorsement”. This is a great goal, but how far does Nokia want to > facilitating it. If you sitting between the customers, and the vendors, by > pooling payment, or validating a design, they your effectively putting > Nokia on the hook for its success. > > Still, I love the basic idea of building a market place that connects > customers with pain with vendors who can help them. > > I would be happy to brainstorm the issues with you. > > > > Cheers, > > > > -peter > > > > > > > > ---------- Forwarded message ---------- > From: Quim Gil <[email protected]> > Date: Thu, Mar 8, 2012 at 6:30 PM > Subject: Re: [Marketing] Bidding for patches > To: > > On 03/07/2012 01:13 PM, wrote: >> I've discovered that corporate Qt users sometimes have a need for their >> bugs or features they care about to be escalated and they are willing to >> pay for it. At the DD11 SFO Contributors Summit we had a discussion >> during the Qt Project Corporate Outreach session where we brainstormed >> about a bidding system to address the need for such one-off development >> work. >> >> A partner services engagement is one-to-one relationship with a high cost >> of entry. We could provide an alternative which opened up bidding on JIRA >> tasks to all, partners as well as freelance programmers. Maybe even >> multiple parties interested in a task could commit to pay what its worth >> to them and once the pooled amount is worth their effort a contractor >> agrees to do the work. >> >> I wonderŠ >> 1) How we could integrate this into the community workflow > > Does it need to be integrated? Why not keeping the Qt Project > infrastructure and workflow focusing on the development, leaving the > business motivations and organization aside? > > >> 2) How to assure trust and payment > > Using a 3rd party service. I don't see the Qt Project infrastructure > and the thin legal & accounting overhead having to take that responsibility. > > http://www.freelancer.com/ could be an option. Are there others? I'm not > an expert on this. > > > >> 3) How to deal with patches that are not approved to be merged. > > The Qt Project context offers a lot of flexibility on this, making > easier to merge good patches (while keeping away the rest, no matter how > much money someone is willing to pay for its merge). > > No bounty should come with a promise that the patch would be merged. The > reasons for patches to be merged or not are based in many factors and > this is what someone willing to see a patch upstream should look at. > > Let's look at the possible scenarios considering that there are > fundamentally two types of patches: bugfixes and new functionality. > Bugfixes are relatively simple to merge. You need: > > - A patch with proof of the bugfix. Without this you wouldn't get your > bounty anyway. > > - Needs to follow the contribution guidelines of the Qt Project and the > specific module (if any). This can be required in the bounty offer. > > - Needs to be reviewed and approved. This can be tricky if maintainers > are busy with other priorities or the module is basically unmaintained. > A sub-bounty for a reviewers / approvers to have a look? Nobody should > be able to buy an approval, though. If the patch is buggy or doesn't > follow the guidelines it will be rejected anyway. > > - If we are talking about new functionality it needs to be discussed > within the project in the first place. Is that functionality fitting in > the module roadmap? Is someone else working on this already? What is the > approach proposed for the implementation? > > - Note also that new features imply a new IPR risk that needs to be > assessed. Maybe a brilliant patch solves a problem for a specific > customer but puts in potential legal trouble the Qt Project and the > unaware users of that code. > > >> 4) How to get started > > Find the 3rd party service. Find a customer with money and bugs. Let's > try a pilot? > > > >> Is this something the community is up for or YOU want to get involved >> with? > > I see it as a nice "add-on" that the community can work around, more > than as something the Qt Project itself should take responsibility of. > At the end this is about paying money for development, which is no > different that what Nokia, Digia, ICS and others are doing already - > keeping their accounts and agreement out of qt-project.org. > > -- > Quim > > _______________________________________________ > Marketing mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/marketing > > > > > _______________________________________________ > Marketing mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/marketing > _______________________________________________ Marketing mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/marketing
