> On Jun 28, 2020, at 3:19 AM, sebb <seb...@gmail.com> wrote: > > On Sun, 28 Jun 2020 at 01:41, Craig Russell <apache....@gmail.com > <mailto:apache....@gmail.com>> wrote: >> >> >> >>> 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. > > The same applies if there is a single shared copy of the template file.
That is true. > >> 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. > > Having annual copies of template.txt seems *more* complicated to me. > There is then no need to copy the file to the annual directory. So we can move the template.txt to the top (documents/conflict-of-interest) directory and only change it when the board says so. Then the code just needs to try to find it. ;-) Craig > >> Ciao, >> Craig >>> >>> Cheers, >>> -g >> >> Craig L Russell >> c...@apache.org <mailto:c...@apache.org> Craig L Russell c...@apache.org
