> On Jun 26, 2020, at 3:00 AM, sebb <seb...@gmail.com> wrote:
>
> On Fri, 26 Jun 2020 at 01:56, Craig Russell <apache....@gmail.com> wrote:
>>
>>
>>
>>> On Jun 25, 2020, at 3:23 PM, sebb <seb...@gmail.com> wrote:
>>>
>>> On Thu, 25 Jun 2020 at 19:45, Craig Russell <apache....@gmail.com
>>> <mailto:apache....@gmail.com>> wrote:
>>>>
>>>> Hi Sebb,
>>>>
>>>> Thanks very much for your review and comments.
>>>>
>>>>> On Jun 25, 2020, at 8:29 AM, sebb <seb...@gmail.com> wrote:
>>>>>
>>>>> AFAICT whilst the forms must be signed annually, that does not mean
>>>>> that the form must be signed at the start of each calendar year.
>>>>
>>>> Right. The only requirement is "annual" signing.
>>>>>
>>>>> The current COI file layout assumes a directory for each calendar year.
>>>>> I think that is going to cause complications.
>>>>
>>>> I don't think it will be a problem. Previous thinking on my part was to
>>>> have a "current year" link but that ended up being complicated.
>>>>>
>>>>> I think the directory structure should be flattened.
>>>>> When an officer signs a new form, it should replace the old one (if any).
>>>>> The signing date could be recorded in a separate index file.
>>>>
>>>> This is really complicating things unnecessarily. With the current
>>>> structure, if you have signed three times, there will be three files. If
>>>> you sign in 2024, that document will be in the 2024 directory. For example,
>>>>
>>>> cd documents/conflict-of-interest/2026; ls
>>>>
>>>> Gives you a list of everyone who signed in 2026. And anyone with
>>>> credentials can browse to
>>>> https://svn.apache.org/repos/private/documents/conflict-of-interest/ and
>>>> see the entire history.
>>>
>>> As it stands, the COI form will only show people who have signed in
>>> the *current* calendar year.
>>> At the beginning of the year that is likely to be no-one, even if they
>>> signed as recently as a month or two ago.
>>
>> Why is that a problem? Folks are required to sign "annually".
>>>
>>>>>
>>>>> Or maybe the entry in the index file would be sufficient to record
>>>>> agreement?
>>>>
>>>> The reason I chose the current structure is so it's easy to tell if an
>>>> officer has signed "this year". When an officer is first
>>>> elected/appointed, they sign. Next year, they sign again. If they no
>>>> longer have a position that requires it, they don't sign until "next
>>>> time".
>>>>
>>>> The board may change the policy from time to time, and if they change it,
>>>> the next time anyone signs it, they get the new policy.
>>>>
>>>> "All that is needed" is to create the directory 2021 and copy the
>>>> template.txt from 2020 to 2021 and we're ready for next year.
>>>>
>>>
>>> Seems to me the template could be in the parent (or sole) directory.
>>> If the template changes, update the single copy.
>>
>> That would be possible. We can also include a header like
>> Apache Conflict of Interest Policy
>> (March 2020)
>>>
>>> However, I think the simplest would be to maintain a single index file
>>> with the signing details.
>>> Is there really any need to store a copy of the processed template file?
>>
>> It is a record of what the officer signed and when. We are requiring
>> officers to sign annually so I think it's important that we keep records of
>> when these documents are signed.
>
> Agreed, so the index file should contain sufficient details to capture
> that agreement.
My preference is to *not* keep duplicate information but rather to calculate
status as needed. Which translates to: no index file as long as the information
is available elsewhere.
I think of this tool as informative but not prescriptive. Maybe we can look at
the wording and come up with some less-prescriptive words.
>
>>> However it could be emailed to the officer.
>>> If there was a need to validate which version of the template was
>>> agreed, that could be done by saving a hash of the file in the index.
>>
>> I think it's really simple as it is designed now. Everything is in the open,
>> available for audit/review. Only one thing to do once a year: add the <year>
>> directory and template file. Change the template file only if the board
>> updates it.
>>
>> Only problem I see is that it doesn't work due to some permissions problems.
Which are discussed else-thread. But I thank you here for fixing it.
>
> I agree it's simple to create the documents.
> It's not so simple to check if a person has signed in the last year.
I'd like to solve this year's problem this year and defer solving next year's
problem.
As I see it, there will be 27 people who shortly sign the affirmation.
Secretary will then report that all required signers have signed. (if there are
some who have not signed by the end of summer, Secretary might contact them and
if they are unresponsive, report to the board; or not.)
When the calendar rolls over, allofasudden the tool will report many people who
are required to sign but have not. Which we will all ignore until a new board
comes in. And then we can look at the tool again and decide what to do.
Craig
>
>> Craig
>>>
>>>> Craig
>>>>
>>>> Craig L Russell
>>>> c...@apache.org <mailto:c...@apache.org>
>> Craig L Russell
>> c...@apache.org
>>
Craig L Russell
c...@apache.org
