RFC: Best Way To Track Bounties #25062

issue Rspigler openend this issue on May 4, 2022
  1. Rspigler commented at 2:52 am on May 4, 2022: contributor

    I have in the past set bounties for a few issues, just in the title of the thread. This doesn’t work very well, because there is no (central) way for a developer to search for the bounty, or keep track of them. @Bosch-0 brough up https://bitcoinbounties.org/ but I’m not sure if we want to rely on a third party site, that lists other projects.

    I thought maybe a new label for bounties could be a good idea. @MarcoFalke wasn’t sure this was a good solution, and brought up here that we should discuss possible solutions in a separate issue.

    Any ideas?

  2. Sjors commented at 1:18 pm on May 10, 2022: member
    I think a label is reasonable. It makes bounties easy to find for those who care, and easy to ignore for those who don’t. Details about the bounty can go in the issue thread, or in the description if the author wants to.
  3. MarcoFalke commented at 1:45 pm on May 10, 2022: member

    One issue with a label (or any other metadata of this repo) is that it requires maintenance to keep the labels in sync with the countless external third party sites and resources.

    An alternative would be to create a third party meta resource (link list) for bounty related websites and bounties itself?

  4. michaelfolkson commented at 1:51 pm on May 10, 2022: contributor

    My two cents. I think the management, monitoring and labelling of bounties should be kept outside of the repo. At best they could serve as a distraction from already identified long term priorities of a particular contributor/reviewer. At worst disagreements over who deserves the bounties after a PR is merged are discussed in this repo or pressure is exerted to merge prematurely to claim a particular bounty.

    Although anyone is free to prioritize their work based on bounties (I have no problem with bounties if managed externally to this repo especially if it encourages more external contributions) there seems to be more than enough funding available these days for an existing contributor to focus on their long term priorities and not have their priorities swayed by bounties.

  5. Sjors commented at 1:52 pm on May 10, 2022: member
    For now we could just accept that a bounty may have been retracted, and not worry about deleting the label.
  6. MarcoFalke commented at 1:55 pm on May 10, 2022: member
    It also requires work to assign the label, not only to delete it.
  7. laanwj commented at 1:59 pm on May 10, 2022: member

    My two cents. I think the management, monitoring and labelling of bounties should be kept outside of the repo.

    Yes. Please keep funding initiatives separate and distributed. I have no problem with anyone putting up bounties to have certain things implemented, but please don’t leave it up to maintainers whether they should be paid out.

    I strongly object to any proposal to manage funds or funding as part of this github project.

  8. MarcoFalke added the label Brainstorming on May 10, 2022
  9. MarcoFalke added the label Upstream on May 10, 2022
  10. ryanofsky commented at 3:27 pm on May 10, 2022: contributor

    I think it would be nice to label bounties, but only if it requires no effort or involvement from repo maintainers. E.g. if bitcoinbounties.org wants ability to label issues on github, they should write a bot that syncs the labels and is incapable of doing anything else besides syncing those labels, and get permission to run it.

    (I also think this topic would be a lot more interesting if funding were offered for code reviews rather than code authorship, since that is the actual bottleneck on most feature development.)

  11. MarcoFalke commented at 3:37 pm on May 10, 2022: member

    (I also think this topic would be a lot more interesting if funding were offered for code reviews rather than code authorship, since that is the actual bottleneck on most feature development.)

    I think the issue is that it is often harder to review if someone reviewed the code than it is to review the code itself.

  12. sipa commented at 3:55 pm on May 10, 2022: member

    I’m fairly skeptical in general about the merit of bounties for development work in general. Even if it is aimed at more than writing code or getting code merged (such as doing review tasks) I feel it generally creates perverse incentives due to Goodhart’s Law. Historically at least, bounty programs haven’t really attracted much interest from competent people; that may have been due to how those programs have been run, but it contributes to my skepticism.

    Of course I don’t mean to discourage anyone from offering funds for development is whatever way they seem fit, but I’m very wary about it adding additional work for the maintainers and contributors here.

  13. ryanofsky commented at 4:00 pm on May 10, 2022: contributor

    I think the issue is that it is often harder to review if someone reviewed the code than it is to review the code itself.

    I think this mostly depends on your reviewing style. If you write reviews like shaavan’s https://github.com/bitcoin-core/gui/pull/581#pullrequestreview-943855841, or just post meaningful comments and questions that are not about code style, it is possible to demonstrate thoroughness of your review if you want to do that.

    Of course figuring out utility of bounties is not really the issue here. This issue is only about labeling. I think everybody agrees that repo maintainers should have nothing to do with tracking bounties, unless they want to track bounties as a side-hobby.

  14. Rspigler commented at 10:41 pm on May 10, 2022: contributor

    I offer bounties to help this community, not hurt it. I now agree that this should not be apart of this repo.

    (I also think this topic would be a lot more interesting if funding were offered for code reviews rather than code authorship, since that is the actual bottleneck on most feature development.)

    My bounties reward reviewers as well just for this reason.

    I feel it generally creates perverse incentives due to Goodhart’s Law.

    One of my first posted bounties for multisig specifically addressed this: “I am not trying to influence consensus (this should just be wallet code), and ultimately it is of course up to the developers and the community if these are changes that are good for Bitcoin, and if the above is how it should be implemented. I am just trying to put all the thoughts/discussions down in one place.”

    If there are any other ideas on how bounties can better utilized, please let me know.

  15. Rspigler commented at 2:11 am on May 11, 2022: contributor
    https://nydig.com/bounties Seems really cool!
  16. fanquake commented at 8:35 am on August 8, 2022: member
    I’m going to close this issue for now. I think it’s fairly clear that this repository, and it’s issue tracker isn’t the right place to track bounties or similar, and there isn’t a need for us to provide any special labels to do so.
  17. fanquake closed this on Aug 8, 2022

  18. bitcoin locked this on Aug 8, 2023

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-11-21 09:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me