What oparoz said.
What you say is somewhat valid for home users, but what about bigger deployments of ownCloud where the gap between the end users and the admin is wider ?
I would even question whether a home user would be able to give feedback in a way the devs can efficiently process it.
A lot of effort has been going into making ownCloud installation easier lately, which automatically means that the average skill level of the home user goes down too.
edit : actually, the problem of collecting end user feedback could be tackled by implement features that allows ownCloud to push polls and such things.
Still, there remains the issue that the voice of the contributors will probably be always louder, if just because they are more invested, than the end users one. How can we make sure to strike the right balance between both side of the community ?
Also, I was wrong to distinguish the community and the users ; they are indeed both part of the community. I meant devs and users and will edit my OP to change this.
Interesting topic and we should really try to come up with some concrete ideas. Let me start with some more or less obvious points. In most cases software gets developed because of three reasons:
- to “scratch your itch”, this means people who can write code write the stuff they want and need.
- people get paid by their employer to write some specific features
- the community suggest a feature which a developer consider interesting enough to work on it
- people write code because of a bounty they want to get
Personal I consider a bounty program something really important. Because it helps to close the gap between community users and paying users to some extend. With bounties the community can compete on the same level about developers attention. Of course a developer will still decide if he things a feature makes sense or not. But it is one important step into the right direction.
What I could also think of is that the Nextcloud Foundation picks for every release one or two of the community features with the highest vote and add it to the roadmap for the next release. I think this could be a interesting approach to experiment with.
Let’s also not forget, that very often, the ratio between users making suggestions and devs capable of implementing them is rather large, so issues can quickly pile up. That’s one reason I’m not too keen on seeing hundreds of users registering on Github to submit their thoughts.
And services around bounties are spreading so that’s good too. However, creating a bounty implies a power user already (and an invested one).
How do we collect feedback of basic end users that either don’t have the skills to create a bounty, create an issue on github, or just don’t have the inclination to do that ?
I was thinking of a feature where Nextcloud would be able to push feedback surveys towards all its users (and by that I don’t mean only the server admin, I mean the end users). It can be as simple as an URL to surveymonkey, or the feature could implement the survey itself. It could be an app for users of the server web interface, or an additional feature for the client for users who only use the sync client (although the new notifications API could do the job).
This way would provide a centralized and easy mean of collecting feedback ; of course it should be possible for an admin to control the behavior : disable it entirely, or asking to manually validate when a survey comes down for instance.
Really this seems to be an issue that would strongly benefit by having feedback from someone with usability experience such as @jan . One of the big issues is that users typically only draw on solutions they’re used to for their specific encountered issue, which isn’t necessarily the best solution for all similar use cases to theirs. A usability expert can look at specific requests, bring it back to the use case that they’re trying to cover, look at what other similar usecases may be helped by implementing various solutions and help pick out solutions that will be easily comprehensible and smooth workflows for the majority of target users. This is a very different process than just “implement whatever feture users are yelling the most loudly about/throwing money at”
Regarding bounties, ideally, you’d want open-minded sponsors who trusts the process and the project’s experts to deliver both what they and the community need, but that’s not always the case and the dev needs to get the sponsor’s approval in order to be able to get paid. Nonetheless just as with ownCloud, it’s always best to consult with the designers’ team when devising a solution.
The OP makes assumptions about the user being on Windows etc., but there isn’t a typical open source cloud user. There are groups of users with different goals and skills and that’s something ownCloud had problems with, mainly I think because of 2 reasons:
- paying customers have very specific needs that need to be fulfilled, so that’s the priority
- the product targets Dropbox users
People at CERN don’t use ownCloud like a student at TU Berlin or someone who bought a PiCloud prototype.
In the proprietary software world, one chooses a solution based on his needs. People who need more advanced features will pick Box per example, the ones who want more privacy will pick SpiderOak, etc., but in the Open Source world, it shouldn’t be necessary to switch platform or hire a team of developer to build a custom version, instead, the solution should be flexible enough to fill different use cases.
We need to be careful with such features. This can easily be seen as some kind of spam. I definitely would not like my software to do something like this. So it would need to be opt-in on a per user level. Also people could rise privacy concerns because this would mean that someone have to know all Nextcloud installations to push the survey to them.
At the moment I wouldn’t say that something like this is completely impossible. But we would need to be really careful to do it right.
It would depend on how often it happens, and how it’s done I guess.
I used the term “push” but it really would be a pull actually, just like the client is querying for updates for instance.
Actually, we could also tie these surveys with updates : since the user is already engaged in a manual action anyway, why not ask him whether he wants to provide feedback at this time ?
I agree that this would need to be implemented very carefully, because it could backfire easily.
If we just ask on installation, then it’s seen by all installing admins, and doesn’t include anyone who doesn’t want to be included. I would suggest a policy of not pushing more than one survey a month, made clear when we ask for permission, would be reasonable.
This one depends on the app and the release cycle I guess or we end up with the ownCloud dilema regarding community contributions. With the Android app in Mind @tobiasKaminsky @przybylski and I opened of a large share of (great) PRs which up to now never made it into a release so only adding 1-2 community PRs per release might be a quota that slows down progress. On the other hand let’s see where this leads us since I am still positive that this won’t happen. Especially since the PRs are also features that other users requested and that got implemented by the community.
I guess what @bjoern was suggesting to add these items in addition to the roadmap. Everything else is “nice to have” and the mentioned features are something that the foundation publicly commits to.
One of our goal with Nextcloud is also to have all pull requests merged in a timely manner. Having a Pull Request that is ready for review open for more than 2 weeks is just horrible
In addition I’d like to note that I don’t see any reason to differentiate between “community PRs” and “employee PRs”. Both are part of the community, moving a PR from backlog to backlog just because one is not employed is rather questionable. In the end there should just be “the community”
I totally agree! I just shrug reading the term 2 “PRs by the community” since that has also been a promise by oC in the end (which didn’t really happen consistently) and 2 per Release would have taken a decade to get all open ones shipped (without opening any new ones ;))
Of course I didn’t want to say that we only merge two community PRs per release. This should be a lot more as already said by @LukasReschke. My idea was more about features suggested by users (not developers who already have a ready to apply PR). For this we could try to pick a certain number, e.g. two, and commit ourself to implement it for the next release. Not because a customer pays for it, not because there is a bounty, not because it is important for me, but because we as a community decided that this is something we should have.
You are totally right but I think in this situation it is the assignment of the administrator to track end user issues. maybe we should provide something to ease this for administrators? I think one way could be adding a support formular in our nextcloud clients so end users could post their problems and the administrator of the installation can read it and maybe post the problem in our community if it is something important.
ideally we implement this opt in so an administrator can choose whether he wants this formular for all users or not.
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:
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.
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.