If I am correct there are 12 bounties open with a total sum of $815 for the Gallery app on https://www.bountysource.com/teams/interfasys/issues Some of these are just blocked because other issues in the core need to be addressed first. I know the community can be diverse and so when it comes to feature requests but I am very interested to see how the community can be involved in nextCloud while taking into account if a user is actively contributing to a forum/github or not, if the user has given paid support (in any form) or not.
@joephein - I don’t understand your request. Could you try to break it down?
The way it usually works with bounties as far as I’m concerned is that the people who are supporting the feature get to accept the requirements since they’re the ones who need to validate the work at the end.
Now if core is blocking a feature, it’s usually known in advance and a separate task. It’s usually much harder to implement changes in core.
There are also bounties on programmes which typically stay open for months. That’s one reason it’s best to support the separate features.
There are some feature requests that are important for me. Other people in the community can have different requests and priorities. Personally I like the interface of uservoice to visualize this. This is for example used by https://tutanota.uservoice.com It seems to promote the voice of the community more than the voting in github. But this might just be a personal preference. Just to list my current most important wishes:
- Favorite filtering support in the gallery app: https://github.com/owncloud/gallery/issues/230
- More features regarding tags, also discussed here: Tagspaces for owncloud
- Better way to work with multiple files: select multiple files by using the spacebar, add comments or tags to multiple files at once etc.
Relates to the bounties I am clear on the acceptance of the requirements. It is just that it is nice to see some progress, being it as an update of the dev team about the progress of a certain feature request or even better see the features being implemented in the release(s).
Thanks. Re-reading both your posts, I’ve discovered an interesting problem with things like Bountysource.
As a supporter, you pay in advance, in hope for a feature to be implemented. This is quite different than a crowdfunding campaign where there is a timeline.
The developer is under no obligation to do any work and usually waits for the bounty to be sufficiently high. If there are complications, then it adds up to the wait since the pre-requirements may also need to be funded, etc.
So, supporters have their money taken away, but nothing changes, for months, even years.
That’s one reason I think that for major features, crowdfunding platforms should be used. Bountysource and Patreon are good to try and get a coffee a day to the dev or to try and motivate someone to have a go at implementing something relatively simple.
2 Likes
Agreed, although I have a pretty significant personal bias here, working in the crowdfunding industry. I’d point out though that I work in this space, because I believe in it. At the end of the day though, if people can tap into a community who want what they can create, set a goal that can be reasonably done, with a good margin for error, and they have the trust of the community - especially core contributors, then this model can work really well. The main thing to remember though, is that when you go with crowdfunding, it’s as much about your ability to communicate, as your ability to code. That doesn’t mean you need to be a native English speaker, but it does mean you need to be willing to explain what you’ll do / are doing and keep the community updated in good times and bad.
1 Like