On Mon, May 15, 2017 at 11:54 AM, Craig Russell <apache....@gmail.com> wrote: > Hi Sam, > >> On May 13, 2017, at 7:41 PM, Sam Ruby <ru...@intertwingly.net> wrote: >> >> On Fri, May 12, 2017 at 6:51 PM, Craig Russell <apache....@gmail.com> wrote: >>> >>> I know up front that this is a second icla. So good idea for this to be a >>> different action. >>> (O) icla >>> (O) additional icla >>> (O) ccla >>> >>> Full Name: this is the key to find the entry in iclas.txt >>> Public Name: this should replace the public name in the entry >>> email: this should replace the email in the entry >>> file name: this is generated from Full Name and is the directory for the >>> iclas >>> >>> If a third icla comes in, I can handle this manually. Unless it's easy to >>> put in now: >>> >>> if full-name/full-name.pdf (or full-name/icla.pdf and icla.pdf.asc) already >>> exists: >>> find the largest n in full-name/full-name<n>.pdf >>> file the new icla under full-name/full-name<n+1>.pdf >>> >>> and replace Public Name and email in iclas.txt as for the second one. >> >> Handling the 'nth' case doesn't concern me. >> >> What does concern me is the ability to change the Full Name (and >> therefore the filename). If you do that, this won't be a second ICLA, >> and the code won't be able to identify an existing line in iclas.txt >> to update. > > Select (O) additional icla > > The Full Name is the key to the entry you want to change. I don't know if > there are any cases where the Full Name does not exactly match the file name > (modulo converting Non-US-ASCII letters to latin letters). That is, someone > changed file name after filling full name. But that is not the usual case. > For our purposes, we can disallow changing the file name and always take it > from the full name. This might be a good thing to do for all iclas. > > Maybe an update to icla-lint would catch any cases where the full name and > file name do not match.
The part of the 5th field after a semicolon is, indeed, a key field. Many of which reflect decisions that were made before the workbench existed, or before I was secretary for that matter. :-) >> I'd like to suggest as an alternative, two fields: one identifying the >> existing user, > > This is the full name ~== file name I was thinking of a field like the one present here: https://whimsy.apache.org/roster/committer/ You will be able to enter a name, and id, or an email, and it will find the correct entry. It could then display the full name value for confirmation. >> and one identifying the new email address. > This is the email address > >> This should >> handle the bulk of the additional icla requests. Anything else can be >> done manually? > > We also should allow updating the Public Name if it is different from what is > in iclas.txt. Once the secretary enters the full name, the iclas.txt entry > can be brought up and the existing public name and email (and file name) > displayed read-only. The proposed new public name and email are taken from > the incoming mail. Secretary can change public name and email depending on > what the new icla says. Seems reasonable. > The new workflow: > > Categorize > (O) icla > fill all fields > File > Warning: documents/iclas/craig-russell.pdf already exists > Categorize > (O) additional icla > fill Full Name > tool locates iclas.txt entry and displays read-only file name and two new > fields Existing public name and Existing email > tool fills public name and email from incoming mail > secretary reviews and possibly changes public name and email > File > secretary reviews proposed changes > continue WFM. I would also guess that in many cases the email text will indicate that this is a replacement ICLA, and you can skip a few steps. > Craig >> >> - Sam Ruby > > Craig L Russell > Secretary, Apache Software Foundation > c...@apache.org http://db.apache.org/jdo - Sam Ruby
