tl;dr Adding title field is fine. I see it as secretary's responsibility to harmonize iclas.txt and ldap.
Kudos to sebb for keeping an eye on our records and pointing out deficiencies. We might as well add Suffix to LDAP to cater for the 23 III and 6 II that we have. I've added a comment to IIINFRA-13850 > On Apr 9, 2017, at 10:05 AM, Sam Ruby <[email protected]> wrote: > > On Sun, Apr 9, 2017 at 11:10 AM, Chris Lambertus <[email protected]> wrote: >> Hi Whimsy, >> >> I’m proposing in https://issues.apache.org/jira/browse/INFRA-13850 that we >> implement the Title field in LDAP. This would require some tooling changes >> that would involve Secretary, possibly whimsy code, and infra mods to the >> ap-adduser scripts and other tools that manage and process >> new-account-reqs.txt. >> >> Any thoughts on this change and what would need to be touched to make this >> happen? > > Related: > https://issues.apache.org/jira/browse/INFRA-13834 > https://lists.apache.org/thread.html/0c78dee2654469db7ec5873974570dbd26e37ad1b7c5497817f69112@%3Cdev.whimsical.apache.org%3E > > It looks like we new fields: givenName and title. And a number of > existing fields, including cn and entries in iclas.txt (which includes > separate entries for public and full names). > > --- > > Overall, we should be moving in the direction of having the person > themselves proving (or at least verifying) their name during the > initial account creation process. Prerequisites to a new account are > an ICLA and an invite, and these can happen in either order, so there > are two paths. > > Once created, we need to nail down the responsibility for updating > names. Given that names change infrequently and at least one copy > (iclas.txt) isn't updateable by users themselves, this responsibility > should go to the secretary (Craig, please confirm?), and the necessary > tooling needs to be in place to allow the secretarial team to do so. Secretary is up to this task, given adequate tooling. > > --- > > The format of a new-account-request isn't flexible, but is workable > (I'd prefer JSON or YAML, but adding still more fields at the end is > probably easier): > > https://svn.apache.org/repos/infra/infrastructure/trunk/acreq/new-account-reqs.txt > > If this changes, three (and possibly four) tools will need to be updated: > > https://svn.apache.org/repos/infra/infrastructure/trunk/tools/new-account-reqs.py > https://whimsy.apache.org/officers/acreq > https://whimsy.apache.org/secmail/ > > and possibly: > > https://svn.apache.org/repos/infra/infrastructure/trunk/tools/updateiclas.py > > --- > > The secretarial team already can update cn and givenName; and I > presume that we will be allowed to update title too when it is added. > > There is a tool for detecting mismatches between iclas.txt and LDAP; > but given that givenName and title aren't in iclas.txt, that is not > likely to be affected. > > What I would like to see as the preferred interface for the secretary > to use to update names is the roster tool: > > https://whimsy.apache.org/roster/committer/ Yes, this makes sense for corrections, once tooling is in place. Note that it's relatively easy to fix most of the issues in https://issues.apache.org/jira/browse/INFRA-13834 given that we understand that: Dr. is a title; van, von, Van, and Von are part of family name, II and III are suffixes, and most everything else is part of given name. Note also that asian names in particular are problematic because many iclas have last name first which is the custom, but many iclas have last name last which meets Western custom. I attempt to figure out which is which but I know there are some wrong entries. I'm looking forward to the time when we have the ability for people to enter their own icla information, assuming that they can understand that there are three fields required: Family Name, Given Name, and Title (optional). Of course, we also have a couple of III lurking in there. Craig > > This tool already will update LDAP and iclas.txt. > >> -Chris > > - Sam Ruby Craig L Russell Secretary, Apache Software Foundation [email protected] http://db.apache.org/jdo
