From: "Sebastien Vauban" <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
To: emacs-orgmode-mXXj517/zsQ@public.gmane.org
Subject: Re: Collaborating with TODO lists and clocks.
Date: Thu, 05 Sep 2013 13:22:38 +0200 [thread overview]
Message-ID: <86mwnr4io1.fsf@somewhere.org> (raw)
In-Reply-To: 874n9zwszq.fsf@konixwork.incubateur.ens-lyon.fr
Samuel Loury wrote:
> Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org> writes:
>
>> Having thought about that in the past, I had thought of adding "tags" after
>> clock lines, such as:
>>
>> --8<---------------cut here---------------start------------->8---
>> CLOCK: [2013-09-05 Thu 07:55]--[2013-09-05 Thu 08:46] => 0:51 :userA:
>> CLOCK: [2013-09-04 Wed 09:05]--[2013-09-04 Wed 09:41] => 0:36 :devB:
>> --8<---------------cut here---------------end--------------->8---
>
> That sounds good also.
Inserting the user is easy to do with:
#+begin_src emacs-lisp
(defun org-clock-out-mark-clock ()
(unless remove (insert (format " :%s:" user-full-name))))
(add-hook 'org-clock-out-hook 'org-clock-out-mark-clock)
#+end_src
>> Though, having separate CLOCK drawers would even be better for Git merges,
>> such as (keeping the idea of pseudo-tags):
>>
>> --8<---------------cut here---------------start------------->8---
>> :CLOCK:userA:
>> CLOCK: [2013-09-05 Thu 07:55]--[2013-09-05 Thu 08:46] => 0:51
>> CLOCK: [2013-09-04 Wed 09:05]--[2013-09-04 Wed 09:41] => 0:36
>> :END:
>> :CLOCK:devB:
>> CLOCK: [2013-09-04 Wed 08:00]--[2013-09-04 Wed 09:03] => 1:03
>> :END:
>> --8<---------------cut here---------------end--------------->8---
>
> I really like this solution.
>
>> But, of course, a lot of development is required to make this become usable:
>>
>> - clocking reports (`R') must be updated with the knowledge of the current
>> user
>>
>> - clock checking functions (`v c') must be enhanced to ignore clocks from
>> other users
>>
>> - etc.
>
> That is my point with the solution by customization of org-clock-string. It
> appears to need only a few corrections of the hard coded "CLOCK:" string
> (that would be required anyway) and it looks like it would work out of the
> box without further development. Wouldn't it?
I've no real idea about how much should be changed for everything to work back
as expected [1], as there are so many functions relying on time clocking. Just
to add two extra points to the above list of possibly complex code changes:
- column view with time summing,
- `org-clock-display' (C-c C-x C-d), which shows subtree times in the entire
buffer
Maybe you want to give it a try?
Though, I fear such a support requires more than what we expect -- while not
looking at the details (where the devil is).
For example, IIUC, different users will share one file with tasks, where they
will clock in/out. Then, what about the SCHEDULED and DEADLINE properties?
Will the tasks be in all the user agendas? Not acceptable. Then, we need first
to add an ASSIGNEE property, and ignore tasks which wouldn't be assigned to
me [2]?
Don't misunderstand me. I'm not trying to convince you or anybody to stop and
cry. On the contrary, I feel that some such possibilities are _needed_ to
transform Org from a "personal organizer" to a "team organizer". I'd be happy
that this would already be the case (and that we would have a real Web
interface for editing the files ;-)).
So, this discussion clearly is interesting, at least for providing ideas and a
common view on what's missing / what should be nice to have.
Best regards,
Seb
[1] Don't forget we should be backward-compatible as well...
[2] For backward-compatibility, I guess we'd need to keep unassigned tasks in
all agenda views. Maybe not that nice.
--
Sebastien Vauban
next prev parent reply other threads:[~2013-09-05 11: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
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 [this message]
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=86mwnr4io1.fsf@somewhere.org \
--to=sva-news-d0wtavr13harg/idocfnwg@public.gmane.org \
--cc=emacs-orgmode-mXXj517/zsQ@public.gmane.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).