Auto-completion when tagging users does not work

[cmenguy]

Currently it seems that tagging users works (at least with Github.com, haven't tried yet on the on-premise version but I assume it is the same), but there is no auto-complete.

It would be nice to support auto-completion in the app similar to what Github does, I tend to rely a lot on auto-completion to find the users I need to tag for review.

[amit1rrr]

Auto-completion when tagging users would be a nice UI enhancement for commenting. The challenge is GitHub doesn't have any autocomplete API. One option I can think of is to provide autocomplete API on ReviewNB side which is restricted to all the signed up users of ReviewNB. I.e If the user is part of your organization and has used ReviewNB at least once, then he/she is available for auto-completion.

I know it's not the perfect solution but the best I can think of given the data we have. Do you think this is a good 80% solution?

[cmenguy]

👍 on restricting to the signed up users on ReviewNB, that would cover most of it I think.

[cmenguy]

Actually @amit1rrr I was looking at the Github API and it seems you can list contributors for a given repo: https://developer.github.com/v3/repos/#list-contributors - so if I'm not mistaken, I think it would be doable at the repository level to offer auto-completion for all the contributors of that repo, does that make sense? I think it would be more useful than restricting on the users who have signed up for reviewNB.

[amit1rrr]

Using repo contributor list would be better than using ReviewNB' signed up users list for autocompletion. There are couple of challenges though,

• GitHub returns max 100 contributors per call, so we'll have to paginate the results.
• If we paginate often with too many threads, our API calls will get throttled by GitHub
• Fetching list in real time would make for a sluggish auto complete experience

To counter these challenges we could fetch the contributor list offline and maybe update it periodically. That way autocomplete is both, more responsive and comprehensive.

Sorry if it was too much information, I'm just thinking out loud and using this issue to document everything.

[cmenguy]

Yes @amit1rrr I definitely think if you were to add something like this, doing it in a batch manner in the backend every few minutes would be good enough - contributors probably don't change that frequently for most repos, so once an hour or more would probably be enough.

I wonder what is considered a "contributor" in Github API, and it would be good to document this as part of what would be included in autocomplete - is someone who contributed a PR but does not have direct commit access considered a contributor? It might matter more for github.com vs your on-prem solution where I suspect in most orgs everyone who needs to commit usually has direct access.

[amit1rrr]

I wonder what is considered a "contributor" in Github API

From what I can tell, it's actually list of users who have made any commits on that repository.

A nice auto-autocomplete list would be union of following,

1. Contributors on repository
2. PR related users (author, assignee)
3. Optionally if PR is on an org repository - all publicly visible members of the org

1 is obvious.

2 so that person who opened the PR first time is available under auto-complete

3 for product managers and other executives who might not be contributors but needs to be included in conversations.