How We Handle External Requests in YouTrack

External Requests in YouTrack

The YouTrack team has several channels that we use to collect your feedback. We have public presences on X and YouTube, a community forum, and our own product blog.

The most dynamic channel that we use to collect feedback is our issue tracker. Here, your feedback is reported to the same YouTrack project that we use to plan and manage our own development efforts. Your issues co-exist alongside our own and are given equal consideration for implementation.

Registered users can track the current status of a public issue, whether they or another customer reported it. We let the community comment, vote, and view changes that are applied to each issue.

In response to this amount of interaction, we developed a formal process for handling external requests in our issue tracker. By sharing this process, we hope to increase the level of transparency and set your expectations correctly when you report an issue.

How We Process Issues

The YouTrack team processes all of the external requests that are reported to our issue tracker on a daily basis. Our standard approach is to assign the issue to the subsystem owner, set the priority, and assign the issue type.

• We classify external issues as bugs, cosmetics, performance problems, security problems, exceptions, usability problems, features, or support requests.
• We normally reserve the Task issue type for our internal issues.
• Many external issues don’t require changes to the source code. These describe configuration problems or simply ask questions for clarifications. We classify these issues as a Support Request. For the issues submitted to our tracker, we do not follow the response SLA that is applied to the support requests. If you have an urgent problem, please submit a support ticket. 
• As a product team, we reserve the right to reject a request. We don’t delete the issue. If it doesn’t fit our vision for the project, we assign the issue the Won’t fix or As designed state. In this case, we explain our rationale for rejecting the issue in the comments.
• The issue type can change during its lifecycle. For example, a request that is initially classified as a Support Request can be reclassified as a Bug upon further investigation.

Features

We assign this type to external requests that describe functionality that is lacking in the product.

Basically, any comment along the lines of “It would be really helpful if YouTrack could do this, or that, or the other.”

• Reporting a feature doesn’t guarantee that the requested functionality will be implemented as described by the reporter, or will be implemented at all.
• The number of votes does influence our decision to implement the feature, but cannot be considered a primary motivator. However, there is usually a strong correlation between our vision and the number of votes for a feature.
• The product team defines a development roadmap. Our roadmap is influenced by various factors, including our vision for YouTrack as a company and product team, feedback and requirements from internal users, and analysis of external feature requests.
• We don't set a due date for a feature to be implemented and don’t commit to deliver a feature in a specific release. We are open and share our plans publicly, including our roadmap and the tentative release date. However, these plans may change at any time for various reasons.
• Unfortunately, it’s not always possible to post a comment and provide a detailed answer in every feature request. Please treat your request as open and ready to be upvoted, but keep in mind that its implementation is not guaranteed.

Bugs, Cosmetics, and Exceptions

These issue types are generally processed in the same manner. We classify issues as bugs when the product doesn’t work as expected. Cosmetics are for issue that describe a defect on the user interface, while defects that produce errors are classified as exceptions.

• We don’t deliver bug-fix releases on a set schedule. Normally, we release a bug fix at least once a month, and do our best to maintain a decent level of product quality and minimize the number of open bugs.
• We set the priority for each bug and use this classification to determine which bugs are fixed first.
• We prioritize bugs for which no workaround can be found as a Show-stopper. Bugs that affect business-critical functionality are marked as Critical. These issues get top priority and we do our best to fix them in the nearest bug-fix release.
• We take the number of affected users into consideration when we decide which bugs to fix. When a relatively small number of users is affected, we may decide to work on other bugs that have a lower priority first.
• For bugs that are prioritized as Major, we make an effort to fix them in the next major version. However, we do not postpone the release of the major version if every major bug has not been fixed.
• We don’t give any estimation for bugs that are prioritized as Normal or Minor.

Usability Problems

We assign this type to requests where the reporter struggles to perform a task. Maybe the steps required are not obvious. Sometimes users just get lost. These issues are classified separately from feature requests, as they require additional input from our user experience designers.

• The approach that we follow for usability problems is similar to our tactic for feature requests. We don’t provide any estimation or commitment to fix them.
• Perception plays a large role in determining what is or is not a usability problem. Maybe other users see things differently. Here, we try to assess whether other users also expect the application to behave differently.
• When you propose usability improvement, it may be rejected if it breaks user experience in any other manner, or negatively impacts system behavior or system performance.

Security Problems

Any issue that points to a situation where data is at risk of loss or theft is classified as a security problem.

• As a rule of thumb, the team considers all security problems to be high priority issues.
• Every security problem reported is subject to evaluation and may be reclassified as a missing feature, usability problem, configuration issue, or bug. For instance, if the permission scheme that is implemented in YouTrack is not flexible enough to cover a particular use case, we usually consider this to be a feature request, not a security issue.
We work directly with users who report security issues to ensure that vulnerabilities are not disclosed before a fix is applied.
• We don’t reward a bounty to users who report exploits and vulnerabilities. However, we do appreciate your efforts to help us keep YouTrack safe and secure.

Performance Problems

We distinguish performance problems that are detected in our cloud-based platform from the problems that are experienced by users who work with a YouTrack Server installation.

• For YouTrack Cloud instances, we always investigate performance problems and do our best to fix them. However, the resolution times may vary.
• For YouTrack Server installations, most performance problems are related to configuration issues, which means that no fixes are required from our side. However, we do provide support for these cases, providing detailed instructions of the best ways to configure your environment and server to ensure the best possible performance.

How You Make a Difference

Your feedback helps us find undiscovered problems and identify potential improvements. You also help us learn more about how you work with YouTrack and what you expect from it.

By making the issues in our project public, we provide you with an environment where you can share your experiences and connect with other users who find themselves in similar circumstances. We recognize that your interaction with YouTrack won’t always be positive. However, taking a positive approach to problem solving goes a long way.

When you report issues and add comments, keep these things in mind:

• We don’t moderate the content that you post in issues and comments. We expect everyone to be polite and constructive with their comments. This gives us more details and describes your use cases much better than angry complains and blackmailing do.
• Try not to use the issue tracker as an outlet for venting your frustrations. We understand the aggravation you might experience when you’re just trying to get your work done. Always remember that you catch more flies with honey than vinegar.
• If you find a feature that you would like to see implemented, don’t hesitate to vote it up. This helps us gauge how much impact a new feature will have on our customer base. Your votes also help us measure the interest in fixing other types of issues, like usability problems and bugs.
• If you see an issue that describes a usability problem that you have experienced yourself, please tell us how you expected the application to behave. Describe your use case in detail as well. This helps us better understand what you were trying to accomplish and identify how to make the process more user-friendly.