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:
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 ;-)
_______________________________________________ Bit-dev mailing list -- bit-dev@python.org To unsubscribe send an email to bit-dev-leave@python.org https://mail.python.org/mailman3/lists/bit-dev.python.org/ Member address: foss@michael-bueker.de