Now that I can actually test some stuff, I'd like to circle back to the
technical details.
Sam pointed out how the script can calculate "today's" list of required
signers. That will become part of the script.
The structure would look like:
COI/ # Should this be more like ConflictOfInterest?
template.txt # this year's template
fy2020
template.txt
clr.txt
rubys.txt
...
fy2021
template.txt
clr.txt
rubys.txt
...
But we need to discuss how to track the affirmations year after year. So, the
tool will need to:
Check out the COI directory with a depth of one so the list of fyxxxx is
available. Then, the tool needs to work with the latest fyxxxx and get a
listing of the signers and get the template for that fy. I'm imagining that the
template might change year-over-year. To make things easier, we could archive
the template in the fyxxxx directory but keep the current template in the top
level COI directory.
So I'll look at adding an entry to documents.rb to allow the tool to access a
list of the most recent fyxxxx entries. Something like class COIFiles with a
self.getlisting method that returns the names of files in the most recent
(biggest by sort order) directory.
Other details to worry about right now?
Thanks,
Craig
> On Jun 8, 2020, at 10:05 PM, Craig Russell <apache....@gmail.com> wrote:
>
> Here's how I'd like to have the COI affirmation tool work. Once the
> discussion here nears consensus, I'll share the plan with the board. Unless
> anyone thinks that the tool should have a wider discussion on board@...
>
> The tool is protected by officer login and the credentials are sent to the
> server so that only officers can see the results.
>
> The tool executes one GET to retrieve:
> - the current COI document from foundation/officers/COI/fy2020/template.txt
> - the current list of officers who are required to affirm their agreement
> with the COI foundation/officers/COI/fy2020/signatories.txt
> - the current list of officers and their status (whether they have already
> affirmed)
>
> If the user is required to affirm, and has not done so already, the current
> COI document modified with the officer's availid and date is presented to the
> officer in a scroll window along with two buttons: (Cancel) and (Affirm)
>
> If the user is not required to affirm, or has already done so, or (Cancel) is
> pressed, the list of officers and their signing status is displayed.
>
> If Affirm is pressed:
> - the officer's availid and timestamp is sent to the server via POST
> - POST processing:
> -- the COI document with the officer's availid and date is written to the
> file called foundation/officers/COI/fy2020/availid.txt
> -- the list of officers and their signing status is displayed
>
> Open questions:
> - how to manage the list of officers required to affirm? one possibility is
> to create a file: foundation/officers/COI/fy2020/officers.txt which is
> created by secretary/chair at the beginning of each fiscal year.
>
> - is officer credentials sufficient for the purpose of this tool, or should
> the tool be restricted to those officers required to affirm?
>
> Feedback?
>
> Craig Russell
> Director, Apache Board
> apache....@gmail.com
>
>
>
>
Craig L Russell
c...@apache.org
