4 ms·

Congrats on the launch! I see many potential use cases for this project: 1. As a developer, I have had customers paying me to contribute improvements to open

Congrats on the launch! I see many potential use cases for this project: 1. As a developer, I have had customers paying me to contribute improvements to open source projects they depend on, this case is very tricky because there is no guarantee that the upstream project will accept the change. 2. As a company, we have had the need for some improvements to our projects that we don't have time for handling, a platform like this could have helped us. On the other hand, I see some potential issues: 1. As a developer, it is hard to invest the time on a task when there is no guarantee for the payment, imagine I start investing 1 week in completing a bounty just to see someone else getting its PR merged before I finish mine, have you considered adding a locking mechanism? let's say, if I get the bounty assigned, I get up X time to deliver, otherwise, the bounty can go to someone else. 2. As a company, I'm not sure that many companies would be willing to commit to the 23% fee, maybe there is a way to structure this in a friendlier way? for example, taking a 20% fee up to $Y, even Upwork has a different % based on the amount paid by a company to a developer (staring at 20%, going up to 5%). 3. As a company, assuming a bounty can get locked to a dev, if I get many people interested in a bounty, how do I decide which one to pick? displaying historic data about devs could help. In any case, good luck! EDIT: I also haven't seen how a dispute would be handled, let's say, a dev sends a PR but a company rejected it but silently takes the code to use it. The inverse case could happen, a dev submitting low-quality work and demanding the company to pay.

irf1 4y ago
fantastic feedback, thank you so much for all your input AlexITC!! regarding the potential issues you noted: 1. developers get assigned by the maintainers/core-team so there is no duplication of effort, there are never multiple developers working on the same bounty. if there's no progress from the assignee, maintainers / other developers would check in and the issue would get reassigned, there is self-regulation. that being said, standardizing this process through a 'locking mechanism' is an interesting idea, we will think it through - thanks! 2. the sliding-scale fee model you are suggesting is an interesting idea, we'll think it through! if companies try bounties, are satisfied and would like to commit to a bounties budget, at the moment we offer the option to pre-pay fees at a discount. there's definitely room for experimentation here, thanks for your note! 3. great point, at the moment you'd evaluate people by looking at their github profiles and whether they've contributed to your project before (or other projects in your ecosystem). there's definitely room to improve that 'selection' process for maintainers. once again great point!
- AlexITC 4y ago
  > 1. developers get assigned by the maintainers/core-team so there is no duplication of effort, there are never multiple developers working on the same bounty I have read the website docs again and I can't find any reference to this or how the process work. As a company, I would hope to see more docs related to the business before trying it out, the docs assume that you are already integrating the bounties, there are even API docs (which are fine) but no clear definitions on dispute handling (these cases will occur sooner or later). > 1. As a developer, I have had customers paying me to contribute improvements to open source projects they depend on, this case is very tricky because there is no guarantee that the upstream project will accept the change. So far, my understanding is that this case is not supported, is there any plan for it? it is the most common I have been hired for. Thanks.
  - irf1 4y ago
    we will update our docs accordingly about the assignment flow, thank you for noting this AlexITC! regarding your last point, yeah this use case is very tricky, indeed there is no guarantee that the upstream project will accept the change. in fact, that project would need to have the algora app installed to begin with. that being said, we understand there is a pain point here, so we will note this down and seek additional feedback. we won't hesitate to reach out if/once there is a development here :) thanks so much once again for all your feedback!
goldfeld 4y ago
Regarding point #1, I also launched something that is the volunteer idea of the OP, or just a journal with weekly themes of projects needing help, some AI related. Investing the time in this case is simply a volunteering or not decision. [0]: (emacs week) https://news.ycombinator.com/item?id=35413940 https://news.ycombinator.com/item?id=35413940

irf1 4y ago

fantastic feedback, thank you so much for all your input AlexITC!! regarding the potential issues you noted: 1. developers get assigned by the maintainers/core-team so there is no duplication of effort, there are never multiple developers working on the same bounty. if there's no progress from the assignee, maintainers / other developers would check in and the issue would get reassigned, there is self-regulation. that being said, standardizing this process through a 'locking mechanism' is an interesting idea, we will think it through - thanks! 2. the sliding-scale fee model you are suggesting is an interesting idea, we'll think it through! if companies try bounties, are satisfied and would like to commit to a bounties budget, at the moment we offer the option to pre-pay fees at a discount. there's definitely room for experimentation here, thanks for your note! 3. great point, at the moment you'd evaluate people by looking at their github profiles and whether they've contributed to your project before (or other projects in your ecosystem). there's definitely room to improve that 'selection' process for maintainers. once again great point!

AlexITC 4y ago
> 1. developers get assigned by the maintainers/core-team so there is no duplication of effort, there are never multiple developers working on the same bounty I have read the website docs again and I can't find any reference to this or how the process work. As a company, I would hope to see more docs related to the business before trying it out, the docs assume that you are already integrating the bounties, there are even API docs (which are fine) but no clear definitions on dispute handling (these cases will occur sooner or later). > 1. As a developer, I have had customers paying me to contribute improvements to open source projects they depend on, this case is very tricky because there is no guarantee that the upstream project will accept the change. So far, my understanding is that this case is not supported, is there any plan for it? it is the most common I have been hired for. Thanks.
- irf1 4y ago
  we will update our docs accordingly about the assignment flow, thank you for noting this AlexITC! regarding your last point, yeah this use case is very tricky, indeed there is no guarantee that the upstream project will accept the change. in fact, that project would need to have the algora app installed to begin with. that being said, we understand there is a pain point here, so we will note this down and seek additional feedback. we won't hesitate to reach out if/once there is a development here :) thanks so much once again for all your feedback!

goldfeld 4y ago

Regarding point #1, I also launched something that is the volunteer idea of the OP, or just a journal with weekly themes of projects needing help, some AI related. Investing the time in this case is simply a volunteering or not decision. [0]: (emacs week) https://news.ycombinator.com/item?id=35413940 https://news.ycombinator.com/item?id=35413940