Let's talk about community & support.

Meanwhile, I have also taken upon myself to manually go through the entire GitHub repository, Forum feedback and bug report channels, and then have them all neatly categorized and prioritized for the engineering team internally. This has proven to be a very arduous task, but a highly essential one to really understand where we are standing as a product and also to not loose all the valuable information that this loving community has shared with us.

I hope to have this completed by the time the other tools are launched for users, and thus will be able to safely close down these spread out channels of feedback. We will have ported all the data safely internally for immediate use, and then use the new tools for all future purposes.

I would just like to reassure that the community’s efforts in giving us feedback will not be overlooked, and to state that this is really important to us a team.

6 Likes

Thanks for the detailed reply- I appreciate the transparency about the status and your passion for driving this forward. :slight_smile:

Hope to see this system live soon!

P.S. IMO allowing feature requests to be created same as bugs would be great, especially as the line between the two can be pretty thin at times.

1 Like

You are almost right, and I used to have the same thoughts earlier. However after further research and thought into this project, I have now realized that there’s more to this than just classification. Each of these require different data points to be collected, for ex., bugs would require information like platform, version, console log errors, trigger points etc., while feature requests and feedback require some information about the use case, type of user, the criticality of the feature for their workflow and some other quantitative measures to understand the impact on the total user community. This lead me to find separate solutions for the two.

We have now been able to solve the underlying engineering issues, and hope to have the systems public sometime next week :slight_smile: pretty excited about this!

2 Likes

Each of these require different data points to be collected

Makes sense, I didn’t think of that.

But from a UX standpoint - I don’t think having different underlying systems is mutually exclusive with having both available from the same place in the app though, just each requesting different data?

We have now been able to solve the underlying engineering issues, and hope to have the systems public sometime next week :slight_smile: pretty excited about this!

Great, looking forward to checking it out! :slight_smile:

1 Like