emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Buddy Butterfly <buddy.butterfly@web.de>
To: emacs-orgmode <emacs-orgmode@gnu.org>
Subject: More generic taskjuggler export proposal
Date: Wed, 03 Apr 2013 22:25:01 +0200	[thread overview]
Message-ID: <515C901D.50500@web.de> (raw)

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?

             reply	other threads:[~2013-04-03 20:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-03 20:25 Buddy Butterfly [this message]
2013-04-12 13:08 ` More generic taskjuggler export proposal Christian Egli
2013-04-14 12:51   ` Suvayu Ali

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=515C901D.50500@web.de \
    --to=buddy.butterfly@web.de \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).