|
7 | 7 |
|
8 | 8 | ## tickgit 🎟️ |
9 | 9 |
|
10 | | -`tickgit` is a tool to help you manage tickets, todo items, and checklists in a codebase. Use the `tickgit` command to view pending tasks, progress reports, completion summaries and historical data (using `git` history). |
| 10 | +`tickgit` is a tool to help you manage latent work in a codebase. Use the `tickgit` command to view pending tasks, progress reports, completion summaries and historical data (using `git` history). |
11 | 11 |
|
12 | 12 | It's not meant to replace full-fledged project management tools such as JIRA or Trello. It will, hopefully, be a useful way to augment those tools with project management patterns that coexist with your code. As such, it's primary audience is software engineers. |
13 | 13 |
|
@@ -41,21 +41,12 @@ Check out [an example](https://www.tickgit.com/browse?repo=github.com/kubernetes |
41 | 41 |
|
42 | 42 | #### Coming Soon |
43 | 43 |
|
44 | | -- [x] History - get a better sense of how old TODOs are, when they were introduced and by whom |
| 44 | +- [x] Blame - get a better sense of how old TODOs are, when they were introduced and by whom |
45 | 45 | - [ ] Context - more visibility into the lines of code _around_ a TODO for greater context |
46 | | - |
47 | | - |
48 | | -### Why is this useful? |
49 | | - |
50 | | -This project is a proof-of-concept. Keeping tickets next to the code they're meant to describe could have the following benefits: |
51 | | - |
52 | | -- Tickets live with the code, no need for a 3rd party tool or system (anyone with git access to the repository has access to contributing to the tickets) |
53 | | -- Updating a ticket's status and merging/committing code are the same action, no need to synchronize across multiple tools |
54 | | -- Source of truth for a project's ticket history is now the git history, which can be queried and analyzed |
55 | | -- Current status of a `goal` can be reported by simply parsing the repository's `head` |
56 | | -- Less context switching between the codebase itself and the system describing "what needs to be done" |
57 | | - |
58 | | -Generally speaking, this is an experiment in ways to do project management, within the codebase of a project. With a `git` history and some clever parsing, quite a bit of metadata about a project can be gleaned from its codebase. Let's see how useful we can make that information. |
| 46 | +- [ ] More `TODO` type phrases to match, such as `FIXME`, `XXX`, `HACK`, or customized alternatives. |
| 47 | +- [ ] More configurability (e.g. custom ignore paths) |
| 48 | +- [ ] Markdown parsing |
| 49 | +- [ ] More thorough historical stats |
59 | 50 |
|
60 | 51 | ### Installation |
61 | 52 |
|
|
0 commit comments