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.
Agreed.
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:
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.
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.
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 ;))