| > > Additionally, some projects close issues once the mainline has addressed them even if the fix isn't in a released version. > And that is a general issue with the maintainers not understanding what they're doing, or not understanding how issue trackers work. > If you close an issue that is still present in the current release, then you're doing it wrong - with one exception. If it is in fact functioning as intended and the issue was just a misunderstanding, then explaining that and closing the issue makes sense. (But even then you might want to update the docs or helptext or something to prevent future misunderstanding, if it's confusing enough.) The concept of an issue tracker was not bequeathed to us from on high. There is no single "right" way to do it, nor can you (context free) tell someone they're doing it "wrong". Some people use issue trackers to inventorize bugs in current releases. Some people use them as a dev's todo list. If you do the latter, closing the issue once you've implemented the fix is perfectly reasonable. > Closing an issue just because you don't feel like looking at it today just means that someone else will open a new issue tomorrow to report the same thing. And any history, workarounds, steps to replicate, etc. in the old issue will be lost/disconnected. That's not doing anyone a favor. It feels like it's doing the developer a favour. |