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 > >