Is it necessary to make the list of bugs in the project public?

Now it has become fashionable to give users the opportunity to view a list of known bugs in the project, to introduce new bugs and even vote for bugs.

The pros are more or less obvious:

• Developers get a good way to gather information about user problems.
• Users can use the list of known bugs to solve problems on their own. Often this is a faster way and reduces the load on the technical support service.

But if the pros make you know about yourself immediately, then the disadvantages of this approach appear after a while:

• A bugtracker is often another place to look for information about a problem. Those. if the user has an error and he wants to solve the problem himself, then he should look in the forum and search in the bug tracker . If you leave users only a forum or only a bugtracker, it will be even better, because look for similar problems will need only in one place.
• Suppose a user found an error in the product and contributed it to the bugtracker. If he wrote by e-mail and didn’t receive a response within a day, then either the developers have already died, or the service leaves much to be desired :-) But if the bug got into the database, this fact does not oblige the developers to react at all . The presence of bugs in the bugtracker does not mean at all that the developers recognize it or are going to fix it - they may well be closed after 5 years with the comment won't fix. Many users are embarrassed to ask directly in the bugtracker, after all this is a “public” place.
  Those. seeing the bugreport in the bugtracker, the user might think that:
  • if the developers did not close the bug report, then they recognize the problem. The error will be fixed soon
  • developers simply accumulate information on the problem. Whether developers will correct this error and when is unknown.
  • About this error, developers know X years, but it is still not fixed. Probably, they are not going to fix it at all, it is not worth spending time on its discussion.
  Moreover, if the developers first accumulated information on a problem for a long time, and then said it won’t be correct, the reaction of users can be extremely negative.
  
• There is such a bad thing - to instruct the developer to fix the bug, directly contributed by the user. Of course, this simplifies the life of the management (no need to think about what to occupy the developer, "hung up" some bug on him and sit still), but badly affects the quality of the product. It’s too great to fix exactly this little problem, and not try to understand and eliminate the cause of this and a dozen other similar problems.

Problem solving, in principle, is known:

• We make 2 types of tasks: bug report and change request.
• If the user finds an error, he simply creates a bug report. Moreover, it is necessary to register all errors, force the user to look for similar problems in order to avoid duplicates - this is a very bad idea because:
  • this disrespect to the user. He found a glitch, and instead of getting information from him in any convenient way as quickly as possible (even by e-mail), he is forced to register, look for something similar, fill out some forms, etc.
  • the user cannot know that this is the same bug, and not a similar manifestation of some other bug.
  • developers (partially) lose information about the importance of the problem, since not all problems are recorded.
    Ie, a bug report is not a message about an abstract error, but about the manifestation of an error with this particular user.
  Imagine that you come to the police with a statement about the theft, for example, and you do not take a statement until you go to the archive and look for similar crimes :-) And in the field of software development, this behavior is considered to be a company’s openness and good service: -)
• After the user has submitted a bug report, the representative of the company should inform him (personally) when the problem will be fixed and what is planned to be done. A bug report without an answer greatly undermines the credibility of the idea itself.
• When the company decided to correct the error, it is necessary to create separate tasks of the type change request, which should be associated with bug reports. Several change request-s are needed if fixing an error includes not only fixing the code, but also updating the documentation, the site, etc. The importance of creating separate change request-s is also in the fact that the possibility of “hanging” fixing the problem on the developer is eliminated without too much thought.

The main problem with this approach is that by no means all of the issue tracking systems allow you to conveniently link bug reports and change request, assign different workflows to them, set different visibility rules for them.
If your system does not allow you to do this, I would advise you to use a bugtracker either only for communicating with users (we are only submitting bug reports), or only for internal development (we are only making change requests), but not disturbing everything in one pile.