RfC (dev process): When to close an fixed issue?

I have just created issue #1553 ([https://github.com/bit-team/backintime/issues/1553)](https://github.com/bit-team/backintime/issues/1553)) for which we already have received an PR that fixes the issue. Which timing should we follow to close an issue? a) When the issue is fixed in the "dev" branch b) When the issue is fixed AND an contained in a release The timing may be of importance when users search for "open" issues. Currently we apply a) (mostly ;-)

I would suggest the following: 1) An issue is closed when the problem is a) fully understood, and b) a fix has been committed to the "dev" branch, and c) the fix is documented in CHANGES. Therefore, a closed issue means to us: "No more work is needed here." 2) The closed issue is assigned to the milestone of the next release. This way, people can look up the closed issues for that milestone to see what's been fixed. (A bit of duplication with the README, but sensible IMHO). I've done this for #1553 so you can see what I mean :) Cheers! Michael On 20.10.2023 23:48, BiT dev wrote:

On 2023-10-20 23:48 BiT dev <python@altfeld-im.de> wrote:
For BIT I would prefer a) This keeps the things more simple.
The timing may be of importance when users search for "open" issues.
I assume there are not much users searching for bugs. They just open bugs not caring about duplicates. On the other hand the small amount of users searching for bugs are smart enough to also check closed bugs and our docu (README.md, etc). In the end differentiate between fixed-in-dev and released-fix won't affect much people but would complicate the management of Issues.

I would suggest the following: 1) An issue is closed when the problem is a) fully understood, and b) a fix has been committed to the "dev" branch, and c) the fix is documented in CHANGES. Therefore, a closed issue means to us: "No more work is needed here." 2) The closed issue is assigned to the milestone of the next release. This way, people can look up the closed issues for that milestone to see what's been fixed. (A bit of duplication with the README, but sensible IMHO). I've done this for #1553 so you can see what I mean :) Cheers! Michael On 20.10.2023 23:48, BiT dev wrote:

On 2023-10-20 23:48 BiT dev <python@altfeld-im.de> wrote:
For BIT I would prefer a) This keeps the things more simple.
The timing may be of importance when users search for "open" issues.
I assume there are not much users searching for bugs. They just open bugs not caring about duplicates. On the other hand the small amount of users searching for bugs are smart enough to also check closed bugs and our docu (README.md, etc). In the end differentiate between fixed-in-dev and released-fix won't affect much people but would complicate the management of Issues.
participants (3)
-
BiT dev
-
c.buhtz@posteo.jp
-
Michael Büker