I'm thinking about bringing back a project I first created when I was just starting programming: a local-based issue tracker.
My original thought ...
For further actions, you may consider blocking this person and/or reporting abuse
Should the data be held in a separate file in the repository?
I'm thinking this might lead to issues where you have to manually merge a machine-generated JSON file, which (besides being no fun) could create problems.
An alternative could be some kind of human-readable (markdown/YAML) issue object embedded in block-comments inside the source-files? If you remove one of these files, for example, any issues pertaining to that file are removed with it.
Like some kind of
TODOannotation on steroids?Waking up this morning, I just thought of building into the issue tracker tool the ability to handle conflict resolutions, so you wouldn't have to do that manually; the interface would prompt you.
I don't dislike the idea of having the block-comments, but given that I (and my team) already comment heavily, that might turn into line noise very quickly.
The other issue, I believe, is that there are many scenarios where I will delete a file so I can start fresh, but I don't want to remove the 20-some-odd issues relating to it, since I'm refactoring.
Third, I typically use
TODOannotation for self-reminders that don't quite warrant an issue, or else to remind myself EXACTLY where I left off during the previous coding session. They rarely stay in place for long.However, perhaps we can use the Git hashes of files to create direct associations between files when necessary.
I do know that conflict resolution, however friendly we make it, will always be a potential issue. That said, I think it would usually show up only if two people are working in the same code territory, which we try to avoid in active teams anyhow. This could almost become an advantage in some cases, because any external modification to a task we were working on would not be able to escape our notice.
What if a commit fixes a bug, but it's not marked as fixed before in a later commit? Then you wouldn't have the implicit connection anymore.
Though I guess sometimes having an implicit connection is better than never having one, people just have to make sure to not commit an issue as solved in a separate commit if they find out after it's pushed.
Maybe an optional field to specify what commit an issue was fixed in? Then the CLI could have an option to look at HEAD similar to how git does.
I love the idea to link issue (and fixes) to a git commit. This is something we don't find in tracker.
I don't use git bisect but maybe another field to specify where the issue started can be useful too.
I definitely agree! That's one of the features I love about Phabricator Maniphest: you can link commits, pull requests (Differentials, on that platform), and issues together in any fashion.
I think part of this is a matter of training developer habits. Since the commit would typically go through a PR, the lack of a closed task could actually be something a reviewer could catch. But, since what's done is done, the developer would still need to manually associate the task with the commit.
Perhaps it would be useful to have some sort of optional notation: you could say
-1for the commit number, to say "back one".I think consistency with git would be essential, so HEAD1 and HEAD~1 and short/partial hash
I like the idea. It's something a colleague and I thought about a lot while working in QA. Essentially, issues are nothing more than versioned documents...
...except, the details. There are hundreds are minor changes made through a typical issue triage, and/or randomly through the day.
There are also log-type entries, where details get appended, rather than modified. Though this is something I wish source control supports as well -- like feature appending logs.
You'd still need a front-end and indexer to support searching and issue listings.
The fundamental idea seems sound, but there's a lot of those damn details. Though I'd not likely support the idea of the code and issues being in the same repository -- the issues have their own lifetime, and may not be code specific.
Well, that there's no saying you must put the issues in the same repository. Because it's just a file, you could track it in another repository, a cloud share, whatever works for your team.
I think you bring up a good point: comments and logs. That makes me think that this is beyond one file. We could use hashes to associate issues with individual files for comments (organized in a dedicated directory), so those won't become merge conflicts.
As I mentioned, I'll build a front-end for this - an application GUI, a CLI interface, and a VSCode plugin. That'll offer the search, browse, and modify tools.