Matching member apps with members.txt

[sebb <se...@gmail.com>]

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.

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.

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.

Re: Matching member apps with members.txt

[sebb <se...@gmail.com>]

On 28 June 2018 at 13:44, Shane Curcuru <as...@shanecurcuru.org> wrote:
> sebb wrote on 6/28/18 7:21 AM:
>> On 25 June 2018 at 12:01, sebb <se...@gmail.com> 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/%3C679afc1c281f0644c704c7bc48283298@apache.org%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

Re: Matching member apps with members.txt

[Shane Curcuru <as...@shanecurcuru.org>]

sebb wrote on 6/28/18 7:21 AM:
> On 25 June 2018 at 12:01, sebb <se...@gmail.com> 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

Re: Matching member apps with members.txt

[sebb <se...@gmail.com>]

On 25 June 2018 at 12:01, sebb <se...@gmail.com> 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.
>
> 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.
>
> 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.

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.