Hi everyone,
Work on the bh_core_experimental branch of bloodhound, which is where I'm
playing around with ideas of the new core model, is a bit slower than it could
have been. I was hoping that I would get a bit more input at the time but I
imagine that I did not make that clear enough.
So, at the moment, the model is very basic, allowing text fields to be added to
a ticket with no particular restrictions. One way this could play out is to
keep the core models roughly this simple or we could build in the concepts of
field types in a more concrete form.
For instance, we are likely to require fields to keep track of things like
users (e.g. who owns or is working on a ticket) and dates (e.g. to specify a
due date). You might imagine that one advantage to having a defined set of
fields is that we could better control the ways that fields are stored so as to
be more appropriate for the type, so as to make things like comparison or
ordering more appropriate or even allow handling of fields that can take
multiple values in some way.
Alternatively we can go with the concept that we can describe pretty much
anything in text. This still leaves similar tasks of defining how fields are
treated but the basic ticket delta remains a text diff consistently across all
fields.
The user part of the model is also an interesting thing to have to take into
account. One question in particular here is whether the Django user model
should be tightly coupled to ticket ownership. We will almost certainly want to
tie the Django user models to permissions but we could ask whether it is
important to insist that assignment of tickets requires such real users. I am
not too worried about the idea of tickets getting lost in the system by not
having such a direct connection to a real user. Users being removed from the
system is not an unlikely event so having ways to discover these kinds of users
will be useful anyway.
On a different note, I have also had some further thoughts around the label
concept I was discussing a while back. Overall, I am still pretty happy with
the idea of generalising concepts like versions, milestones and components to
be categorisations applied via a label. What this lacks is a way to capture
such information as dates (release or due for versions and milestones
respectively) descriptions and general ownership. We could look at bringing the
full flexibility of the ticket model for adding such metadata by having a
ticket with such a label representing the label as a whole. At that point, with
the addition of the concept of ticket links, it would be possible to use this
as a mechanism to state that a ticket is 'in' a version, milestone, component,
etc, by linking to the appropriate ticket.
Anyway, all thoughts will be welcome as usual.
Cheers,
Gary
