4 ms·
It took me a bit of "Selling" to management to begin to use Github issues as a solution at a number of organizations but every time I have it has been a rousing
by trcollinson 11y ago
It took me a bit of "Selling" to management to begin to use Github issues as a solution at a number of organizations but every time I have it has been a rousing success! Most of the concerns around using issues have been that there "aren't enough fields for all the things we want to track on an issue." After a bit of discussion it is usually decided that they should try to track without so many fields and see what happens.
Ultimately, people love the simplicity and the integration with the repository. I know for a fact that GitLab's has a very similar mechanism and works wonderfully. Good suggestion and a very successful one!
- WorldMaker 11y agoIssue tracking is one of those areas in computing where there's a compulsion to over-organize things and store a lot of peripheral information that may or may not be germane to the actual problem of issue tracking. It's fascinating how much applying the YAGNI [You Aren't Going to Need It] principle to Issue Tracking reveals. A lot of fields are either to duplicate stuff that should already be searchable (in the main body, for instance) in a good issue tracker [1]. A bunch of other fields are business process related and it's not surprising how many of those business processes themselves could use a good YAGNI refactor, and the few that remain after tree-shaking are often easy enough to store in a label, a "tag" in the title of an issue, or a status on a kanban board. [1] I honestly think that a lot of blame goes back to the very slow search of early issues trackers (including and especially, but not alone, Bugzilla) and needing to lump things into specialized fields to get any sort of search improvements.