This idea was suggested to me by someone on one of my SE sites (not sure if public linking is desired so not doing that now):
If we have a reputation score (of whatever name) – and I hope we won’t, but that’s being discussed elsewhere – then we should not also tally up a network-wide (instance-wide) reputation score. On SE the number is not meaningful; did you get that score by having 175 accounts, or by answering on high-traffic sites, or by providing a large volume of high-quality content in smaller corners of the network? A number that merely adds up your reputation on all your sites isn’t useful.
Further, if we have reputation, we should allow per-site customization of rep settings – and not having a network-wide total makes this easier. Maybe some sites want question upvotes to be +5, some +10, and some 0. Maybe some sites don’t want to award rep for answer acceptance. Maybe some sites want edits to be worth more than +2. Maybe some sites don’t want to penalize casting downvotes. Maybe some sites want to penalize them more. Sites should be able to customize these values, and doing so makes a network-wide number even more meaningless and confusing.
(This also means that “no reputation” is an implementation of “customize rep values”; a site could set them all to zero. So if we can’t decide to eliminate rep, let’s enable this path to a site doing so.)
One might say that variation within a network is confusing, but: on SE this already happens (StackApps and Area51), and it already happens with SE clones (Physics Overflow looks a lot like SE but has different values), and at Codidact we are emphasizing the idea of a network of communities so I think the idea of different community standards won’t be hard to explain.
If privileges are based on reputation, then yes we need to do something about that. Elsewhere we’ve been talking about privileges being based on related actions, so I’m hoping that even if we do have rep we won’t base privileges on it.
My hope is that MVP won’t expose rep at all, so if we decide not to have it we don’t have to take it away. If we can decide on “no rep” in time for MVP then great. If the decision takes longer, we should in the meantime not show it or imply it exists.
I happen to like Reputation. Arguably it was one of the key things that got me active enough in SE to eventually work my way up to not caring so much about Rep and just “helping others”. But I see the arguments both ways.
That being said, I think I have already mentioned elsewhere that pretty much everything relating to “points” - i.e., how much per action (which you specifically targeted here), how much needed for a privilege, etc. - should all be configurable per site/community. As noted, SE already does that to a limited degree (primarily on “how much to get certain privileges”) but it can and should all be configurable. Even if (which I doubt) we have all the same for all communities in the primary instance of Codidact that we set up, another instance elsewhere might have totally different ideas and making the change in a database is a lot easier than having to tweak the code. For example, a company using Codidact in-house for their own purposes might only care about Reputation so they can use it to push goals on their internal help-desk employees. Or whatever.
As far as the “recalc” issue. That is easy enough to implement in the “simple” way. But making it work in a “don’t change the history” way is really very easy to do too. All that is required is a history of the point-related changes (action/badge/privilege values). Then a recalc uses that table to determine when each action occurred. But alternatively there should also be an override to yes recalc old stuff using the new values, e.g., if a month into the system (or into a new site/community) we decide to make a change it logically could be retroactive at that point even if we don’t want a change 5 years later to be retroactive.
I think it’s already clear and uncontroversial that rep values (if used) should be set in the database rather than hard-coded. But that could force the values to be the same for an instance; I want us to go a step farther and make them settable for individual sites within an instance. Doing it that way from the start is way easier than trying to retrofit it later.
I already wrote up somewhere (I can find it, but not right now) that all sorts of things should be configurable at the instance and the site/community level. I have long been a believer in the “everything in the database” mode of operation, and this system is no exception. And for those who complain about “extra queries”, just read everything at system startup and persist it while running (very much dependent on language/environment). Plus a query to get a handful of configuration items from a very small table costs basically “nothing”.