On 28 June 2018 at 13:44, Shane Curcuru <[email protected]> wrote: > 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.
Whimsy links to the Membership app on the committers pages. So either we drop that link, or we fix the lookup so it works. I decided to attempt the latter. >>> >>> 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. This is draft code; can rename the method if that helps. >>> 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). One is a lawyer who was never a committer and did not submit a membership app either AFAICT For another, see: https://mail-search.apache.org/members/private-arch/infrastructure/200505.mbox/%[email protected]%3E I don't know about the other two. The latter 3 are all listed on the memapp_check page It's possible that the 3 did have logins. It appears that inactive logins were dropped when LDAP conversion happened. >> 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
