"lodash style issue mangement"

[GerHobbelt]

https://twitter.com/samselikoff/status/991395669016436736

[GerHobbelt]

(reminder for self: in Twitter click "Show this thread". for the next time you're confused. 😉 )

[GerHobbelt]

(came by this via https://github.com/11ty/eleventy/issues/379#issuecomment-502390648-permalink)

[GerHobbelt]

Conclusion after having considered this and inspected the way I work with issues:

It's not a good approach (for me at least). Why?

• closed means closed. As in: done.

  At least that is how I treat github issues in any project: closed status is one of the strongest signals the issue tracker has and I don't want to increase the potential chaos by watering that signal down to a level of possibly maybe not.

• We've got labels for that sort of thing: I took the idea of Unicode emoji enhanced labels off another project (forgot which one) where it worked very well; don't recall if I ripped off their emoji choices too, but I've set this set of labels to cover the 'lodash' idea (and then a whole bunch more):

duplicate

⛷performance

🐛bug

👀FYI only

👮invalid

👮wontfix

📖documentation

🕵code review

🕵investigate

🕵TLC

🦸‍♀️enhancement🦸‍♂️

🧑‍🤝‍🧑help wanted🧑‍🤝‍🧑

• the label called

  🦸‍♀️enhancement🦸‍♂️

  is specifically useful for this: anyone can filter issues on label and thus produce the set of feature requests. By not degrading the power of the closed state signal you can also easily discover which features have been added to the software and which ones are still pending for whatever reason.

• I think the unmentioned benefit of the lodash approach to issue management is a premium score on the 'issues resolved/closed' KPI which is used by many OSS monitoring and reporting sites on the liveliness / activity of an OSS project, artificially raising the quality metrics. Smell like a "perfide prikkel" (perfidious stimulus) to me.

So after having considered it and its mentioned and unmentioned merits, I decide not to go that way.

At the time of this writing, Qiqqa has 126 open issues, many of which would become 'closed' if I were to use the lodash process, but most of these address very tough upgrade paths which need quite a bit of work (and not just at level of keyboard-🐒 😉 ). While it doesn't make me happy, I still think it is better to keep them open, including their near-duplicates, until the issue has been fully addressed and thus can be closed for real.

Any follow-up (bugs in the new work) from such actions can then, as usual, be filed in new issues, which can reference the closed issues, but I'd rather measure progress that way than artificially 'disappearing' the issues here. (Yes, while I felt immediately attracted to the lodash approach, it also feels artificial at a deep ethical level, but that's just me and my inner workings 🤡 )

So... this has been considered and WILL NOT be done.