On 03/07/2012 01:13 PM, ext [email protected] 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
