On 16/03/15 13:30, Ron W wrote:
On Sun, Mar 15, 2015 at 3:56 AM, Graeme Pietersz <[email protected]
> <mailto:[email protected]>> wrote:
>
> No one system has all these, but looking at multiple ticket trackers,
> the obvious things to me are:
>
> 1) email notifications, the most important for me
>
>
> Can currently be accomplished with external (to Fossil) service,
> using, for example, Fossil's RSS feed to trigger email generation.
Not easy to do with a private repo without compromising privacy.
>
> 2) assigning tickets to developers
>
>
> I have done this. The part that didn't work at the time was the list
> for the drop down had to be maintained manually. This might be
> possible, now. I don't know if the TH1 query function allows reading
> the user table.
Nice if it now works.
>
> 3) setting a milestone (only makes sense if you have a project
> management features fossil does not have anyway)
>
>
> Still could be done via a custom field. Though maintaining the list
> for the drop down needs admin access to the Fossil repo.
>
> If the TH1 query function can read user defined tables, then the list
> could be maintained via SQL updates.
That will actually work quite well for many projects. Thanks.
>
> 4) link user names to user pages with other activity (only useful of
> you have some social networking features)
>
>
> You mean like linking to users's "walls"?
>
> Tickets descriptions and comments can contain wiki mark-up.
That relies on people remembering to do it - procedure for something
that could be painless and uniform if automated.
Fossil does not have use pages as such, but it does have pages for a
timeline for that user: /timeline?u=graeme for example.
Ideally we would have a combination of that and contact info on one page.
>
> 5) edit the original report if things change
>
>
> Not sure I agree. While making corrections might be nice, I think
> comments are better for describing an evolving situation.
In general, but if the task is changed significantly there is a good
case for changing the ticket itself.
To take a recent example I came across, you have a ticket to upgrade an
application to work with a more recent library version.
You then change your mind about which more recent version to upgrade to.
A ticket that still says "upgrade to version x.y" when you
are now upgrading to x.z is misleading.
>
> 6) sub-tasks/child tickets/todo list for ticket
>
>
> In the description and comments, other tickets can be linked,, as can
> wiki pages and commits.
>
> Would be nice if other fields could link as well.
>
> Anyway, could create a child ticket using Javascript to populate a
> new ticket with defaults derived from the currently viewed ticket.
That does not provide the same functionality. It is a partial workaround
but relies on manual intervention to ensure the links run both ways,
and does not prevent the parent ticket being closed before all child
tickets are closed.
>
> 7) better UI - I am sure this can be fixed with relatively simple
> customisation, and its mostly nice to have features like having the
> comment form under the comments.
>
>
>
>
> _______________________________________________ fossil-users mailing
> list [email protected]
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
