A few thoughts:
Adding to the information we collect about a user is a common thing to do in OpenACS, so I think the Base Profile probably belongs there.
It seems to me that a student who is looking up info on their TA would like to see their staff profile, not their student profile. So what I would suggest is allowing multiple profiles and displaying them all when a user goes to look at another user's profile.
This could get really tricky, though - what if a student TAs for more than one department and has different office location and hours for each? Then we'd want them to have two Staff profiles as well as a Student profile. I think for the purposes of getting the thing done quickly one profile per user is probably good enough for now, but it should be written with having multiple, even unlimited profiles in mind for later implementation.
There are really two possible restrictions on each field in a profile - is the user required to enter it, and can they keep it private (which means only admins can see it)? The admin UI for specifying the list of attributes in each profile will need to allow the admin to mark fields as mandatory and/or suppressable.
A really spiffy search facility would let you choose which types of profile to search, and then let you specify values to search for in particular fields. But, and this is a big but, this is where having the profiles split between OpenACS and dotLRN is a problem. dotLRN can reach down into the base profile in OpenACS and include it in a sophisticated search, but OpenACS will need it's own profile search facility for the times when dotLRN is not installed. I don't like this, since it's duplicate code, but I don't see a good way around it at the moment.
Ok, that's all I can think of - time to go walk the dog. :)
