[PATCH] comments: display username and name instead of only username

[Thomas De Schampheleire]

On Mon, Apr 20, 2015 at 9:13 PM, Mads Kiilerich <mads at kiilerich.com> wrote:
> On 04/20/2015 06:51 AM, Thomas De Schampheleire wrote:
>>
>> On Sun, Apr 19, 2015 at 4:38 PM, Mads Kiilerich <mads at kiilerich.com>
>> wrote:
>>>
>>> On 04/19/2015 05:57 AM, Thomas De Schampheleire wrote:
>>>>
>>>> I guess this is a place where a global configuration could make sense.
>>>> :-(
>>>>
>>>> It would be nice to show everything everywhere but especially in the
>>>> tables
>>>> with commits that is not an option.
>>
>> Currently:
>> - pull request author: username (full name)
>> - pull request reviewers: full name
>> - pull request commit overview: username only
>> - repo summary/changelog: username if user found, else name from commit
>> header
>> - changeset detail: username (full name) if user found, else name from
>> commit header
>> (I haven't checked all other places yet, like notifications...)
>
>
> Thanks - a review for consistency has value ... even more so if we can
> establish guidelines for maintaining that consistency.
>
>> I would go for:
>> - pull request author: full name (username)
>> - pull request reviewers: full name (username)
>> - pull request commit overview: username only
>>
>> For changeset/changelog displaying, I'm not fully sure: suppose
>> someone uses the same e-mail to commit under two different display
>> names, for example 'John Doe' and 'John Doe (scripted)'. In this case,
>> one would probably expect the name from the commit header to appear in
>> the changeset/changelog details.
>> But the correlation to the actual user as known in Kallithea is also
>> useful, so we should show that too, at least in the changeset details.
>> In case both the name in the commit header, and the name known to
>> Kallithea is the same, there would be some duplication if we show
>> both, though. Maybe we should show both but clearly indicate that one
>> is coming from the commit header and the other (if available) is the
>> detail from Kallithea.
>
>
> Currently we always use the user entry and show the username if the email
> address is known (and we allow the system to email the user - we will never
> spam users / email addresses that are unknown to the system). I think that
> is fine. If the user wants to commit under different names, he should use
> different email addresses.

While I understand your reasoning, it doesn't work in a corporate
environment where you have only one e-mail address and no easy way to
create aliases.
I'm not saying that e-mail address should no longer be unique in
Kallithea. I'm just saying that if a user commits with a name
different than the name in Kallithea (under the same e-mail address)
we should not ignore that or hide it in Kallithea.

>
>> So then we'd have:
>>
>> - repo summary/changelog: name from commit header
>> - changeset detail: both name from commit header as full name (username).
>>
>> For other places that I did not identify above, 'full name (username)'
>> would be preferred, unless if there is limited space in which case
>> username could be shown alone.
>>
>> What do you think of that?
>
>
> Looks fine ... except that I like that we always use the user entry if the
> email address is known and only fall back to the parsed full name if the
> parsed email address is unknown.
>
>>
>>
>>> Somewhat related: the username and email address will often have a
>>> trivial
>>> mapping. I would like to get rid usernames and just use email addresses -
>>> also for login, perhaps with a config option for a default @domainname
>>> that
>>> always should be stripped.
>>
>> I'm not really opposed to that, but it does mean more typing for the
>> typical user.
>
>
> In which cases? We have completion for @annotation and reviewers ... and the
> typical user will use a domain that will the default for the system and thus
> can be left out.

I was thinking of @annotation (wasn't aware that it had autocomplete)
and login. But it's a non-issue, really.

>
>>
>>> Another thing is the confusion that comes from having separate first name
>>> and last name fields. Cultures put given name and family name in
>>> different
>>> order ... and sometimes people compensate for that in firstname/lastname,
>>> sometimes they don't. I thus prefer to have a "full name" field with the
>>> preferred spelling of the whole name and something like a "nick name" or
>>> "common name" with the name the person usually goes by. (In addition to
>>> that, there might be a "need" for having both the "real" name and the
>>> name
>>> transcribed to a different culture.) This ends up as a completely
>>> different
>>> problem but it might indicate that it could be relevant to have some kind
>>> of
>>> configurable template for naming ... or a couple of templates for "short"
>>> and "long" name.
>>
>> I was planning to touch upon that subject in my previous reply, but
>> left it out because I thought it would lead us too far :)
>>
>> Anyway, I think we should keep external authentication databases into
>> account: we should be able to map data from such databases into the
>> scheme we propose. Our LDAP database does have a separate firstname,
>> lastname, a full name and a common name, so this would be mappable on
>> your proposal. Note that the 'common name' in our database is not
>> following the local convention of 'Firstname Lastname' but is
>> 'Lastname Firstname' regardless, and I cannot change it.
>
>
> In that case it is the LDAP admins who made the decision. It is better to
> expose their wrong decision that to try to fix it in the vcs system ;-)

Agreed.