From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Sebastien Vauban" Subject: Re: Collaborating with TODO lists and clocks. Date: Thu, 05 Sep 2013 13:22:38 +0200 Message-ID: <86mwnr4io1.fsf@somewhere.org> References: <87li82se2b.fsf@totherme.org> <87obcybgmc.fsf@berkeley.edu> <87txmpoz34.fsf@doc.ic.ac.uk> <87vc743hyw.fsf@berkeley.edu> <877gevwwq5.fsf@konixwork.incubateur.ens-lyon.fr> <8638pjiujv.fsf@somewhere.org> <874n9zwszq.fsf@konixwork.incubateur.ens-lyon.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org To: emacs-orgmode-mXXj517/zsQ@public.gmane.org Samuel Loury wrote: > Sebastien Vauban writes: > >> Having thought about that in the past, I had thought of adding "tags" af= ter >> clock lines, such as: >> >> --8<---------------cut here---------------start------------->8--- >> CLOCK: [2013-09-05 Thu 07:55]--[2013-09-05 Thu 08:46] =3D> 0:51 :u= serA: >> CLOCK: [2013-09-04 Wed 09:05]--[2013-09-04 Wed 09:41] =3D> 0:36 :d= evB: >> --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 merge= s, >> 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] =3D> 0:51 >> CLOCK: [2013-09-04 Wed 09:05]--[2013-09-04 Wed 09:41] =3D> 0:36 >> :END: >> :CLOCK:devB: >> CLOCK: [2013-09-04 Wed 08:00]--[2013-09-04 Wed 09:03] =3D> 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 usa= ble: >> >> - clocking reports (`R') must be updated with the knowledge of the curre= nt >> 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 b= ack as expected [1], as there are so many functions relying on time clocking. J= ust 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 th= ey 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 fi= rst 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 a= nd 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 hap= py that this would already be the case (and that we would have a real Web interface for editing the files=C2=A0;-)). So, this discussion clearly is interesting, at least for providing ideas an= d 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. --=20 Sebastien Vauban