Bounty System

Feedback
,
1

Good evening all,

A short while ago the bounty system was disabled due to various reasons and I wanted to get some conversation/feedback from the Stash team as well as regular users on how we can:

A) Get it reinstated
B) Make it better than before so that it doesn’t get discontinued again

Myself, as a learning developer, love bounties as it gives me motivation to learn/create a feature. I believe it helps involve extra developers and can help relieve some strain from the main development team. I have been doing some work for StashApp recently but would love the opportunity to learn and then have it pay for a beer after the fact as a celebration

I know there are drawbacks in the form of management. People have to manage the bounties, money, and various other aspects that I’m sure I don’t know about. What were the pain points that caused the bounty system to be called off in the first place? Perhaps this would be a good place to discuss those and figure out a solution.

Hopefully we can figure out a plan to get this readded :slight_smile:

EDIT:
I wanted to throw some of my thoughts on potential fixes that might make things easier

Potential Fixes:

  • Force users to speak with Stash team prior to adding a bounty (unsure how to do this)
  • Allow bounties to be refunded after x times (3/6/9 months?)
  • Create a dedicated “Bounty Manager” role (Recommendation from Discord)
  • Create actual guidelines/documentation for bounties
2

I may be wrong here, but here goes …

From my non-coding perspective, the issue with free for all bounties were that they we getting piled up on ‘features’ that needed half the app to be rewritten for them to be integrated.

Then there was the pile on of expectation - ‘if I place a bounty on that one feature I want hopefully that’ll get bumped to the top of the list’ (Some of it was discord users pushing people to ‘put your money where your mouth is’!)

My idea would be to have a bounty pot, all bounties into one big pot. WP did some work on estimating size of projects/issues before which could tie in …

WP/Org Team can sit and estimate small wins and place bounties on those that others could pick up for a small reward.

As the pot gets bigger then ‘small remuneration’ in return for successful PRs can become a thing.

On a project this size I don’t think bounties per issue are fair on either the person placing money in expectation or on it becoming a stick to beat WP with.

TLDR: One big bounty pot, placed on issues as and when.

3

From my non-coding perspective, the issue with free for all bounties were that they we getting piled up on ‘features’ that needed half the app to be rewritten for them to be integrated.

I agree with you here. TECHNICALLY, people were supposed to have conversations with WP before putting the bounty in but quite a few people didn’t. This ended up bounties being placed on features that they shouldn’t have went on. I think something needs to be put in place that almost requires users to communicate prior to a bounty being placed. I’m not sure of how this could be done but it would solve a lot of that.

Then there was the pile on of expectation - ‘if I place a bounty on that one feature I want hopefully that’ll get bumped to the top of the list’ (Some of it was discord users pushing people to ‘put your money where your mouth is’.

I have seen and done this myself so I agree here as well. Most of the time when I did this it was “If you really care put a bounty and hope someone picks it up faster”. I believe it needs to be communicated better that a bounty != this will get done soon. Most of the time, from my experience, this was said to those trolls who come in demanding stuff and being blatantly rude to the Stash team.

My idea would be to have a bounty pot, all bounties into one big pot. WP did some work on estimating size of projects/issues before which could tie in …

WP/Org Team can sit and estimate small wins and place bounties on those that others could pick up for a small reward.

As the pot gets bigger then ‘small remuneration’ in return for successful PRs can become a thing.

I disagree with this portion. I believe this adds extra strain on the management team and makes them make decisions. How do they decide how much value a feature is? Currently, afaik, WP and infinite are the only real developers on the team who could make that kind of decision. As a non-coder, could you look at a feature request and honestly tell me what its value is? I think the users being able to add their own bounty amount speaks for what the users want and can be counted as a “vote”

On a project this size I don’t think bounties per issue are fair on either the person placing money in expectation or on it becoming a stick to beat WP with.

I agree that WP should not be taking the brunt for these FRs with bounties not being done. I do believe bounty per issue is the way to go and allows users to use their voice (and money) on what they want to see be included in the future.

4

Bounties have always been a weird spot for me, They’ve sort of evolved more into the stick than the carrot. Yes there are successful bounties where it motivates someone else to work on it, but you’ll end up with a lot of backweight on giant issues that would almost (or are) rewrites like audio stories, multi-user etc..

I’m not sure how to continue with it but I think having multiple smaller chunks is much better than one giant bountry, ie $5 bounty for every sub-issue in [meta] "short form" video content · Issue #6274 · stashapp/stash · GitHub for a total of $55 if someone wants to take it all on

TLDR: One big bounty pot, placed on issues as and when.

I would argue this is just “Backer”

I like am intruiged by NZB360’s feature bounty system where purchased “Credits” are contributed towards dev "goals’ like unraid support

The new Feature Bounty system is a replacement for doantions. Head into settings → Feature Bounties and purchase credits that can be applied to new features you’re interested in. It’s a win/win where you get to help support the development and also in turn get new features you want!
You can bank credits as well to wait for new things you’re interested in. I plan on adding a new “Dashboard 2.0” bounty soon.
reddit

where it’s used more for prioritizing features already considered/ in the pipeline but notably does also include being able to use that feature once released

5

When we originally added bounties, there wasn’t much of a backer income stream, and I wasn’t drawing much from the Open Collective. Bounties were a bit of a bonus for me to get a bit of extra income while working on users’ various pet projects. It also had the advantage of showing interest in a particular feature.

Once I started getting paid by the hour, it made working on bounties far more murky. I wasn’t sure if I should be charging for work done on bounties and award myself the bounty when the work was done. It felt like double-dipping, especially if it was something that didn’t benefit a plurality of users. It also meant that I felt compelled to work on these issues because I didn’t want the liability of unfinished bounty issues plaguing the finances. It meant that I would feel pressure to work on these issues to the detriment of what I felt the project needed.

I began to feel that as more bounty requests came in, I was having to spend non-trivial amounts of time design solutions for things I hadn’t previously prioritised, so even if I wasn’t necessarily working on the bounties themselves, I was still doing stuff that didn’t feel as important as what I wanted to work on.

In the midst of all this, we had people using the Bounty tier in Open Collective, then not indicating what issue to assign it to, or people putting money into things that weren’t even discussed as being eligible. I also had to track the status of the bounties to ensure we had the funds reserved for potential payouts (this is been less of an issue as the balance has grown). It was a headache to maintain and manage, and it was contributing to the overall pressure I was feeling. I made the decision to suspend the bounty system until I could rethink how it could be done.

I think the main problem to solve when it comes to reintroducing a bounty system is handling cases where a bountied issue isn’t or can’t be resolved in a reasonable time. Refunding users for such a bounty is not an easy problem to solve, and I’d rather avoid it altogether.

To that end, I’d prefer a system similar to @Ronnie711 described, where we can allocate a set of bounties for the duration of a release, funded from the general funding pool. This mitigates the above issue since if the issue isn’t successfully resolved, the bounty just goes back into the pool - or can be rolled over to the following release. I imagined getting the backers involved in nominating and voting on features to assign bounties to.

Whatever we do, the process needs to be clear and transparent. Ideally the management of it could be delegated to someone, rather than being one more thing I need to juggle.

6

What I was thinking but not explicitly putting a value on was, whilst a new system and not a lot of money in the pot, the bounty on a PR is a couple of $ here and there, a tip if you will. With a bigger bounty pot offers the chance to pay a little more, not quite a proper hourly rate but something that could reward time spent.

As for the last part we’d be heading back into stick territory with a tiny carrot.

7

I read through some of this. With the work WP is doing. Since it is ‘hourly’ it seems.

I would argue that WP has a general idea of features and items that are possible and planned.

I don’t want to get too into the details of what it was but I was involved in a project that took in all the feedback. Made it into a list and had a second colum of if it was ‘planed’, ‘possible’, ‘needs review’, ‘already done’, ‘not possible’, ‘against goals of project’ or some other statement on the scope of work.

The devs knew what they were doing, and had their own internal goals for the project like I would argue WP does.

The possible, planned and needs review were allowed to have ‘bounties’ as in this case put against them as a bonus paid to the dev on completion. Not everthing was allowed to have a monetary bonus placed on it. If the task was deemed not possible or needed extra work the person who placed it was contacted if they wanted to move it or just roll it into the default donations, I was told no responce to said contact in 90 days just resulted in donation.

I think one of the more clever ones I saw was about fixing a bug that affected <1% of users and only in a highly specific use case. From what I saw it wasn’t hard, but it took a long time to find so it kept getting dropped down. The bonus gave it priority even though it was a planned fix for ‘later’.

It was also very interesting as you could see what was requested and what is beyond what is seemed as doable or possible.

I guess that is a long winded way to say allowed it to actually just be a priority list of what is possible or planned, not a new feature list.

1 Like
8

So, I’ve been discussing with WP further and I wanted to put forward my proposal. Of course this will need to be tweaked and we can adjust as needed.

The original bounty system was suspended due to several pain points: management overhead, unclear handling of unresolved bounties, and pressure on development priorities. My proposal aims to reintroduce bounties in a way that addresses those concerns while still giving backers a voice in feature prioritization.

  1. Funding allocation — The Stash team determines a flat dollar amount from the general funding pool to allocate toward bounties. This avoids the complexity of individual user contributions and eliminates refund headaches.
  2. Feature selection — WithoutPants selects 5-10 (Rough number, can be adjusted) features that would make good bounty candidates. These would be features that are nice-to-have but won’t negatively impact Stash if they don’t get completed and keeping his focus on the critical development path.
  3. Backer prioritization — The selected features are passed to backers to discuss and rank from most to least important. Primary discussion happens on Discourse, with Discord available for informal conversation.
  4. Bounty assignment — The Stash team takes the backer-ranked list and assigns dollar amounts to each bounty based on the prioritization feedback.
  5. Development — Bounties are available for any developer to claim and work on.

That is how I see the “flow” of the bounty system working. I feel like this allows some flexibility on the Stash team to move bounties around for better options as they come up and take away the pressure of “I put a bounty on this feature why isn’t it in” even if it’s not really in the current scope.

Hopefully we can get some responses from users as well as Stash team and I will try and compile it all till we get the right proposal put together.

9

A WithoutPants approved list of bounty candidates isn’t a bad idea.

But I just hate seeing all this responsibility repeatedly fall on his lap. Unfortunately we don’t have anyone else with as deep of a technical understanding of the project at the moment.

So I would almost rather get rid of the bounty system entirely, and double down on donations/backers. Eventually the project could afford to hire another part-time developer to assist.

10

I agree with you to a certain extent. The work for WP would mostly be done on the front end this time, rather than the back end, and I find that to be significantly easier for him and gives him significantly more control of the situation.

Per the part time dev… in a perfect world I would agree. The problem with that is… who? We would need someone who can reliably dedicate their time. As an example if we found someone who would be happy to fill that role what if their life situation changes?. The problem then becomes that, currently WP would need to take time and energy to mentor and train this person. What happens then if their life and can no longer participate? Most of WPs work is gone in the snap of a finger and we are back to square one. If the stash team is considering something like that then I would be happy to throw my hat in the ring for that as my next 6-8 months is pretty much free game. Obviously pay would need to be, and rightfully so, significantly less than WPs due to skill and knowledge gap. Then again, i’m already willing to do this for free as I am learning from WP so why would they pay me? Finding a real dev who is willing to take this on is, in my opinion, one in a million but I may be wrong in that assumption.