DITS Origin
One day awhile back, I was working on developing a blog application using Python and Django. I came to a point where I needed to keep track of bugs, issues, and items that needed research. How was I going to do this? I could use GitHub issues, as I keep the project in a repository. That would work fine, but I would have to keep switching context from my IDE to GitHub issues. Eventually I would need to start tracking issues on GitHub, but I felt where I was at in the development process, that was not the way I wanted to go. So, what I ended up doing was creating a project.its file and dumped issues and whatever else that needed researched into it. Although this worked, the file ended up being an unformatted mess and difficult to track issues, especially if there were a lot. What was I going to do?
I did some research to see if I could find an open source solution, but all I could find was applications geared toward organizations and large teams. Those are great if you work in that kind of environment, but too heavy for just a single developer or a small team of two or three. This is were I came up with the idea of creating my own issue tracking application. The application will be able to track issues/problems or anything for multiple projects and for multiple areas. So, that means the developer will be able to track “items” for let’s say work, personal, or learning, etc., and have multiple projects under those areas. It is an awesome design and will work well for the lone developer.
My application is called DITS, Developer Issue Tracking System. I am in the early development stages of the project. I have most of the core back end and a good amount of the front end web application finished, but still have a lot of work ahead. I work on it a few hours a day or when time permits; It is an ambitious and interesting project. I’ll post more as I make progress.