emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Gareth Smith <gds@doc.ic.ac.uk>
To: emacs-orgmode@gnu.org
Subject: Re: Collaborating with TODO lists and clocks.
Date: Tue, 30 Apr 2013 19:21:53 +0100	[thread overview]
Message-ID: <87y5bzop4u.fsf@doc.ic.ac.uk> (raw)
In-Reply-To: <87vc743hyw.fsf@berkeley.edu> (Richard Lawrence's message of "Mon, 29 Apr 2013 18:50:17 -0700")


Hi Richard,

Thanks for those suggestions - they're definitely helpful. I'll have a
bit more of a think, and if I come up with a "more optimal" idea, I'll
post again.

Cheers,

Gareth.

Richard Lawrence <richard.lawrence@berkeley.edu> writes:
> Hi Gareth,
>
> Gareth Smith <gds@doc.ic.ac.uk> writes:
>
>> I hadn't thought of using :tags on a clock table. I still worry if we'll
>> find ourselves in a situation where more than one of us has clocked in
>> some time on the same task.
>
> Yes, I agree this might not be optimal, for that case in particular.
> One nice thing about this use of tags is that you have a representation
> of when more than one person is working on a task, but that makes the
> clock less useful, as it can no longer represent an individual's working
> time without some effort to separate the clocks of the different owners.
>
>> For example, often I clock into a task while I do the work of
>> sub-dividing it into smaller tasks. And often when I'm actively working
>> on a task, I'll create a sub-task of my current-clocked-task on the
>> fly. It seems to me that if I continue with this sort of working
>> practice, and attempt to collaborate with others who work similarly,
>> then we might quickly find that it's not easy to describe a given task
>> (or even subtask) as being "owned" by a single person.
>
> So one problem case is where you "own" a task, but someone else owns one
> of its subtasks, e.g.:
>
> ==========================================
> * Clock tables
> #+BEGIN: clocktable :maxlevel 2 :scope file :tags "+gareth"
> #+CAPTION: Clock summary at [2013-04-29 Mon 18:25]
> | Headline           | Time   |      |
> |--------------------+--------+------|
> | *Total time*       | *3:05* |      |
> |--------------------+--------+------|
> | TODO Task 1        | 3:05   |      |
> | \__ TODO Subtask 1 |        | 1:05 |
> | \__ TODO Subtask 2 |        | 1:00 |
> #+END:
> #+BEGIN: clocktable :maxlevel 2 :scope file :tags "+john"
> #+CAPTION: Clock summary at [2013-04-29 Mon 18:17]
> | Headline           | Time   |      |
> |--------------------+--------+------|
> | *Total time*       | *1:05* |      |
> |--------------------+--------+------|
> | TODO Task 1        | 1:05   |      |
> | \__ TODO Subtask 1 |        | 1:05 |
> #+END:
>
> * TODO Task 1							     :gareth:
>   CLOCK: [2013-04-29 Mon 18:15]--[2013-04-29 Mon 19:15] =>  1:00
> ** TODO Subtask 1						       :john:
>    CLOCK: [2013-04-29 Mon 18:15]--[2013-04-29 Mon 19:20] =>  1:05
> ** TODO Subtask 2						     :gareth:
>    CLOCK: [2013-04-29 Mon 16:16]--[2013-04-29 Mon 17:16] =>  1:00
> ==========================================
>
> Notice that Gareth gets credit for John's time on Subtask 1, because
> Gareth owns Task 1.
>
> You can avoid this particular gotcha in (at least) two ways:
>
> 1) Remove the :gareth: tag on task 1 and move the clock time to subtask
> 2 (more generally, "ownership" tags and clock times should only appear
> at the lowest level of the task tree).  Maybe this makes the most sense,
> but it slows down the worflow a bit and is hard to enforce, etc.
>
> 2) Use a tag filter like "+gareth-john" to build the clock table (more
> generally, the clock table for each person should exclude tags for all
> the others).  This prevents double counting and is easy to enforce, but
> if any tasks have more than one owner, no one will get credit for their
> clock times.
>
>> Again, perhaps my workflow is at fault, and I should be organising
>> myself in a more principled way. And perhaps in practice I'll find that
>> tasks do tend to be owned by just one person anyway. 
>
> Yeah, it's a hard problem with no general solution that I can see.  The
> best thing is just to figure out what constraints you're willing to put
> on your workflow, given what Org allows you to do.
>
> Hope that's helpful!
>
> Best,
> Richard

  reply	other threads:[~2013-04-30 18:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-28 18:30 Collaborating with TODO lists and clocks Gareth Smith
2013-04-28 19:27 ` Richard Lawrence
2013-04-29 20:34   ` Gareth Smith
2013-04-30  1:50     ` Richard Lawrence
2013-04-30 18:21       ` Gareth Smith [this message]
2013-09-05  7:31       ` Samuel Loury
2013-09-05  7:42         ` Sebastien Vauban
2013-09-05  8:52           ` Samuel Loury
2013-09-05 11:22             ` Sebastien Vauban
2013-09-05 11:54               ` Thorsten Jolitz
2013-09-05 13:32                 ` Samuel Loury
2013-09-05 13:29               ` Samuel Loury

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=87y5bzop4u.fsf@doc.ic.ac.uk \
    --to=gds@doc.ic.ac.uk \
    --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).