At the recent biweekly developers’ conversation, concerns were again raised about managing items in the GitLab Issue Tracker.
This has been a recurring topic for several years, but no decisions or actions seem to result from the conversations. If I am mistaken, and some new guidelines or decisions have been established, could someone please record them? If there are outstanding questions that warrant further discussion, could we record those?
When the topic came up at a developer meeting a year ago, we seemed to reach some initial new understanding about how we would like to use the issue tracker, but an attempt to update our guidelines stalled.
Maybe this discussion forum would be more effective than the issue tracker for recording ideas about how to use the issue tracker and approaching a consensus.
I believe that our current documentation about issue management is inconsistent and misleading. If we are facing a dual problem of issues getting opened and issues not getting closed, we should try to clarify
- who should open issues, under what circumstances, and with what expectations?, and
- who should update and close issues, under what circumstances, and following what conventions?
My perception is that specific issues are rarely discussed or updated at biweekly meetings or at quarterly planning meetings. In current practice, the issue tracker does not appear to be part of the project planning process. Codifying this might help reduce unproductive creation of new issues. On the other hand, there are a lot of developer-hours spent in GROMACS meetings, and some time could be spent reviewing issues to either allocate effort, defer to future discussion, convert to forum discussions, or to mark as “won’t fix”.
Clarify annotation policies for issue management (#4438) · Issues · GROMACS / GROMACS · GitLab and Update docs for issue management. (!2591) · Merge requests · GROMACS / GROMACS · GitLab record some past discussions.