Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [mylar-dev] RE: Planning

Sorry for the very slow reply Jimisola, your message was unfortunately too
interesting for a quick reply ;)

> -----Original Message-----
> From: mylar-dev-bounces@xxxxxxxxxxx [mailto:mylar-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Jimisola Laursen
...
> First of all, what information is included in a context task? The
> information that Mylar shows under Planning as well?

Mylar stores all your interaction with the resources your work on as part of
a task in the task context, and all your interaction with tasks in a special
task activity context (which can be thought of as a meta task context).
Since the task activity context has interaction events for every activation
and deactivation of a task it is the only thing used for computing the time
listed under the Planning tab.  Similarly it used for determining the
different intervals that a task was worked on each week (visible in the Task
Activity view). 

A paper on how this works will be published in the beginning of November and
I'll post a link.
 
> Since I am not very familiar with EPF nor Mylar context details I might
> have
> missed understood #111218.
> I therefore want to verify with your before I make comments to it or add
> an
> additional feature request.
> 
> #111218 discusses sharing task context and task awareness. How is this
> suppose to be done?
> Via instant messengers using Jabber/Smacker , via issue trackers (such as
> Bugzilla, Jira etc)?
> How does EPF come in here? I am not very familiar with the process and
> project management terms yet (it's coming). But, if I understood Scott
> Lewis
> right - which I hope - EPF have the concept 'shared object'. A 'shared
> object' then resides in the 'datashare'.

>From Mylar's point of view it doesn't matter how you share it.  Currently we
support asynchronous sharing of task context in the form of task repository
attachments, shared asynchronously (i.e. I attach, later you retrieve).  It
would be just as easy to share task context with a shared object, giving the
benefit of synchronous collaboration, but possibly taking away the benefit
of having one or more contexts associated with a task on the repository.  

> My initial idea was a "a central time tracking facility" which:
> 
>  1. is aware about the task and time concept (estimated time, elapsed
> time,
> scheduled for, creation datetime, last update datetime) etc
>  2. uses an open protocol to store tasks context
>  3. uses an open protocol to query the central
> 
> Hence, the central time tracking facility allows storing from anything
> that
> supports the protocol - it can be a an IDE such as Eclipse, a Lisp
> extension
> for XEMACS or even a web application for companies that use many different
> tools just need a standard way of reporting time and do planning on a
> task.
> 
> In the same way it allows _any_ project management tool to use it for
> querying - it can be a "plugin" for MS Project, a web application or a
> Maven
> plugin that creates a report.
> 
> I am not sure if the solution discussed in #111218 is allows this or if
> the
> e.g. the datashare is tightly coupled to EPF or if can be used to store
> time
> information as expressed above without EPF.
> 
> What I am basically trying to get to is that a standalone solution for
> storing the time information would be best. Then EPF can use it like any
> other "client" to retrieve data and Mylar would is it as any other client
> to
> store/input data.
> 
> The ideal would be to connect process management, issue tracker and
> standalone time tracking facility and then be able to ask a question like
> "What tasks for project/product/component X have elapsed time > estimated
> time?" and also to be able to show summary pages which contains
> information
> not only about task status in terms of ASSIGNED/NEW/REOPEN/RESOLVED/etc
> but
> also how much time is has taken so far.

Have you considered making this "central time tracking" facility be the
Bugzilla server?  Bugzilla's support for time tracking, which is not turned
on in bugs.eclipse.org, is sufficient to do all this, and has the benefit of
Bugzilla's query mechanisms as well as well as potential for extensibility.
JIRA also has similar support, and integration with it's time tracking has
been requested:

improve integration of the task completion with issue tracking repositories,
supporting workflow
https://bugs.eclipse.org/bugs/show_bug.cgi?id=144333

If you do check out Bugzilla's time tracking facilities I'll be interested
in hearing whether the meet your needs.  

Mik

--
Mik Kersten, http://kerstens.org/mik
Mylar Project Lead, http://eclipse.org/mylar





Back to the top