Tag Archives: bug-tracker

DragonU Bug Tracker Dev – Milestone 1

Posted by Jacob Santos on February 6, 2011 Comments Off

Framework

I decided to build my own framework using Zend Framework as a base. The basis of which is going to have a mismatch of directories. I might look at Habari, Fuel framework, and Kohana framework to see how they structure their directories and files. At this moment, I’m going a mix of WordPress and what I remember from CodeIgniter. Not the best choice to be sure. However, I plan on improving the nonsense after I go over certain details and get the base working how I like.

I switched from Fuel, because Zend Framework has more of what I need to get started faster. The only downside is that I need to setup the controllers and functionality. I might instead, create a branch, that uses CodeIgniter 2 for the MVC for rapid prototyping to be sure that the application is how I want it while I build the official framework for which the application is going to be based. I’ll create this as a branch, if I am going to develop this way. I’ll have to see how quickly I can get the base up and running.

If I get this working, I’ll most likely use it for my other projects, but I might attempt to implement the features into FUEL instead.

Core Application

The core application, I’ve decided is going to be based on Zend Framework and I’m going to make the following changes:

  1. Kohana Style Front Controller. The front controller is going to allow for modules and plugins, which will also have controllers, so most likely, I’m going to set it up to where it first searches the official Router and if it is not found to look at the directory structure for the controller. I like the way CodeIgniter and its clones allow you to easily add controllers without actually setting up the routing, except for the more advanced purposes. I’m going to implement a hybrid system between Zend Framework predefined routing and CodeIgniter style routing.
  2. WordPress Style Script and Style Loaders. I hate having to change the headers and what not and using styles and scripts that aren’t even used on the page. The code will not be from WordPress, since I’m going for New-BSD license, but I’ve already built something similar, and the algorithm is simple, so I won’t have to worry about this feature taking too long. I am going to attempt to add script collisions to prevent duplicate javascript files from being added.
  3. WordPress Style Filters and Actions. I’ve already started code for this and I’m think I’m going to go an easier route for implementing the feature. It will be the 3rd rewrite and 5th overall. I’m looking at probably 4 or 5 hours given how long the other attempts took.
  4. Themes. I do like the way WordPress does themes, so I’m going to attempt to implement this. I’m going to include an API for extending existing themes, setting dependencies, and using the default theme if missing files. The differences from WordPress is that Modules will also define default templates that themes may override. It will be done in such a way to prevent conflicts; the theme module template files will be in a separate directory, ‘modules’ and use the name of the module. In this way, a theme does not need to know about all modules, but may provide for those it knows about and popular themes.

    It also allows for placing themes and their additions in one place. Users do not need to put module theme files in the module directory, just the directory of the theme they are using. Given the parent-child nature, if they want to support multiple themes, they can put the modified theme file in the default theme (which is a parent of every theme by default) or the parent or child theme.

  5. Modules. See below section on this.

    The goal of the modules is to provide additional features for the Bug Tracker that can be enabled and disabled. Modules may have plugin support, theme support, but most importantly will have separate controllers and models and are basically separate and mini applications for the bug tracker.

  6. Plugins I want the difference between plugins and modules to be that plugins are mostly filters and actions for existing hooks, with maybe an options page. For this, I’m going to include an API for setting the options page, if one is needed. I really want to emphasize the purpose of plugins over modules, so that the confusion of when you would implement one verses the other. I have a feeling that eventually one or the other will win out if I don’t force the issue. Modules will offer Plugins as well, and this may help with the issue of when you would do a Module verses Plugin.

    Probably include something similar to WordPress widgets, but I always hated how it was implemented in WordPress, so I’m going to go for something different.

  7. Hybrid Settings Configuration. Setting up and configuring the application should never require editing files, unless the initial database configuration file could not be made. The problem is that this often requires using the database to store the settings. I really don’t like doing that. The base application will attempt to create PHP configuration files for core and module configuration, but will use a database table, if that fails.
  8. Enabling Plugins and Modules will also have two ways to do so. You could enable modules and plugins by including a file named, “.enabled” in the module or plugin directory, but enabled modules and plugins will always be checked in the database. I might also include a third way, which is a separate config file, which loads modules and plugins. I may also attempt to create this similar to configuration.

Extensible Administration and Separate Front-End

One of the concepts I’ve thought on was having a default administration for the application that modules and plugins could extend and themes could customize. I figure actually that customization will be very limited. Only the header, navigation placement and footer will be editable, as well as the CSS and Javascript.

The reason for this is that modules and plugins have their own controllers and I don’t want to force mixing or moving directories. I want modules to be contained applications that all you need to do is drop it into the modules directory and enable it. To this end, the administration of modules has to be combined with the base application administration controllers. It should also give modules complete controller functionality within their scope.

I was actually thinking about including a member profile as a separate system similar to the administration. However, this I don’t think will be necessary as modules and plugins will be able do this anyway. The separation was given the fact that navigation and theming will be different from the front-end and back-end and therefore will need a system to ensure cohesion.

Installer

WordPress has spoiled me, I believe that any application that does make it extremely simple to install, isn’t worth using. To this end, there will be an basic installer that checks against certain requirements and runs queries for installing the database tables.

In the future, I want to allow downloading plugins, themes and modules during the installer process, as well as configure them. This milestone, I’m going to simply work on simple database specific configurations, so that the application can be installed. The rest of the configurations will be done in the administration.

Modules

I’ve already discussed some of my plans on this feature, but really, the purpose of modules is to separate several features of the application into components that the administration can enable to extend what the base application can do. I figure if all you want is simply a ticket tracker, that simply install the application and run with it. If you want a support ticket feature, then you’ll enable the module that implements that feature or any feature you want.

Several planned modules, but not in this milestone:

  • Support Ticket.

    Help and support tickets that aren’t bugs, but would be helpful for future requests and reference. Might be used internally for customers. Will be extremely simple in structure and UI and include public option for allowing anyone to create a support ticket.

  • Company Projects.

    The base application will assume that only one company is using the application and therefore all projects belong to it. Again, this will be a boilerplate module for extending and allowing for this feature. This will really force the base application to allow setting the default controller, overriding defaults, something that is already planned, but in a way to allow for cascading default controllers.

    The feature will most likely test the cascading controller in a certain of filter system for setting the priority of controllers. So you could have segments matching against multiple modules. This may require allowing the administrator to set up the priority in case there are conflicts.

    So for /{Company}/{Project}/

    The company module will add its priority as 1 and the Project priority, which is in the base application will be priority 10. So in theory, you could have another module come along and add region, which would make it, “/{Region}/{Company}/{Project}/” and since the Region will also be priority of 1 will notify the administrator of this conflict and force modifying the priority, so Region is always first and Company is always second.

  • Repository Activity

    There is a difficulty with implementing this feature in PHP. That is, that the implementation will require command line applications and also access to the CLI git, svn, hg, etc on the system for the repositories. Given this requirement, as well as the esoteric feature set in Trac, Redmine, etc. I mean it seriously isn’t strictly necessary for bug tracking and managing projects. It is “nice to have” feature and I plan on using it for statistics of developers.

    One element that I’ll implement when I see how it is done in other bug trackers and project management applications is how to get the application to work with Tortoise SVN and Tortoise GIT ticket features. I’m going to attempt to add this as part of core, but the ability to close tickets in the repository commit log will have to be part of this module or implemented as a plugin.

Note About Configuration

The configuration will be file and database based. An attempt will be made to create PHP file configuration, but given any permission issues, the database with caching will be used instead. The purpose is to make the application as easy to modify as possible without having to modify any PHP files. The application is require as little work as possible to setup and configure as possible, but also attempt to be as efficient as possible.

Planned Features In Later Milestones

The first milestone is about getting the base framework working to start adding application functionality. Other planned functionality includes automatic upgrading of the application, modules, plugins and themes.

This will quite possibility use the same system as WordPress, but implemented for this web application framework. The library that WordPress uses is freely available and I believe uses a license compatible with this web application. I will need to implement it separately as WordPress had to include work arounds and WordPress specific code to get the installer and upgrader working. The worse case is to use a separate library or libraries for implementing a similar feature. Well, actually, what is cool about these libraries, is that it might allow for using file based configuration even if access is not granted for creating those files, since the main library is creating files using FTP or SSH tunnel.

Possibly Related Posts:


State of Bug Trackers

Posted by Jacob Santos on January 14, 2011 Comments Off

It is disappointing to me that the best Bug Trackers out there are web applications that you can’t access the source to. It is disappointing, because these web applications often lack some feature that make open source bug trackers great. The best of these that do combine the best of both worlds require payment and often have more features than most require.

I think the problem has always been that bug trackers have been built by programmers for programmers based on specifications that the programmers thought others would require, need or comprehend as useful. There are basic features for organization of bugs or tickets, but most of the time these are made for programmers. An user doesn’t really know what milestone or version the ticket will be completed, they might not even care. They probably don’t know how the administrators define each component and I doubt most really care.

The key element of most web bug trackers are that they are simple and easy. They remove most of the cruft and useless features that plague open source and other more complicated bug trackers. The break it down to the fundamentals of tracking bugs and leave you to have at it. Most of the time this is all you will need. When you get to the point where the basics are no longer cutting it for you, then either more features are being offered by the service or you move on to a more advanced platform.

I want something like this in an open source product that can be easily and quickly extended. I want something that takes the best of Trac, Get Satisfaction, 16 Bugs and maybe some of Fog Bugz.

Goals

The goal is to look at what makes these web applications great and include them in one package for people to use and hopefully extend. The goal is to also allow for enabling and disabling features as they are needed. If all you need is a 16 bugs (which is really more of a Basecamp clone), then well, that is what the basic package will be and you simply don’t enable any of the other features.

Features like roadmaps, components, reports, searching etc from Trac can be enabled, customized and configured later. However, what the web application will never be is anything more than a simple, but extendable bug tracker. There won’t be a Wiki, you would instead link to one, but I do hope to have some support for built-in linking of wiki, similar to the Trac feature.

Get Satisfaction

Looking at Get Satisfaction, I can really see why it will become popular in the future for a bug tracking web application. It is simple. Really incredibility simple, but well there are some navigation problems, but they are so minor that navigating the web site after the initial learning curve is not an issue.

It does what bug trackers should have been doing and really, I think you have to see it in action to realize its effectiveness. It allows you to not allow list problems, but also questions, request features and give praise. I think why it is so great needs a little bit of explanation, in case you don’t realize it already.

Why is giving praise important?

It tells the developers what people think they should be working on. It tells the developers and people making plans for the next release what features really made a person’s day; the one feature that sold the product for them. It also continues motivation for open source projects where no money is being made. It is really kind of depressing to read over defects all day, but with this feature on the site, people can tell you how much you helped them and that they care.

Why so simple?

If you think about it, what does the customer or user really care about? They really only care about telling you what the problem is and then leaving. Thinking about it some more and Trac is really setup to be confusing. How many people know which component a ticket belongs to? 1 or 2, 0 if the person who set them up was just winging it. How do you set the component when the ticket might belong to several? Throw darts most likely. What about the roadmap? Everyone thinks their ticket should be completed before the next release, but how often does that happen?

The power of Get Satisfaction is that it doesn’t burden the user with the minute details that really only the programmers care about or even know. It allows the customer or user to get in tell you about their problem and leave. In some ways Lighthouse is extremely similar, but mostly geared towards only defects and features with a bit of Trac thrown in for good measure.

I do like the bit about Giving Praise, along with asking for features. I’m thinking about including it. It won’t be that difficult to add and will work similar to everything else. It will just be a matter of allowing the administrator to disable it if so desired.

Problems of Get Satisfaction

I think Lighthouse solves many of the organization problems with Get Satisfaction. The major and only problem I can see with Get Satisfaction is the lack of milestones or separation of tickets. It is just one big list and when you have many tickets, praise, and feature requests, it can be a little overwhelming to go through them all. The other problem is the matter of duplicates. It is either difficult or impossible to mark something as a duplicate of something else.

Project Management

The strength of Fog Bugz is its project management and well, their other features as well. The initial version, I’m not going to focus on Project Management or Agile features, unless more time comes up.

I do think that this is what Trac is lacking. It is difficult to get metrics on what people want, on what people have done, how close the project is to being completed, etc. Reports and graphs are one aspect of this. The other is figuring out what programmers should focus their time on.

In my product, I want to initially focus on completeness of bug and feature tickets. I want to include ticket dependencies for features and bugs. I want a metric for whether a bug or feature is complete and for this I want a report that tells programmers which tickets they should be looking at.

Reporting

Ticket Completeness

The term ticket completeness is the workflow of the ticket from the initial report from the customer or user to the time is fixed or included into the project. It does not include tickets that are closed for being invalid or another reason.

  1. How Detailed is the Report? Does it include a detailed or proper description? Does it include correct steps to reproduce the issue? Does it include a workaround? Does it include Expected event -> Actual event descriptions?
  2. Does it have Attachments? Does it include a patch, a prototype, screenshots and, or other helpful files for reproducing or understanding the problem or feature?
  3. Does the ticket have comments? Are the comments helpful, debating the issue, or querying for more information? Do the attachments have comments, requests for feedback? Have the patches or prototypes been accepted?
  4. Does the ticket, defect or feature, have up votes telling the programmers what the users and customers care about?
  5. Has the extra information been completed: things like roadmap, version, OS, etc
  6. Time the ticket has been active, time the ticket has been opened, time the ticket has been stale.

    In a perfect world, every ticket will receive feedback within 24 to 48 hours. Whether it is a comment saying the ticket has been looked at and, or reviewed or a patch has been submitted. It is possible to include some of these feedback mechanisms into the web application. Whether the ticket has been looked at will include whether the core team has looked at the ticket or patch or whether a trusted member has looked at it or if someone else has looked at the ticket. These are easy features to include and might have some pay off for the reporter.

    This is really to tell the programmers which tickets are not receiving proper attention given the other criteria. It will also inform based on how complete the ticket is. If a ticket has a patch and the patch has not been reviewed, then why not based on a given number of days?

Giving programmers and contributors information to make wise decisions.

The programmers managing the project and the contributors should be able to see which tickets are being addressed and how well. They should also be able to quickly find tickets that haven’t received proper feedback and tickets that can possibility go into the next release.

I think this is the first step to project management features. The reports will be built-in, but completely optional. The emailing to the reporter on updates will also be optional and will be a single check box. The key will be to gradually give the reporter the impression that their ticket is being addressed and help the programmers address tickets.

Possibly Related Posts: