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.