Prototype-based bugracker idea
Most of my professional career as a programmer I deal with bugtrakers (bugtracking, SCM, ALM, etc). In each of my work, I implemented VCS and bugtracking or worked with the existing one. I saw almost all of the worthy ones; I sorted out three of them on a cog: Trac, Scarab, JIRA. The only thing that is 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 could not fall asleep, an idea came to my mind how to implement the core of the bugtracker.
I was most impressed by Scarab with my data model. It is almost close to what I consider ideal for the unified issue tracking system. But Scarab was thrown by developers (I wrote about this more than once). And I, too (sic!). And now, in spite of all his idiological correctness, he is mired in obscurity.
But what was so unique about him, you ask? In Scarab, it was possible to determine the Issue type at the root level, and when the project was configured, it could be customized (field values, required fields, workflow). Plus, at the project level, issue templates could be defined, that is, pre-filled fields.
')
Those who administered JIRA on less or more data (for example,> 100 projects,> 1000 users,> 700 groups,> 300 custom fields, etc) know how hard it is. For example, in the Polycom company, JIRA administers 12 (!!!) people.
And what's the problem? In 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, some to the issue, and some to both (actually there are much more links). And how should it be? It seems to me that the key element of this issue and all the parameters should be tied 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 you change it, and then you can clone a new one on the basis of the result. Each object knows its own prototype, and changing the behavior of the prototype changes the behavior of the clones, if they did not redefine the aspect themselves.
I will give an example of how this might look like:
Actually you can fantasize any hierarchy. The most important thing is that with such a scheme it is possible to individually modify individual Issues (for example, add a field, or change the workflow) and very flexibly influence the behavior of the 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 with the help of a convenient and intuitive interface.
UPD: a little explanation. I didn’t mean that the architecture should be implemented in the Prototype-based language, but that the objects that the user and the administrator work with (issues, issue types, schemes) can be decomposed into a prototype hierarchy.
And today, in the morning, when I could not fall asleep, an idea came to my mind how to implement the core of the bugtracker.
I was most impressed by Scarab with my data model. It is almost close to what I consider ideal for the unified issue tracking system. But Scarab was thrown by developers (I wrote about this more than once). And I, too (sic!). And now, in spite of all his idiological correctness, he is mired in obscurity.
But what was so unique about him, you ask? In Scarab, it was possible to determine the Issue type at the root level, and when the project was configured, it could be customized (field values, required fields, workflow). Plus, at the project level, issue templates could be defined, that is, pre-filled fields.
')
Those who administered JIRA on less or more data (for example,> 100 projects,> 1000 users,> 700 groups,> 300 custom fields, etc) know how hard it is. For example, in the Polycom company, JIRA administers 12 (!!!) people.
And what's the problem? In 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, some to the issue, and some to both (actually there are much more links). And how should it be? It seems to me that the key element of this issue and all the parameters should be tied 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 you change it, and then you can clone a new one on the basis of the result. Each object knows its own prototype, and changing the behavior of the prototype changes the behavior of the clones, if they did not redefine the aspect themselves.
I will give an example of how this might look like:
Issue ------------------- |
| |
Bug --------- | Fetaure
| |
Bug in Bug in --------- |
desktop web-app |
app | |
| | |
Template Template Template
for app1 for for
webapp1 webapp2
Actually you can fantasize any hierarchy. The most important thing is that with such a scheme it is possible to individually modify individual Issues (for example, add a field, or change the workflow) and very flexibly influence the behavior of the 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 with the help of a convenient and intuitive interface.
UPD: a little explanation. I didn’t mean that the architecture should be implemented in the Prototype-based language, but that the objects that the user and the administrator work with (issues, issue types, schemes) can be decomposed into a prototype hierarchy.
Source: https://habr.com/ru/post/57057/
All Articles