* More generic taskjuggler export proposal
@ 2013-04-03 20:25 Buddy Butterfly
2013-04-12 13:08 ` Christian Egli
0 siblings, 1 reply; 3+ messages in thread
From: Buddy Butterfly @ 2013-04-03 20:25 UTC (permalink / raw)
To: emacs-orgmode
Hi,
I would like propose the following for taskjuggler export
as base for a discussion to change export functionality.
Here I will refer to the example project of taskjuggler 3.
Pre-requesites:
- Functionality of tj should be kept in tj as much as possible
- org export should be as generic as possible such that changes
in tj will not impact org.
Suggestions:
- There should be configurable global taskjuggler prefix to define
what shoudl be exported. Here we will take "tj_" as an example.
- tj elements of the form
: <keyword> <id> <name> { <attributes> }
should be implemented as tagged tasks (like already done for resources
and project).
The org tag should be prefixed by the tj prefix and the tag name
should automatically
be exported as the <keyword> of tj. Org task should go into tj <name>
and the org
property tj_id should go into <id>.
The attributes should be org properties prefixed by the prefix (here
"tj_").
Example for the project tag:
The tj example project lists the following project keyword header:
project your_project_id "Your Project Title" 2011-11-11-0:00--0500 +4m {
timezone "America/New_York"
timeformat "%Y-%m-%d"
numberformat "-" "" "," "." 1
currencyformat "(" ")" "," "." 0
now 2011-12-24
currency "USD"
# You can define multiple scenarios here if you need them.
#scenario plan "Plan" {
# scenario actual "Actual"
#}
# You can define your own attributes for tasks and resources. This
# is handy to capture additonal information about the project that
# is not directly impacting the project schedule but you like to
# keep in one place.
#extend task {
# reference spec "Link to Wiki page"
#}
#extend resource {
# text Phone "Phone"
#}
}
This would be written in org like
* Your Project Title :tj_project:
:PROPERTIES:
:tj_id: your_project_id
:tj_timezone: "America/New_York"
:tj_timeformat: "%Y-%m-%d"
:tj_numberformat: "-" "" "," "." 1
:tj_currencyformat: "(" ")" "," "." 0
:tj_now: 2011-12-24
:tj_currency: "USD"
:END:
* Plan :tj_scenario:
:PROPERTIES:
:tj_scenario: actual "Actual"
:END:
* task :tj_extend:
:PROPERTIES:
:tj_reference: spec "Link to Wiki page"
:END:
* resource :tj_extend:
:PROPERTIES:
:tj_text: Phone "Phone"
:END:
As we can see, org can export everything in a generic way with mainly
stripping
the prefix "tj_" from the tags and properties and export as is to
taskjuggler.
This also maps to the well known resource mapping:
# This is a set of example resources.
resource r1 "Resource 1"
resource t1 "Team 1" {
managers r1
resource r2 "Resource 2"
resource r3 "Resource 3"
}
# This is a resource that does not do any work.
resource s1 "System 1" {
efficiency 0.0
rate 600.0
}
Would be written in org-mode like:
* Resource 1 :tj_resource:
:PROPERTIES:
:tj_id: r1
:END:
* Team 1 :tj_resource:
:PROPERTIES:
:tj_id: t1
:tj_managers: r1
:END:
* Resource 2
:PROPERTIES:
:tj_id: r2
:END:
* Resource 3
:PROPERTIES:
:tj_id: r3
:END:
* System 1 :tj_resource:
:PROPERTIES:
:tj_id: s1
:tj_efficiency: 0.0
:tj_rate: 600.0
:END:
Here the fact of inheritance of org tags have been taken into account in
org task "Team 1" for resource "Resource 2" and "Resource 3".
For the tasks the same holds:
task project "Project" {
task wp1 "Workpackage 1" {
task t1 "Task 1"
task t2 "Task 2"
}
task wp2 "Work package 2" {
depends !wp1
task t1 "Task 1"
task t2 "Task 2"
}
task deliveries "Deliveries" {
task "Item 1" {
depends !!wp1
}
task "Item 2" {
depends !!wp2
}
}
}
Org mode:
* Project :tj_task:
:PROPERTIES:
:tj_id: project
:END:
* Workpackage 2
:PROPERTIES:
:tj_id: wp2
:END:
* Task 1
:PROPERTIES:
:tj_id: t1
:tj_depends: !wp1
:END:
* Task 2
:PROPERTIES:
:tj_id: t2
:END:
Also accounts could be easily generated with this
method:
account cost "Project Cost" {
account dev "Development"
account doc "Documentation"
}
---
* Project Cost :tj_account:
:PROPERTIES:
:tj_id: cost
:END:
* Development
:PROPERTIES:
:tj_id: dev
:END:
* Documentation
:PROPERTIES:
:tj_id: doc
:END:
There is still the question how to implement properties that go into
the global part of a tj file. Here I would suggest that one can place
this data inbetween
#+BEGIN_TASKJUGGLER
# The Profit&Loss analysis should be rev - cost accounts.
balance cost rev
# Define you public holidays here.
vacation "New Year's Day" 2012-01-02
vacation "Birthday of Martin Luther King, Jr." 2012-01-16
vacation "Washington's Birthday" 2012-02-20
vacation "Memorial Day" 2012-05-28
vacation "Independence Day" 2012-07-04
vacation "Labor Day" 2012-09-03
vacation "Columbus Day" 2012-10-08
vacation "Veterans Day" 2012-11-12
vacation "Thanksgiving Day" 2012-11-22
vacation "Christmas Day" 2012-12-25
# The daily default rate of all resources. This can be overridden for each
# resource. We specify this, so that we can do a good calculation of
# the costs of the project.
rate 400.0
#+END_TASKJUGGLER
The dependency between tasks is one thing that should be supported by org.
I do not know what would be the best solution here. Maybe we could get
a completion list for the values when adding :tj_depends: properties.
This is all for now. I still would like to discuss the organisation with
multiple projects. What do you think about it?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: More generic taskjuggler export proposal
2013-04-03 20:25 More generic taskjuggler export proposal Buddy Butterfly
@ 2013-04-12 13:08 ` Christian Egli
2013-04-14 12:51 ` Suvayu Ali
0 siblings, 1 reply; 3+ messages in thread
From: Christian Egli @ 2013-04-12 13:08 UTC (permalink / raw)
To: emacs-orgmode
Hi Buddy
Buddy Butterfly <buddy.butterfly@web.de> writes:
> I would like propose the following for taskjuggler export
> as base for a discussion to change export functionality.
Thanks for your detailed proposal. It's been a few years since I wrote
the taskjuggler exporter and I don't remember all the design decisions.
Your idea with the prefix to the attributes is an interesting one.
However, the fundamental problem here is that IMHO there is no
one-to-one mapping between all the concepts in taskjuggler and org-mode.
Fundamentally taskjuggler is a system to plan and track a multi-resource
project. I see org-mode more geared towards planing and tracking a
single user. Taskjuggler has the concept of scenarios where you can
compare a plan against another plan or an actual execution (based on
reported effort). This might be doable in org-mode but is not really a
natural thing to do.
So in essence what I'm trying to say is that the goal behind the
taskjuggler exporter was never to give you a complete taskjuggler
development environment. For that you are probably better of just
editing the tjp files directly. Instead the goal was to let the user
take their "normal" org-mode files and have them export to taskjuggler
with minimal changes (i.e. mark the tasks, efforts and the resources).
The same holds for the dependency system. As far as I remember it was an
explicit decision not to support the taskjuggler dependency system and
use the one provided by org-mod instead. I think taskjuggler's
dependency system is very low level. The one provided by org-mode fit my
use cases (for the occasional dependency) much better (and have support
for higher level concepts such as the ORDERED or previous-sibling
attribute).
> The dependency between tasks is one thing that should be supported by org.
> I do not know what would be the best solution here. Maybe we could get
> a completion list for the values when adding :tj_depends: properties.
I don't quite understand this part of your message. As I said above I
think the support for dependencies in the taskjuggler is IMHO quite nice
:-).
> Here I would suggest that one can place this data inbetween
>
> #+BEGIN_TASKJUGGLER
> #+END_TASKJUGGLER
This is something I'd like to add support for. I just never got around
to look at how this could be implemented. It has some implications as
you could destroy your otherwise valid tjp file. But it might cover some
of your use cases above. Do you know how this could be done in the new
exporter?
> I still would like to discuss the organisation with multiple projects.
> What do you think about it?
Are you referring to the problem of handling multiple projects and
similar resources? I have never done this. How do you do it in plain
taskjuggler?
Thanks
Christian
--
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: More generic taskjuggler export proposal
2013-04-12 13:08 ` Christian Egli
@ 2013-04-14 12:51 ` Suvayu Ali
0 siblings, 0 replies; 3+ messages in thread
From: Suvayu Ali @ 2013-04-14 12:51 UTC (permalink / raw)
To: emacs-orgmode
Hi Christian,
On Fri, Apr 12, 2013 at 03:08:17PM +0200, Christian Egli wrote:
> Buddy Butterfly <buddy.butterfly@web.de> writes:
> > Here I would suggest that one can place this data inbetween
> >
> > #+BEGIN_TASKJUGGLER
> > #+END_TASKJUGGLER
>
> This is something I'd like to add support for. I just never got around
> to look at how this could be implemented. It has some implications as
> you could destroy your otherwise valid tjp file. But it might cover some
> of your use cases above. Do you know how this could be done in the new
> exporter?
I believe you can use the :export-block property when defining the
backend to specify blocks.
Quoting from the docstring of org-export-define-backend:
:export-block
String, or list of strings, representing block names that
will not be parsed. This is used to specify blocks that will
contain raw code specific to the back-end. These blocks
still have to be handled by the relative `export-block' type
translator.
Hope this helps,
--
Suvayu
Open source is the future. It sets us free.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-04-14 12:51 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-04-03 20:25 More generic taskjuggler export proposal Buddy Butterfly
2013-04-12 13:08 ` Christian Egli
2013-04-14 12:51 ` Suvayu Ali
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).