List view
Housekeeping, bugfixing, run-of-the-mill and routine tasks. It's not exiciting, but nevertheless important to not fall behind on these.
No due date•1/15 issues closedThis is for any new features and improvements to existing functionality, to make the addon better... hopefully.
No due date•0/44 issues closedThis milestone is for the ongoing effort of improving addon performance (where needed) and optimize for speed whenever it appears reasonable.
No due date•0/1 issues closedAll sources should be documented, in LDoc format. Since this certainly hasn't always happened, a milestone for the ongoing effort of revisiting and adding/improving documentation where necessary is in order. Also includes user-facing documentation, such as the project site and potentially a wiki page later on.
No due dateSometimes, stuff just works but the implemented solution isn't exactly great. This milestone should be assigned to completed functionality that fits this criteria - it would require some re-imagining to find a better/more elegant solution. If it's merely slow or needs to be refactored, there are different milestones for that. Architectural changes that don't affect individual features but the addon as a whole should also be assigned to the respective milestone instead.
No due date•0/2 issues closedIf certain modules are conceptually lacking or need streamlining, or have become obsolete/ambiguous/bloated, they should be revisited to make sure the architecture doesn't become a jungle.
No due date•0/1 issues closedAnything that works but is in danger of becoming or has already turned into spaghetti code should be revisited at some point and cleaned up. This milestone is for collecting those tasks.
No due dateAssigned to tasks that are related to the tests provided to cover as many parts of the addon's functionality as humanly possible, and to verify code is behaving as expected at all times.
No due date