> On Jun 27, 2020, at 5:25 PM, Greg Stein <gst...@gmail.com> wrote:
>
> On 2020/06/27 23:52:20, Craig Russell <apache....@gmail.com> wrote:
>>> On Jun 27, 2020, at 3:11 PM, Greg Stein <gst...@apache.org> wrote:
>>>
>>> On 2020/06/27 00:15:39, Craig Russell <apache....@gmail.com> wrote:
>> ...
>>>> ...
>>>> The term "annually" can be read in a few ways, which can be reflected
> in different wordings on the web
>>>
>>> Just read "current year" and "prior year", and weave them together.
>>
>> Nope. In June 2021 after we have a new team in place,
>> currentyearprioryear would show everyone has signed. Not good enough.
>
> Hmm? In June 2021, you'd see that John Doe hasn't signed in, in the past 12
> months. By "weave", I meant a hash/dict of name->date. You'd know that John
> Doe signed in January 2020, so he'd need to sign again on-or-about January
> 2021.
Nope. "Annually" doesn't mean "every year in the same month" or anything else
like it. Which is why the tool should be descriptive and not prescriptive.
> And when you go look at June 2021, and find "jdoe->jan2020", you'd
> find he was 5 months out of compliance.
The board is free to elaborate what is meant by "annually" but a strict reading
of this term would allow signing in January 2020 and December 2021. But clearly
this in not what we want. And I would strongly advise against coding anything
into whimsy before the board decides whether to clarify or just use common
sense.
>
>> But assuming that we make a trivial change to the tool to iterate the
>> years directories, we can have the sidebar give quick access to all COI
>> documents ever signed, or just the last three or whatever we like. Later.
>
> Sure!
>
>>> You'll be able to synthesize "annual" in any fashion you like. Whether
>>> that is calendar, Board election cycle, or fiscal year. "svn info" gives
>>> you the last modification date, which is presumably the signing date.
>>
>> I still prefer to keep it simple. Organize all documents signed in a
>> calendar year in a directory named after that calendar year. Everything
>> else, including the following, is icing.
>
> I'm suggesting: keep your current organization. It works totally fine.
Thanks!
>
> The *tool* weaves current+prior together for its processing and display.
>
>> ...
>>> Note that comparing the file means stripping the metadata from the end.
>>> I would suggest to make the file the policy-at-time, and use svn properties
>>> for the metadata (that is why they are there).
>> ...
>> Let's get past this year's exercise and wait until something more
>> complicated becomes necessary and agreed.
>
> Mixing metadata into your primary content may make things harder down the
> line. But, meh. It's data processing.
>
> I will echo sebb's discussion point about 2020/template.txt. What if it
> gets changed in October 2020, for some reason? If the answer is "well, we
> can see that in the svn revision log".
If this does happen, we change it in the 2020/template.txt and anyone who signs
after that will have the new template checked in under their name. And if you
want to see which version someone signed, just look at their clr.txt file.
Instead of March 2020 at the top you will see October 2020.
Once we have agreed on the tool, we will need to update the chair's runbook to
cover the various changes needed if a new VP is appointed, when the calendar
rolls over, and when the board turns over. We could add tooling for these
changes as well, but they are simple enough for an svn command and too
complicated for the tool to do automatically.
> And if *that* is the answer, then
> move it outside the per-year directory and use a single revision log for
> understanding which COI policy was extent on $date.
I'll reiterate my opinion that there is absolutely no reason to add more
complexity to the tool. If we were going to have this tool be used by all
committers, all members, all PMC chairs, or some other larger group, I'd be
happy to entertain more complexity. But for the task at hand, no.
Ciao,
Craig
>
> Cheers,
> -g
Craig L Russell
c...@apache.org
