<aside> đź’ˇ This process is currently GiveWP-specific, and not for other StellarWP brands
</aside>
As a part of our role of customer ambassador, when we find a problem, bug, or area for improvement in the plugin or an add-on, we escalate it to the product team in the form of a post on the GiveWP feedback site (powered by Canny). This is done during ticket time, as a part of the flow.
Any time we create feedback on the site that is based on a request from Priority Support, we add a note to the Help Scout ticket with a link to the feedback.
The feedback site is designed to provide a space between “Users are requesting this issue” and “the development team is working on this issue” so that support technicians can always tell what is being actively worked on during the current development cycle (it’s on GitHub) and what is still being evaluated for inclusion in a future development cycle (it’s in the feedback pipeline and marked accordingly).
There are three types of product feedback:
The first two are discussed here. For more on Documentation feedback, see the section on Managing Docs.
<aside> đź’ˇ NOTE: The Bug/Feature Name and Details entered here are all publicly viewable. User information of any type should be removed from feedback.
</aside>
If in the course of replicating customer issues we find a bug that is replicable in a separate environment, we should immediately create feedback, and alert Senior Support Technicians and/or the Head of Support that the feedback has been reported. It’s not the role of Support Technicians to determine if an issue is urgent, just to keep an accurate count of how many folks are reporting an issue.
To create the feedback for bugs, visit the bug reports page of the feedback site and click to create new feedback. While filling out the title and description of the feedback, ensure the bug has not already been reported. using the column on the right.
If the bug is not already reported, use the left-side interface to report a new bug.
The title of the bug should be short and descriptive and communicate what is broken. {X} should...
language is helpful, and titles should remain as end-user understandable as possible.
Race conditions should be avoided on the init hook
Email reports should include renewals