Hi,
This is the continuation of a discussion I started in PMs on Twitter.
Iād like to know if thereās a vote-for-the-next-feature thing planned.
Personally, Id like to put a bounty on a feature I really need (MongoDB collations).
I tried to code it myself, based on the ReadPreference implementation, but Iām on Windows, and with the addition of GraphQL (which I love and might use), I think itās to complicated for me.
Thx
On the vote for the next feature side of things, there is an official Discourse voting plugin. We could setup a category and allow people to submit suggested features and then use a reddit-style upvoting system.
Iām doubt we could give a guarantee of implementation at this time but perhaps it could provide a useful indication.
Voting system would be great actually. My suggestion is more file security. Parse Server only accepts file from a parse user but security is still weak. One who has my parse server adress and app id can easily upload files. There is no triggers for Parse.File like ParseObjects. That can lead eventually orphan files. And unnecessary usage of server.
That would be a good start. Bounty comes next.
Thanks you your thoughts @uzaysan, I would like to keep this thread focused on how we should prioritise new features rather than discussion about specific requests.
However, on the point about file triggers, this is actually a brand new feature in Parse Server 4.2.0ā¦
Weāre working on documentation in the cloud code guide and it should be published soonā¦
I found the Discourse voting plugin to be a great idea.
Any news on this?
Iām still looking into it. Iāve installed the plugin and setup a test category but I also want to get some feedback from the other @core-contributors because I donāt want it to end up being a burden.
Sorry for the delay on this, Iāve opened up a new Wishlist category publicly. Feel free to post a request there and vote. The number of votes available depends on your trust level but Iāve tried to be fairly generous to those of lower trust levels as not everyone uses the forum frequently.
Votes are returned to users once the topic theyāve voted on has been closed i.e. has been implemented.
We might run into dispersal of conversations about feature requests if we maintain a āWishlistā in the community forum and feature requests in Github issues.
Already the first wishlist post MongoDB small features, like Collations is a good example:
Define a distinction between opening a FR on Github vs. in the wishlist, hoping that people would consider that distinction and prevent cross-posting. What could that distinction be?
We are in the process of establishing a triage process on Github issues to address and resolve them faster. A wishlist on the community platform could make it more difficult to triage and reference other issues and code than in Github issues. How can we mitigate that?
An externally visible wishlist is statistically seems more meaningful if it is set up temporarily to let users decide about a topic for a limited amount of time. Otherwise we will always see wishes that are posted for a longer time having more upvotes, therefore floating on the top of the list / getting more attention and receiving even more upvotes. This skews any interpretation one could draw from the wishlist. Which conclusions would we want to draw from the wishlist and how likely is it that someone will submit a PR because a feature gets upvotes vs. the person requires the PR to resolve their own roadblock regardless of whether itās in a wishlist (for example see the iOS SDK roadmap from 2018)?
On another note, we could think about setting up a ānotificationā channel people can subscribe to where we can actively engage the Parse Community around a specific topic and ask for feedback on demand in a structured form like a poll. That goes beyond FRs and can involve anything from governance to product roadmap. Through such a channel we can pose a one-time question to the community which feature they would like to see the most, close the poll, evaluate results and derive concrete action from that. Such a channel is more versatile and could be our first way to directly mass-engage with the Parse Community.
All good points. Iāve always been conscious that it may not work, itās an experiment! But itās good to have someone to discuss it with, and youāre right that establishing some parameters would be good if it is to be successful.
Just to give my perspectiveā¦ I thought that if it worked well the Wishlist could replace FRs on GitHub to further reduce the non-issue issues. In my experience FRs tend not to go very far unless it is very pressing (e.g. Sign in with Apple) or the author has at least some intention pursuing a PR themselves. So I guess my distinction would be whether you have an intent to pursue it or not.
Those involved in triaging could have moderation perms on here. The biggest problem here is that there are few team members who are active on here and know how to moderate.
Temporary list sounds like a good idea but I donāt think we can do that without a well compensated dev.
Could happen but I believe the list is actually ordered by activity (like the rest of the forum) rather than number of votes so this might not be a major problem. This is also probably a much bigger problem when there is lots of topics on the Wishlist.
Itās possible to āwatchā a specific category or perhaps more usefully a specific tag so you get emails about each new topic etc. Iāve tried to get people to engage with specific topics via twitter in the past which works to some extent but it tends to be a very small number of people who engage. But Iām all ears to change that - especially with some help!
Overall, Iām not sure of the perfect solution and it maybe that it just doesnāt work. It would be cool if we could have all FRs in GitHub automatically create a topic on the forum and there were limits on replying etc, that way there would be no confusion. But I donāt have the time (and potentially the knowhow to do that!).