Bug management process and key points

the Bug management questions we talked about two days ago are a lot of bug tracking software. I think tools are a part of them, but they are mainly in the Bug management process.
among these bug management tools, one of the most important attributes of a bug is the "status", which generally includes "new or active )", "in progress", "fixed", "reopened", and "close, these statuses clearly understand the process from discovery to elimination of a bug:
1. the tester finds a bug and submits it. Bug status: New
2. the developer receives the bug and the bug status is in progress
3. after the developer completes modification, submit the bug and change the bug status to fixed
4. the tester tests the bug again based on the changes made by the developer. If the bug persists, set the bug status to reopened. The process starts again in step 2. If the problem has been solved, directly change to close, and the process of the bug is finished.

although the process is simple, some problems are still found in actual use:
1. incomplete bug information:
some information, such as the project, module, designated handler (that is, who is assigned to handle it) is used for statistical analysis, and which project is used for analysis, which module, who has many bugs, who has found many bugs, who has changed many bugs, etc. According to this information, we can roughly see the workload and quality of work of a person. So don't bother yourself. Write all the bug information.
2. the provided information is inaccurate:
some bugs have been described along with vague descriptions, but they only indicate errors, but what are the errors and prompts, it is unclear how such a bug occurs. If it is handed over to the developer, it will only add a burden to the developer, because he has to perform another test to find more information, to exclude a bug, or he will discuss it over the test, ask for details, and sometimes give feedback multiple times to determine what the problem is.
3. developers can close a bug:
only the bug submitter (that is, the discoverer) can close the bug. developers can only use two states: "In process" and "corrected"
4. bug reproducibility:
this important attribute cannot be reflected and measured in the Bug management software. This task is mainly tested. If you find a bug, let's call the developer. Someone else is here. You want to show him this bug, but it never appears, I don't even know how this bug was fixed. In this way, bugs that cannot be reproduced are hardly counted as bugs, which are also the biggest headache. As a tester, your task is to find the pattern of a bug as much as possible and try various possibilities. Even if it cannot be reproduced, at least let the developers know what you have tried, he does not have to make any detours.