New features decisions

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

2 Likes

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.

2 Likes

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.

2 Likes

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…

2 Likes

I found the Discourse voting plugin to be a great idea.
Any news on this?

1 Like

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.

2 Likes

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.

Issue

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:

  • At first it looked as if the post was just a question about a feature that already existed but is missing in the docs (which is not a rare case). The process to resolve this would be to transfer the issue to the correct repo and classify it as missing documentation. We can’t do that with a wish posted in the wishlist and would have to open an additional issue on Github.
  • Then the author clarified the post by referencing a Github Issue the same author opened 2 years ago. I assume the reason the issue has not been reopened was because a new list appears as a new opportunity to voice the same FR, hoping to get more visibility. (No blame to the author, it seems an intuitive thing to do.) Now we have a conversation that is split between posts and increases the research effort for team members.
  • I then suggested to the author to pursue a PR. This would mean going back to Github Issues and reopening the existing issue or creating a new one.

Suggestion

  • 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.

@Tom Can I get your thoughts on my previous post?

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!).