[RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock

[RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock

[Dan Drake]

[-- Attachment #1.1: Type: text/plain, Size: 767 bytes --]

I asked about a way to specify a time when using org-resolve-clock instead
of a number of minutes:

https://lists.gnu.org/archive/html/emacs-orgmode/2020-01/msg00010.html

I've implemented this myself and a patch is attached. Comments welcome --
my change works, but I'm not sure about coding style, and right now there's
no error checking.

I marked the patch as a tiny change, but it does add a new menu option and
behavior to org-resolve-clock, so there may be an argument that it's not,
from a user perspective, a "tiny change", but code-wise it's quite simple:
the core logic really isn't more than "ask the user for a time and
subtract".

I hope this change can be incorporated into the official Org release.

Regards,

Dan


-- 
Ceci n'est pas une .signature.

[-- Attachment #1.2: Type: text/html, Size: 1170 bytes --]

[-- Attachment #2: 0001-org-clock.el-add-t-option-to-org-clock-resolve.patch --]
[-- Type: text/x-patch, Size: 4717 bytes --]

From 7c369696c2eb9ebcd72ac9e7415d2481c4da7d80 Mon Sep 17 00:00:00 2001
From: Dan Drake <dan.drake@gmail.com>
Date: Sun, 19 Jan 2020 08:24:12 -0600
Subject: [PATCH] org-clock.el: add `t' option to org-clock-resolve

* org-clock.el (org-clock-resolve): add `t' option. This works just like
`k', but asks the user to specify a time, instead of a number of
minutes.

Often when you are interrupted at a task and get back to it, you know
what time the interruption happened. This option makes it easy to tell
org-resolve-clocks about that. For example, say you clocked into task A
at, say, 9:37:

    * original task A
      :LOGBOOK:
      CLOCK: [2020-01-21 Mon 09:37]
      :END:

While working on task A, you get a phone call. When the call is done,
you'd like to update your time logging to reflect the phone call. Your
phone says the call was at 11:09.

With C-c C-x C-z, you can use the `K' option, but you need to figure out
the number of minutes to keep. It's easier to look at the phone, or to
mentally note the time when an interruption starts. With the new option,
you can select `T', and just specify a time of 11:09. The state is now:

    * original task A
      :LOGBOOK:
      CLOCK: [2020-01-21 Mon 09:37]--[2020-01-21 Mon 11:09] => 1:32
      :END:

You add the phone call to your org buffer and do C-c C-x C-i to clock
in. Org asks you to start the time from when the previous task ended,
you say yes, and the state is now:

    * original task A
      :LOGBOOK:
      CLOCK: [2020-01-21 Mon 09:37]--[2020-01-21 Mon 11:09] => 1:32
      :END:
    * task B, phone call
      :LOGBOOK:
      CLOCK: [2020-01-21 Mon 11:09]
      :END:

At this point, you can clock back into task A, or any other task.

The key feature here is to be able to just type in a time -- in any
format accepted by org-read-date -- instead of specifying a number of
minutes.

TINYCHANGE
---
 lisp/org-clock.el | 23 +++++++++++++++++------
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 06df2d497..a73b500a8 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -986,6 +986,12 @@ CLOCK is a cons cell of the form (MARKER START-TIME)."
 		     (org-flag-drawer nil element))
 		   (throw 'exit nil)))))))))))
 
+(defun time-to-mins-to-keep (start-time)
+  "Asks the user for a time and returns the number of minutes
+from START-TIME to that time."
+  (floor (/ (float-time
+	     (time-subtract (org-read-date t t) start-time)) 60)))
+
 (defun org-clock-resolve (clock &optional prompt-fn last-valid fail-quietly)
   "Resolve an open Org clock.
 An open clock was found, with `dangling' possibly being non-nil.
@@ -1022,6 +1028,9 @@ k/K      Keep X minutes of the idle time (default is all).  If this
          that many minutes after the time that idling began, and then
          clocked back in at the present time.
 
+t/T      Like `k', but will ask you to specify a time, instead of a
+         number of minutes.
+
 g/G      Indicate that you \"got back\" X minutes ago.  This is quite
          different from `k': it clocks you out from the beginning of
          the idle period and clock you back in X minutes ago.
@@ -1041,19 +1050,21 @@ to be CLOCKED OUT."))))
 		(while (or (null char-pressed)
 			   (and (not (memq char-pressed
 					   '(?k ?K ?g ?G ?s ?S ?C
-						?j ?J ?i ?q)))
+						?j ?J ?i ?q ?t ?T)))
 				(or (ding) t)))
 		  (setq char-pressed
 			(read-char (concat (funcall prompt-fn clock)
-					   " [jkKgGSscCiq]? ")
+					   " [jkKtTgGSscCiq]? ")
 				   nil 45)))
 		(and (not (memq char-pressed '(?i ?q))) char-pressed)))))
 	 (default
 	   (floor (org-time-convert-to-integer (org-time-since last-valid))
 		  60))
 	 (keep
-	  (and (memq ch '(?k ?K))
-	       (read-number "Keep how many minutes? " default)))
+	  (or (and (memq ch '(?k ?K))
+		   (read-number "Keep how many minutes? " default))
+	      (and (memq ch '(?t ?T))
+		   (time-to-mins-to-keep last-valid))))
 	 (gotback
 	  (and (memq ch '(?g ?G))
 	       (read-number "Got back how many minutes ago? " default)))
@@ -1068,7 +1079,7 @@ to be CLOCKED OUT."))))
 	  (org-clock-resolve-clock clock 'now nil t nil fail-quietly))
       (org-clock-jump-to-current-clock clock))
      ((or (null ch)
-	  (not (memq ch '(?k ?K ?g ?G ?s ?S ?C))))
+	  (not (memq ch '(?k ?K ?g ?G ?s ?S ?C ?t ?T))))
       (message ""))
      (t
       (org-clock-resolve-clock
@@ -1092,7 +1103,7 @@ to be CLOCKED OUT."))))
 	      (t
 	       (error "Unexpected, please report this as a bug")))
        (and gotback last-valid)
-       (memq ch '(?K ?G ?S))
+       (memq ch '(?K ?G ?S ?T))
        (and start-over
 	    (not (memq ch '(?K ?G ?S ?C))))
        fail-quietly)))))
-- 
2.17.1

Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock

[Nicolas Goaziou]

Hello,

Dan Drake <dan.drake@gmail.com> writes:

> I asked about a way to specify a time when using org-resolve-clock instead
> of a number of minutes:
>
> https://lists.gnu.org/archive/html/emacs-orgmode/2020-01/msg00010.html
>
> I've implemented this myself and a patch is attached. Comments welcome --
> my change works, but I'm not sure about coding style, and right now there's
> no error checking.

Thank you. Some comments follow.

> I marked the patch as a tiny change, but it does add a new menu option and
> behavior to org-resolve-clock, so there may be an argument that it's not,
> from a user perspective, a "tiny change", but code-wise it's quite simple:
> the core logic really isn't more than "ask the user for a time and
> subtract".

TINYCHANGE is only about the number of non-trivial lines of code in your
patch (15 or so).

> +(defun time-to-mins-to-keep (start-time)
> +  "Asks the user for a time and returns the number of minutes
> +from START-TIME to that time."
> +  (floor (/ (float-time
> +	     (time-subtract (org-read-date t t) start-time)) 60)))

The name of the function is wrong, it should start with "org-clock".
Also, docstring's first line must contain a full sentence.

Anyway, this is used only once in your patch, I suggest to inline in
instead.
> +	  (or (and (memq ch '(?k ?K))
> +		   (read-number "Keep how many minutes? " default))
> +	      (and (memq ch '(?t ?T))
> +		   (time-to-mins-to-keep last-valid))))

See above about inlining.

Would you mind adding an ORG-NEWS entry, and, if possible, writing
a test?

Regards,

-- 
Nicolas Goaziou

Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock

[Dan Drake]

[-- Attachment #1.1: Type: text/plain, Size: 2523 bytes --]

Thank you, Nicolas, for the review of my first patch. I've updated my code
and have the new patch attached.

I didn't inline the "time to minutes to keep function"; yes, that function
is very short, but the function name makes the intent/purpose of the code
obvious, and the org-clock-resolve a bit more readable. If it's important
to inline that -- performance concerns about the function call overhead,
accepting org-mode/emacs coding style, etc. -- I'm willing to do that.

I added an entry to ORG-NEWS for version 9.4.

I didn't write any tests, as the change seems so simple, and UI-focused.
But again, if that's a dealbreaker, I can work on doing that.

Further comments welcome.

On Fri, Jan 24, 2020 at 5:31 PM Nicolas Goaziou <mail@nicolasgoaziou.fr>
wrote:

> Hello,
>
> Dan Drake <dan.drake@gmail.com> writes:
>
> > I asked about a way to specify a time when using org-resolve-clock
> instead
> > of a number of minutes:
> >
> > https://lists.gnu.org/archive/html/emacs-orgmode/2020-01/msg00010.html
> >
> > I've implemented this myself and a patch is attached. Comments welcome --
> > my change works, but I'm not sure about coding style, and right now
> there's
> > no error checking.
>
> Thank you. Some comments follow.
>
> > I marked the patch as a tiny change, but it does add a new menu option
> and
> > behavior to org-resolve-clock, so there may be an argument that it's not,
> > from a user perspective, a "tiny change", but code-wise it's quite
> simple:
> > the core logic really isn't more than "ask the user for a time and
> > subtract".
>
> TINYCHANGE is only about the number of non-trivial lines of code in your
> patch (15 or so).
>
> > +(defun time-to-mins-to-keep (start-time)
> > +  "Asks the user for a time and returns the number of minutes
> > +from START-TIME to that time."
> > +  (floor (/ (float-time
> > +          (time-subtract (org-read-date t t) start-time)) 60)))
>
> The name of the function is wrong, it should start with "org-clock".
> Also, docstring's first line must contain a full sentence.
>
> Anyway, this is used only once in your patch, I suggest to inline in
> instead.
> > +       (or (and (memq ch '(?k ?K))
> > +                (read-number "Keep how many minutes? " default))
> > +           (and (memq ch '(?t ?T))
> > +                (time-to-mins-to-keep last-valid))))
>
> See above about inlining.
>
> Would you mind adding an ORG-NEWS entry, and, if possible, writing
> a test?
>
> Regards,
>
> --
> Nicolas Goaziou
>


-- 
Ceci n'est pas une .signature.

[-- Attachment #1.2: Type: text/html, Size: 3541 bytes --]

[-- Attachment #2: 0001-org-clock.el-add-t-option-to-org-clock-resolve.patch --]
[-- Type: text/x-patch, Size: 5400 bytes --]

From 52d53de5f67e9ba16b6efe91ac79b370d89c9fea Mon Sep 17 00:00:00 2001
From: Dan Drake <dan.drake@gmail.com>
Date: Sun, 19 Jan 2020 08:24:12 -0600
Subject: [PATCH] org-clock.el: add `t' option to org-clock-resolve

* org-clock.el (org-clock-resolve): add `t' option. This works just like
`k', but asks the user to specify a time, instead of a number of
minutes.

Often when you are interrupted at a task and get back to it, you know
what time the interruption happened. This option makes it easy to tell
org-resolve-clocks about that. For example, say you clocked into task A
at, say, 9:37:

    * original task A
      :LOGBOOK:
      CLOCK: [2020-01-21 Mon 09:37]
      :END:

While working on task A, you get a phone call. When the call is done,
you'd like to update your time logging to reflect the phone call. Your
phone says the call was at 11:09.

With C-c C-x C-z, you can use the `K' option, but you need to figure out
the number of minutes to keep. It's easier to look at the phone, or to
mentally note the time when an interruption starts. With the new option,
you can select `T', and just specify a time of 11:09. The state is now:

    * original task A
      :LOGBOOK:
      CLOCK: [2020-01-21 Mon 09:37]--[2020-01-21 Mon 11:09] => 1:32
      :END:

You add the phone call to your org buffer and do C-c C-x C-i to clock
in. Org asks you to start the time from when the previous task ended,
you say yes, and the state is now:

    * original task A
      :LOGBOOK:
      CLOCK: [2020-01-21 Mon 09:37]--[2020-01-21 Mon 11:09] => 1:32
      :END:
    * task B, phone call
      :LOGBOOK:
      CLOCK: [2020-01-21 Mon 11:09]
      :END:

At this point, you can clock back into task A, or any other task.

The key feature here is to be able to just type in a time -- in any
format accepted by org-read-date -- instead of specifying a number of
minutes.

TINYCHANGE
---
 etc/ORG-NEWS      |  5 +++++
 lisp/org-clock.el | 22 ++++++++++++++++------
 2 files changed, 21 insertions(+), 6 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 67c3ca2ed..00c1f453a 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -35,6 +35,11 @@ value in call to =java=.
 After editing a source block, Org will restore the window layout when
 ~org-src-window-setup~ is set to a value that modifies the layout.
 
+*** New option to resolve open clock at a provided time
+~org-resolve-clocks~ now has a `t' option, which works just like the
+`k' option, but the user specifies a time of day, not a number of
+minutes.
+
 ** New functions
 *** ~org-columns-toggle-or-columns-quit~
 =<C-c C-c>= bound to ~org-columns-toggle-or-columns-quit~ replaces the
diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 06df2d497..04e17696b 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -986,6 +986,11 @@ CLOCK is a cons cell of the form (MARKER START-TIME)."
 		     (org-flag-drawer nil element))
 		   (throw 'exit nil)))))))))))
 
+(defun org-clock-time-to-mins-to-keep (start-time)
+  "Ask the user for a time and return the number of minutes from START-TIME to that time."
+  (floor (/ (float-time
+	     (time-subtract (org-read-date t t) start-time)) 60)))
+
 (defun org-clock-resolve (clock &optional prompt-fn last-valid fail-quietly)
   "Resolve an open Org clock.
 An open clock was found, with `dangling' possibly being non-nil.
@@ -1022,6 +1027,9 @@ k/K      Keep X minutes of the idle time (default is all).  If this
          that many minutes after the time that idling began, and then
          clocked back in at the present time.
 
+t/T      Like `k', but will ask you to specify a time, instead of a
+         number of minutes.
+
 g/G      Indicate that you \"got back\" X minutes ago.  This is quite
          different from `k': it clocks you out from the beginning of
          the idle period and clock you back in X minutes ago.
@@ -1041,19 +1049,21 @@ to be CLOCKED OUT."))))
 		(while (or (null char-pressed)
 			   (and (not (memq char-pressed
 					   '(?k ?K ?g ?G ?s ?S ?C
-						?j ?J ?i ?q)))
+						?j ?J ?i ?q ?t ?T)))
 				(or (ding) t)))
 		  (setq char-pressed
 			(read-char (concat (funcall prompt-fn clock)
-					   " [jkKgGSscCiq]? ")
+					   " [jkKtTgGSscCiq]? ")
 				   nil 45)))
 		(and (not (memq char-pressed '(?i ?q))) char-pressed)))))
 	 (default
 	   (floor (org-time-convert-to-integer (org-time-since last-valid))
 		  60))
 	 (keep
-	  (and (memq ch '(?k ?K))
-	       (read-number "Keep how many minutes? " default)))
+	  (or (and (memq ch '(?k ?K))
+		   (read-number "Keep how many minutes? " default))
+	      (and (memq ch '(?t ?T))
+		   (org-clock-time-to-mins-to-keep last-valid))))
 	 (gotback
 	  (and (memq ch '(?g ?G))
 	       (read-number "Got back how many minutes ago? " default)))
@@ -1068,7 +1078,7 @@ to be CLOCKED OUT."))))
 	  (org-clock-resolve-clock clock 'now nil t nil fail-quietly))
       (org-clock-jump-to-current-clock clock))
      ((or (null ch)
-	  (not (memq ch '(?k ?K ?g ?G ?s ?S ?C))))
+	  (not (memq ch '(?k ?K ?g ?G ?s ?S ?C ?t ?T))))
       (message ""))
      (t
       (org-clock-resolve-clock
@@ -1092,7 +1102,7 @@ to be CLOCKED OUT."))))
 	      (t
 	       (error "Unexpected, please report this as a bug")))
        (and gotback last-valid)
-       (memq ch '(?K ?G ?S))
+       (memq ch '(?K ?G ?S ?T))
        (and start-over
 	    (not (memq ch '(?K ?G ?S ?C))))
        fail-quietly)))))
-- 
2.17.1

Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock

[Nicolas Goaziou]

Hello,

Dan Drake <dan.drake@gmail.com> writes:

> Thank you, Nicolas, for the review of my first patch. I've updated my code
> and have the new patch attached.

Thank you!

> I didn't inline the "time to minutes to keep function"; yes, that function
> is very short, but the function name makes the intent/purpose of the code
> obvious, and the org-clock-resolve a bit more readable. If it's important
> to inline that -- performance concerns about the function call overhead,
> accepting org-mode/emacs coding style, etc. -- I'm willing to do that.

If you think it makes the code more readable, which is debatable IMO,
one option is to simply add a comment where it is going to be inlined.

It is not about speed or Org coding style, but generally speaking,
defining a global function out of a one-liner, just to use it once, does
not sound reasonable. You may define it in a `let' within the function,
but I'm still confident that a comment and plain inlining is more than
enough.

> I added an entry to ORG-NEWS for version 9.4.

Great!

> I didn't write any tests, as the change seems so simple, and UI-focused.
> But again, if that's a dealbreaker, I can work on doing that.

It's certainly not a deal breaker in this case, but a regression test
more or less guarantees a future code refactoring will not unwillingly
break your feature.

Test can come later, or even never, that's your call. No worries.

Regards,

-- 
Nicolas Goaziou

Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock

[Bastien]

Hi Dan and Nicolas,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> TINYCHANGE is only about the number of non-trivial lines of code in
> your patch (15 or so).

I would not say "non-trivial lines" of code.

The change should be less *than 15 lines or so* to be accepted.

I may be wrong, but this is how I read this:
https://www.gnu.org/prep/maintain/maintain.html

I don't see any inconvenient in being strict here: this is just a
matter of signing the FSF papers for the contributors, and signing the
FSF papers is good for engaging contributors for future contributions.

Dan, if you didn't take this route yet, would you mind doing so?

Here is the form and instructions:

https://code.orgmode.org/bzg/org-mode/raw/master/request-assign-future.txt
https://orgmode.org/worg/org-contribute.html

Thanks!

-- 
 Bastien

Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock

[Nicolas Goaziou]

Hello,

Bastien <bzg@gnu.org> writes:

> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>> TINYCHANGE is only about the number of non-trivial lines of code in
>> your patch (15 or so).
>
> I would not say "non-trivial lines" of code.
>
> The change should be less *than 15 lines or so* to be accepted.
>
> I may be wrong, but this is how I read this:
> https://www.gnu.org/prep/maintain/maintain.html

I disagree. As stated in this page, only lines of code significant
copyright-wise count.

Commenting a line of code, changing indentation (e.g., when you wrap
a `let') do not count. You cannot copyright an indentation change. Nor
a symbol renaming (this example is even given in the page above). Also,
applying the same change multiple times may count /at most/ once.

So, I stand on my ground: there is a "non-trivial" part to take into
consideration when counting locs.

I would go even further: when you transform a string regexp into a rx
regexp, there is no line to count, because there is no new idea to
copyright in the first place. This is a trivial change.

Anyway, I think arguing here is just wasting our time.

Regards,

-- 
Nicolas Goaziou

Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock

[Bastien]

Hi Nicolas,

I think it is worth spending a little time discussing this to ensure
that everyone is aligned on the same understanding, otherwise we may
have to spend more time later, discussing it over and over for other
cases.

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> So, I stand on my ground: there is a "non-trivial" part to take into
> consideration when counting locs.

Yes, you are right.

My point is that distinguishing trivial vs. non-trivial parts of a
change may be subject to interpretation.  When in doubt, I recommend
staying on the safe side of not accepting a change that is more than
15 lines of "maybe-significant" changes.

In general, the more FSF-signed contributors there are, the less time
maintainers spend on deciding whether changes are significant or not.

Also, signed contributors are more likely to contribute again, so I
recommend inciting contributors to sign.  I am glad we already have
more than 200 signed contributors, that's a great achievement :)

> I would go even further: when you transform a string regexp into a rx
> regexp, there is no line to count, because there is no new idea to
> copyright in the first place. This is a trivial change.

Yes, in this case there is no new idea, but this is irrelevant to the
discussion, since ideas cannot be copyrighted anyway.

Copyright is about the expression of ideas, and code is also all about
this, hence the difficulty, sometimes, to interpret "significant".

> Anyway, I think arguing here is just wasting our time.

Well, I hope I clarified my point, which is to stay on safe side of
asking contributors to sign the FSF papers when the importance of the
change can be subject to intepretation.

Thanks,

-- 
 Bastien

Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock

[Nicolas Goaziou]

Bastien <bzg@gnu.org> writes:

> My point is that distinguishing trivial vs. non-trivial parts of a
> change may be subject to interpretation.  When in doubt, I recommend
> staying on the safe side of not accepting a change that is more than
> 15 lines of "maybe-significant" changes.

AFACT, there was no doubt involved when I said "15 lines of non-trivial
code".

> Yes, in this case there is no new idea, but this is irrelevant to the
> discussion,

I thought we had a discussion about it recently, but my memories may be
brittle.

> since ideas cannot be copyrighted anyway.

I knew I shouldn't have used this word. Fair enough. Replace it with
"process", or whatever has a copyright meaning.

> Well, I hope I clarified my point, which is to stay on safe side of
> asking contributors to sign the FSF papers when the importance of the
> change can be subject to intepretation.

If your point (I didn't get it actually) is "interpretation is hard,
let's not interpret anything and count everything as significant", well,
I think this is not a good way to look at the problem. But that's fine,
as long as it suits you.

Regards,

Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock

[Bastien]

Hi Nicolas,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Bastien <bzg@gnu.org> writes:
>
>> My point is that distinguishing trivial vs. non-trivial parts of a
>> change may be subject to interpretation.  When in doubt, I recommend
>> staying on the safe side of not accepting a change that is more than
>> 15 lines of "maybe-significant" changes.
>
> AFACT, there was no doubt involved when I said "15 lines of non-trivial
> code".

I'm sure there was no doubt on your side, but as the one responsible
for the consistency of copyright assignment for Org-mode, my attention
is necessarily triggered when I see a change of >20 lines marked as
"tiny change".

I fully trust your judgement.  I am not arguing that *this* change
required Dan to sign the papers.  I'm saying that in general, I would
rather avoid relying on the evaluation of the "triviality" of the locs
and incite contributors to sign the papers.

> If your point (I didn't get it actually) is "interpretation is hard,
> let's not interpret anything and count everything as significant", well,
> I think this is not a good way to look at the problem. But that's fine,
> as long as it suits you.

My point is this: the inconveniency of *systematically* requesting
copyright assignment from the contributor when its contribution is
more than 15 lines (significant *or not*) is a small inconveniency
compared to the one of having to check carefully whether every >15
lines change is significant or not.

And since is it a good outcome to have more people signing the FSF
papers, I recommend requesting contributors to sign the copyright
assignment for every >15 lines contributions (significant or not).

Future maintainers may of course interpret the recommendations of
the FSF differently, but that's mine for now.

Thanks,

-- 
 Bastien

Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock

[Nicolas Goaziou]

Bastien <bzg@gnu.org> writes:

> Future maintainers may of course interpret the recommendations of
> the FSF differently, but that's mine for now.

Of course, sir.

Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock

[Dan Drake]

[-- Attachment #1: Type: text/plain, Size: 708 bytes --]

I just wanted to add that I have no real opinion one way or the other on
the TINYCHANGE bit; I was just following what I found at
https://orgmode.org/worg/org-contribute.html.

I also have no strong opinion on how copyright should be handled for this.
I'm willing to assign copyright to the FSF, make my contribution public
domain, or whatever is most convenient and easiest to get this into org.

Regards,

Dan


On Sat, Feb 1, 2020 at 10:48 AM Nicolas Goaziou <mail@nicolasgoaziou.fr>
wrote:

> Bastien <bzg@gnu.org> writes:
>
> > Future maintainers may of course interpret the recommendations of
> > the FSF differently, but that's mine for now.
>
> Of course, sir.
>


-- 
Ceci n'est pas une .signature.

[-- Attachment #2: Type: text/html, Size: 1302 bytes --]

Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock

[Bastien]

Hi Dan,

Dan Drake <dan.drake@gmail.com> writes:

> I'm willing to assign copyright to the FSF, make my
> contribution public domain, or whatever is most convenient and
> easiest to get this into org.

Thanks!  My understanding is that your contribution has already been
added to org-mode, which is fine.

To assign your copyright to the FSF for future contributions, you can
follow the instructions here:

https://code.orgmode.org/bzg/org-mode/raw/master/request-assign-future.txt

Best (and hello from the OLPC old days!)

-- 
 Bastien

Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock

[Robert Pluim]

>>>>> On Sat, 01 Feb 2020 15:34:54 +0100, Bastien <bzg@gnu.org> said:
    Bastien> And since is it a good outcome to have more people signing the FSF
    Bastien> papers, I recommend requesting contributors to sign the copyright
    Bastien> assignment for every >15 lines contributions (significant or not).

Not only that: without copyright assignment you need to keep track of
whether an individual has contributed more than 15 significant lines
*total*, which is a hassle.

Robert

Re: [RFC PATCH] specify a time, not number of minutes to keep, with org-resolve-clock

[Bastien]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Sat, 01 Feb 2020 15:34:54 +0100, Bastien <bzg@gnu.org> said:
>     Bastien> And since is it a good outcome to have more people signing the FSF
>     Bastien> papers, I recommend requesting contributors to sign the copyright
>     Bastien> assignment for every >15 lines contributions (significant or not).
>
> Not only that: without copyright assignment you need to keep track of
> whether an individual has contributed more than 15 significant lines
> *total*, which is a hassle.

Yes, indeed.

-- 
 Bastien