sebb wrote on 6/28/18 7:21 AM: > On 25 June 2018 at 12:01, sebb <[email protected]> wrote: >> I've been trying to check that we have files in member_apps for all >> entries in members.txt. >> >> This is proving quite difficult, as there are lots of ways of spelling >> names, for example: >> >> Joe Bloggs >> Joe Bloggs, Jr. >> Joe A. Bloggs, Jr. >> Joseph Bloggs >> etc. >> >> It occurs to me that members must have availids (*), so one possible >> solution would be to use that as the file name (or perhaps as a >> filename prefix?) >> >> AFAIK there are no duplicate names (yet) in members.txt, but that is >> not impossible going forward. >> >> Of course, this assumes that availids are immutable and everlasting.
Reasonably immutable, although we have had several changes over the years. But that begs the question: what is the organizational purpose of this work? I.e. how specifically does this help volunteer leaders at the ASF over the long term to spend less time on paperwork? I'm all for keeping records organized by a strongly-typed system, but it feels like a lot of svn log churn to re-name all the member app files again to availids, if that's what you're suggesting. We do need to be able to find any member's application at any point in the future, in case there's some odd legal question. We'll only have to do it rarely, and it will never be something we have to do immediately. >> >> Note: I am planning on committing some library code to handle all >> access to the member_apps files so that apps all use the same methods >> to find the files. Nice, and thanks for the method comments. Just a reminder: self.find returns [[], []], which is different from other ASF module .find methods. That makes sense; just wanted to note it since we've had questions about differences between [] and .find calls before. >> Similarly for iclas, although we don't have the same problem with >> matching file names, as iclas.txt contains the filename stem. >> >> >> (*) There is one member without. The file could be left as is, or >> prefixed 'notinavail' I suppose. > > Actually there are 4 members without ids; these don't get extracted by > the code so their membership app files (if any) are not matched. Wow, how can someone not have an id? Best guess from infra peeps is that those 4 people haven't logged in since the switch to LDAP, so they don't have an ID in LDAP (but obviously did when we had shell logins). > However I have managed to fix all the other mismatches by some > renaming of the files. > Sometimes the app file contains a name that does not exactly match the > legal, public or members.txt name. > In which case the filename does not exactly match the name in the file > itself, but it does match one of the other 3 names. > > I still think we should consider using avail ids where they exist. > Given that entries without ids don't currently get extracted, that > would not affect the outcome. I'd really like to see more feedback from people, especially Secretary, before mass-renaming all the member apps. -- - Shane Whimsy PMC & Member The Apache Software Foundation
