Hi Allan,
Thank you for the suggestions. Please take my word for it that the input is
definitely appreciated.
I do want to delay discussion on how the front-end could work, or at least
limit that discussion in this thread. The main thing I want to focus on here is
getting agreement on the core platform. OK, temptation gets the better of me..
hopefully it is enough to say that I would see React as a reasonable choice for
helping build the web front-end but Allan appears to have the gist of what I am
expecting.
I'm also not hugely worried about anything being particularly slow for the
moment. Slow operations will be possible to speed up later. I will attempt to
keep the scheduler method in mind for the future as I might not have come up
with that as an obvious option!
Cheers,
Gary
On Sun, 11 Mar 2018, at 9:35 PM, Allan Swanepoel wrote:
> Possibly take a look at what has already been done using Django in this
> arena?
> One project that jumps out with some Google foo is
> https://djacket.github.io/
>
> Also, if you want to separate (loosely couple) the front-end and the
> back-end, possibly build the whole front-end with some js framework like
> react?
> All the functionality would be provided by the api, and all you need is
> some Ajax calls.
>
> For the slow stuff, possibly make these more asynchronous and use some form
> of scheduler (celery / ampq bus) to offload the work. Again, the result is
> posted back via the api.
>
> Just my 2c's worth
>
> On 11 Mar 2018 23:21, "Gary" <gary.mar...@physics.org> wrote:
>
> > Hi everyone,
> >
> > Sorry it has taken so long to get this written. With the understanding
> > that we have expressed the desire to move away from Trac as the base for
> > the project, I'd like to put forward the following as an initial proposal
> > for the way we progress. You should not expect that this is high on
> > details. I only intend to provide some guidance around the concepts that I
> > would like to see used. I am hoping that this will be enough to get a
> > reasonable idea of what the core model might look like.
> >
> > In broad terms I am proposing that we
> > * take the opportunity to design the project from the ground up as opposed
> > to attempting to build up the existing interfaces
> > * build the project using the Django web framework
> > * separate out a core sub-project with a well defined REST api for a
> > frontend UI sub-project to build upon
> >
> > The rest of this proposal sets out to define parts of the core sub-project.
> >
> > The core should provide enough services to support the main part of a
> > issue tracking UI. I am also expecting there to be further sub-projects to
> > support additional optional functionality.
> >
> > The core sub-project will probably provide a basic UI to make progress
> > ahead of work on the UI sub-project. I am not looking to define the UI
> > sub-project any further in this proposal although it is likely that it will
> > be highly dynamic, perhaps making use of websockets. The basic UI of the
> > core project should remain well-maintained throughout the life of the
> > project but at the moment my expectation would be that it is a no-thrills
> > interface.
> >
> > Back to the core sub-project, I am looking for this to be built on the
> > following concepts:
> >
> > #0 a change in nomenclature from product to tracker as the top level
> > #1 uuids for pretty much everything
> > #2 tickets as the accumulation of ticket change events
> > #3 'labels' and 'label types' as a unifying concept for categorisation of
> > tickets
> >
> > One of the early decisions made in handling of multiple projects in
> > bloodhound was to call this feature multi-product. The reasoning for this
> > was that the term 'project' is overloaded (if I recall, there may have been
> > an excuse to add projects as a layer in bloodhound that could be used to
> > group tickets across products.) I would like to see the basic functionality
> > brought in to handle the ability to host multiple projects (in the top
> > level organisation sense) but change the nomenclature to tracker to be as
> > generic as possible. To be fair, the name of the feature may not matter so
> > much as I would also like to see users given the ability to define their
> > levels of organisation to a greater extent. More on this in the discussion
> > of #3.
> >
> > Note that I will use the term tracker in the rest of this proposal where
> > you might prefer to see product or project.
> >
> > The idea behind #1, uuids, is that it may be useful to be able to
> > unambiguously identify instances of objects even across bloodhound
> > instances. Pending decisions on how tickets are referenced, these uuids
> > could be used as a reference that is unchanging as it moved between
> > trackers.
> >
> > How tickets are stored as a whole is also worth tackling, which is what #2
> > is trying to broadly decide. Here I am suggesting that the state of a
> > ticket can be built up from a query that collects all the change events and
> > applies the deltas in order. This could prove to be a slow process so at
> > some point we may want to look at keeping a record of the current state or
> > a checkpoint but, given that ticket views are expected to show the history,
> > these are details that are required anyway. I suggest that we can look at
> > optimising for speed later. Knowing that we can update a ticket from deltas
> > may be useful.
> >
> > Finally, I am suggesting in #3 that as much as possible we generalise
> > ticket categorisation. Categorisation is a central concept to capture and,
> > in trac we inherited categorisations such as statuses (open, in progress,
> > etc), types (bug, enhancement, task, etc), milestones, versions, etc, and
> > these had separate implementations. What I would like to see is that, while
> > we might provide an initial set of ways to categorise tickets, we should
> > allow users to add the categorisations that they require. I'm suggesting
> > calling this generalisation 'labels' and 'label types' (though we can
> > bikeshed that if we like!)
> >
> > There are a few ways to look at implementing labels as we could look to
> > capture a set of common kinds of collections so that there are types of
> > 'label types', as it were. What I mean by this is that you can have labels
> > that are simply a tag, perhaps some types of labels should have
> > descriptions, some might have dates associated with them. Beyond that we
> > would need to know where a label can be allowed to coexist on a ticket with
> > others of the same 'label type'. A lot of these aspects could influence how
> > you might want to display them.
> >
> > At the moment I believe that we can probably get away with a common model
> > across all label types and we can provide users with the tools to define
> > what you can do with labels of a given label type via the properties of
> > that label type.
> >
> > As you can see I have a lot to say about these labels. Another thing that
> > could be useful would be to be able to have label types and labels that are
> > available to a specific tracker, globally or even to a set of trackers. To
> > deliver this, label types and labels need to be able to be associated with
> > a variable number of trackers.
> >
> > We also need to be able to define workflows in terms of transitions
> > between labels and potentially how they are affected by other labels. I
> > think it is suffice to say that I would like to see an implementation where
> > users are able to define workflow transitions with a great deal of
> > flexibility in the label types that are involved.
> >
> > From the point of view of the transition from the trac model to the
> > desired model, we can attempt to make use of Django's migrations from
> > autogenerated models as brought to our attention by Daniel Brownridge. I do
> > want to ensure that there is a viable migration path in place from the old
> > bloodhound to the new.
> >
> > I think this is about as far as I want the proposal to go for now.
> > Obviously there is going to be plenty more to decide.
> >
> > Please let me know your thoughts.
> >
> > Cheers,
> > Gary
> >
