Open Source

• Handling feedback

#Handling feedback

During the lifetime of a package, many users will likely have feedback. This feedback can be split up into three big categories:

• bug reports: these are reports of, ideally reproducible, bugs that we need to fix
• general questions: this feedback revolves around how the package can be used
• feature requests: these are things our code doesn't do but could do.

In any applications that we develop, we use our Palzin Feedback Instance to triage feedback into the various categories.

If application is not linked with Palzin Feedback Board then we use the below template to create a task in IDP - Ingress Delivery Platform

**Describe the bug**
A clear and concise description of what the bug is.

**To Reproduce**
Things needed to reproduce the error.
eg: Configuration, Migration, Model, Controller/Command

**Expected behavior**
A clear and concise description of what you expected to happen.

**Screenshots**
If applicable, add screenshots to help explain your problem.

**Versions (please complete the following information)**
PHP: 
Database: 
Laravel: 
Package: 

**Additional context**
Add any other context about the problem here.

**Exception**
The thrown exception message.

**Stack Trace**
The full stack trace of the thrown exception.

For general questions, a new discussion in the "Q&A" category will be open. Feature requests will go into a discussion in the "Ideas" category. For bugs, a new issue will be opened.

We consider ourselves the owner of the issue tracker. The issues list on a repo should only contain items that we intend to work on. If a user created an issue that we don't want to invest our time in, it should be converted to a discussion.

The community owns the discussions of a repo. We'll give feedback on specific discussions when we have the time, but there's no guarantee.