How should we handle non-Zeus members?

[Procrat]

What is the best way to remove Kenji Yoshida and Michael Große from our scoreboard?
Ignore commits from non-Zeus members? (If a future Zeus member isn't part of the org yet, then he loses these commits.) Add them to the database but don't show them on scoreboards? (Some statistiscs may turn up weird if we don't keep our heads at it at all times.) Just never ever ever fork another Github project?

[feliciaan]

Maybe a blacklist for the scoreboard?

[iasoon]

We could also ignore commits from non-Zeus members, and fetch them when adding a new member.

What would be the desired behaviour for 'total number of commits', for example?

[Procrat]

@feliciaan: I mentioned three options, which all have their downsides. Why are you in favor of the second option or why do you not care about the downside I mentioned? (The possibility that some statistics might turn up weird.)

[Procrat]

@iasoon: That sounds good. Is this something that can easily be done?

[iasoon]

The most straightforward way is stepping through all repositories again, and checking commits that have not been indexed yet.

An alternative would be to index the commits anyways under a dummy user (this would also show up nice in stats: 'others'), and check the dummy users commits when adding a new user.

[Procrat]

The first option seems like a big workload to do whenever a new user registers, unless you're already thinking of some non-straightforward performance enhancements?

The second option looks nice in a lot of ways, but once we fork a big project, the dummy users might bump itself to a top position on the scoreboard, which isn't desirable imho.

[feliciaan]

@Procrat: isn't it possible to "hide" these users? So calculating their scores and so on, but not showing them. I would only hide them on the scoreboard, not in the repo views.

[feliciaan]

And to solve the bounty points problem, I wouldn't give people people on the blacklist bounty points. To update the blacklist I suppose manual intervention would be best, and also add a notification which is send to the admins when new Zeus members commit who are not yet added to the organisation.

[iasoon]

@Procrat it indeed is a large workload, but how often do we add new users?

[iasoon]

We might actually have a place for this: the 'git identity' model. We could change a commit to belong to a git identity instead of a coder. Afterwards, when we identify one these identities as a member of our GitHub organisation, we could just link the identity to the coder.