On Sun, 28 Jun 2020 at 14:54, Craig Russell <apache....@gmail.com> wrote: > > > > > 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. ;-)
Done by changing a single constant... > Craig > > > >> Ciao, > >> Craig > >>> > >>> Cheers, > >>> -g > >> > >> Craig L Russell > >> c...@apache.org <mailto:c...@apache.org> > Craig L Russell > c...@apache.org >
