April 12, 2009 at 11:26Idea of Prototype-based bugtracker
For most of my professional career as a programmer, I have been involved in bugtrackers (bugtracking, SCM, ALM, etc). At each of my work, I implemented VCS and bugtracking or worked with the existing one. I saw almost all of the decent ones, three of them were dismantled by cog: Trac, Scarab, JIRA. The only thing that I missed in this life is the so-called SaS systems, but the trouble is not great. These are very specific and niche products.
And today in the morning, when I couldn’t fall asleep, the idea came to my mind of how to implement the kernel of the bugtracker. Scarab
impressed me the most with its data model. It is almost close to what I consider ideal for a unified issue tracking system. But Scarab was thrown by developers (I wrote about this repeatedly) And me too (sic!). And now, despite all his idiological correctness, he vegetates in obscurity.
But, what was so unique about him, you ask? In Scarab, it was possible to determine the type of Issue at the root level, and when configuring a project, it could be tightened (field values, field mandatoryness, workflow). Plus, at the project level, you could define issue templates, that is, pre-fill the fields.
Those who administer JIRA on a more or less large amount of data (e.g.> 100 projects,> 1000 users,> 700 groups,> 300 custom fields, etc) know how hard it is. For example, at Polycom, 12 (!!!) people administer JIRA.
And what is the problem? The fact that different entities over which administrative tasks are performed are not interconnected in the most logical way. Some of them are tied to the project, part to the issue, and some to both of them (in fact, there are much more connections). And how should it be? It seems to me that the key element is all the same issue and all parameters should be bound to it.
Actually the idea. There is a concept of prototyping objects, which is reflected in a number of programming languages (JavaScript, Self, Io, Lua, etc) and in several frameworks (only Squeak Morphic comes to mind). The bottom line is that to create a new object, you clone an existing one and modify it, and then, based on the result, you can clone new ones. Each object knows its prototype, and changing the behavior of the prototype changes the behavior of the clones, if they do not redefine this aspect themselves.
I’ll give an example of how this might look:
Actually, you can dream up any hierarchy. Most importantly, with such a scheme, it becomes possible to individually modify individual Issues (for example, add a field or change workflow) and very flexibly influence the behavior of an object. At the same time, it remains possible to manage the entire hierarchy and replace prototypes for selected issues.
Of course, there are side effects: over time, the hierarchy grows and it becomes almost impossible to manage, but this can be solved using a convenient and intuitive interface.
UPD: a little explanation. I didn’t mean that we need to implement the architecture in Prototype-based language, but that the objects that the user and administrator are working with (issues, issue types, schemes) can be decomposed into a prototype hierarchy.
And today in the morning, when I couldn’t fall asleep, the idea came to my mind of how to implement the kernel of the bugtracker. Scarab
impressed me the most with its data model. It is almost close to what I consider ideal for a unified issue tracking system. But Scarab was thrown by developers (I wrote about this repeatedly) And me too (sic!). And now, despite all his idiological correctness, he vegetates in obscurity.
But, what was so unique about him, you ask? In Scarab, it was possible to determine the type of Issue at the root level, and when configuring a project, it could be tightened (field values, field mandatoryness, workflow). Plus, at the project level, you could define issue templates, that is, pre-fill the fields.
Those who administer JIRA on a more or less large amount of data (e.g.> 100 projects,> 1000 users,> 700 groups,> 300 custom fields, etc) know how hard it is. For example, at Polycom, 12 (!!!) people administer JIRA.
And what is the problem? The fact that different entities over which administrative tasks are performed are not interconnected in the most logical way. Some of them are tied to the project, part to the issue, and some to both of them (in fact, there are much more connections). And how should it be? It seems to me that the key element is all the same issue and all parameters should be bound to it.
Actually the idea. There is a concept of prototyping objects, which is reflected in a number of programming languages (JavaScript, Self, Io, Lua, etc) and in several frameworks (only Squeak Morphic comes to mind). The bottom line is that to create a new object, you clone an existing one and modify it, and then, based on the result, you can clone new ones. Each object knows its prototype, and changing the behavior of the prototype changes the behavior of the clones, if they do not redefine this aspect themselves.
I’ll give an example of how this might look:
Issue ------------------- |
| |
Bug --------- | Fetaure
| |
Bug in Bug in --------- |
desktop web-app |
app | |
| | |
Template Template Template
for app1 for for
webapp1 webapp2
Actually, you can dream up any hierarchy. Most importantly, with such a scheme, it becomes possible to individually modify individual Issues (for example, add a field or change workflow) and very flexibly influence the behavior of an object. At the same time, it remains possible to manage the entire hierarchy and replace prototypes for selected issues.
Of course, there are side effects: over time, the hierarchy grows and it becomes almost impossible to manage, but this can be solved using a convenient and intuitive interface.
UPD: a little explanation. I didn’t mean that we need to implement the architecture in Prototype-based language, but that the objects that the user and administrator are working with (issues, issue types, schemes) can be decomposed into a prototype hierarchy.