On Sun, 28 Jun 2020 at 01:41, Craig Russell <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. > 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. > Ciao, > Craig > > > > Cheers, > > -g > > Craig L Russell > c...@apache.org >
