On 18 Oct 2012, at 21:35, Gary Martin <[email protected]> wrote:
> I had considered that but you would probably have to list out tasks within a > ticket to cover per task workflow, wouldn't you? I don't believe there should be a per task workflow. It should be a ticket if it's big enough to need a workflow. > This is why I was thinking of making use of structure around tickets for > relationships that we are going to support anyway. > > Also, are we expecting that users might sometimes create tickets separately > that should be joined by a multi version relationship? Would you pull them > into a single ticket and mark the others as invalid? That should be entirely up to the user. > > Can we envisage a way of having a ticket like interface to summarise a set of > related tickets? We have a few of these already: Products, Versions, Milestones. They are like tickets in some ways, but their main purpose is to group tickets. We could introduce kilometre-stones for a smaller measure⸮ - Joe > > Perhaps we can't.. perhaps it is too difficult.. but having the ability to > model relationships suggests this kind of view to me anyway. > > Cheers, > Gary > > Joe Dreimann <[email protected]> wrote: > >> Maybe this can be solved by having a smaller entity than a ticket? >> After all tickets have a lot of properties and are >> distinct/disconnected in the UI - for good reason, because they usually >> represent distinct issues. >> >> What if a Ticket could have a set of checkboxes within it? These >> wouldn't need any properties themselves, they could just list: >> >> [ ] Minor Task 1 >> [ ] Minor Task 2 >> [ ] Minor Task 3 >> >> No matter the status of these the ticket could be closed, reopened, >> etc. They shouldn't add restrictions, just record small tasks that >> users otherwise would track outside Bloodhound. >> >> Pivotal Tracker and Trello use these to great effect for example. >> >> I expect this to be controversial, in fact I'm sitting on the >> proverbial sense myself. >> >> - Joe >
