For the time being we made it so you can request to join AllowFeatureRequests to show that you need to have that capability. We’ll use the activity on join statistics here to help prioritize projects related to feature requests and help us understand scale (in terms of users) we should expect a bit better, so feel free to request to join there in advance!
It will likely take us significant time to properly roll out whatever the improvement or revamp to feature requests should be, so please do take into account that we may not accept the request for a very long while or action it at all. (if we decide that there’s a better way to intake this kind of feedback than having a “feature requests” category)
We just accepted the first small batch earlier this week. There’s several hundred people queued up so it will take some weeks for us to clear out this initial wave. We don’t want to accept all at the same time to avoid a spike in bug reports in #bug-reports which would overload our engineering teams and might lead to important bugs being missed on first glance.
@Kairomatic I have recently noticed that dominant bug report staff (thirdtakeonit, Howimetted, and Focia19) have significantly stopped posting filing confirmations for bug reports. Is this due to the new transition? Can those who file bug reports still expect a filing confirmation?
This is the reason why I ask: A bug report that I filed 8 days ago has yet to receive a filing confirmation. Although one might suspect that it fell through the cracks, the team is usually on top of posting filing confirmations from my experience. Also, are filing confirmations posted when a bug report is determined to have enough information to be investigated or when the issue is successfully reproduced?
By “filing confirmation”, I’m referring to a post along the lines of: Thanks for the report! I filed a ticket in our internal database and we’ll follow up when we have an update for you.
No that doesn’t make sense, you should keep using the current category if you have access right now.
At some point in time long ago our tickets weren’t automatically being forwarded to our internal tracking system, it had to be manually done, hence the message. It has been automated for a long time now and every issue will get “filed” automatically and past issues have been ingested as well.
Every bug report is handled the same and every bug report will get assigned to a team internally. These confirmation messages don’t mean as much anymore, whether the message is posted or not has no effect on how the issue is handled internally.
With this bug reporting group and the future access to Feature Request there would still be distinctions between “Members” and “Regulars”, the only way to completely get rid of this would be reopening access to regular or continue with this group thing and delete ‘Trust Level’ from a user profile.
I assume one revamp you’re referring to is to the Avatar Editor with custom positioning, scaling, and rotating of accessories (as announced at RDC23). With this being the case, are there certain issues (e.g., position, scale, orientation) with catalog assets that we shouldn’t report at this time?
In general, would it be possible to have a list of issue types not to report for each bug report category due to revamps to features? For instance, are issues with R6 considered obsolete due to the development of the R6 to R15 Adapter?
I wasn’t referring to anything specific when I wrote that, it’s a generic explanation for why a resolution may be delayed. You should report bugs when they impede your development.
Well it makes sense as you can’t just accept anyone or random people, you need to have some sort of system that allows people to come in knowing who they are and weather or not they trusted enough.
