Stop "rebalancing" karma, and base it on effort instead

Just switching this off will cause new problems - it needs much further discussion and a spec that addresses the reasons the balancing was implemented in the first place.

  - Nobody has ever actually gone through the Karma list to assign the correct number of points to each action. We just have guesses.
  - By weighting categories we encourage use of the less popular parts of Launchpad.

I've previously suggested a tweak to the existing balancing - if we simply round the scaling factors to the nearest 10, 50 or 100 then the jumps will become much less frequent.

I think the idea of using 'estimated minutes' is a decent idea, and the first proposal I've seen for choosing Karma scores for actions besides pulling a number out of a convenient orifice.

We should also switch to using log(karma)*factor instead of raw karma at the same time which has previously been discussed.

So the proposal is to review the Karma points based on the estimated number of minutes something took? I guess that sounds reasonable, but I'm curious as to how that works out in certain cases. For translations, for instance, do we award a karma entry for each string translated, or for each page posted?

I'd like to know if rebalancing is still necessary when we do the logarithmic change, by the way.

I don't understand why it's desirable to "encourage use of the less popular parts of Launchpad".

For translations, award karma for each string translated, just as Launchpad does now.

Putting karma on a logarithmic scale would make this bug harder to see, but then it would make everything about the karma system harder to see. :-)

Matthew Paul Thomas wrote:

> I don't understand why it's desirable to "encourage use of the less
> popular parts of Launchpad".

Because we want the community to handle support requests rather than
Canonical having to handle the entire burden. Karma's reason for existence
is to be a motivator, not just be a scorecard, and we should motivate people
to do work in areas that benefit the community rather than the traditional
areas of interest. If we find people are not bothering to report bugs, we
can bump off the score for doing so, or if support requests are not being
triaged, or whatever. The scaling was implemented as a temporary fix to
automate this somewhat until we had enough data to allocate the scores
properly (and the time to analyse this data...).

--
Stuart Bishop <email address hidden> http://www.canonical.com/
Canonical Ltd. http://www.ubuntu.com/

Well, now I don't understand why we don't want Canonical to get more support business. :-) Also, there isn't necessarily any correlation between "less popular parts" and "areas that benefit the community". I've revived the KarmaTypes specification to discuss the issue more thoroughly.

Seems like "rebalancing" karma or some other mechanism is completly broken. I had nearly 65000 karma one or two months ago. Today, I logged into launchpad and my karma is 2951 (!!!). Is that "rebalancing" or something else you wanted? I don't want that, I just want my karma back ;).

Vadim, that is a separate issue. More details:
<https://help.launchpad.net/KarmaReductionJan07>

Well I read https://help.launchpad.net/KarmaReductionJan07 and there's a note that says:

  Everybody's Launchpad karma decays slightly over time, to reflect how recent your work has been.

Most of us answering the posted questions are volunteers and as such we do it only when time permits. Karma points are our only incentive so if one is so busy when he logs in back he'd find his karma reduced! As if he hasn't contributed anything.

To reflect how recent ones work is, one should use time/date instead and leave karma points alone.

This bug report is about how much karma each type of action gets originally, not about how fast it decays afterwards.

It's probably very difficult to keep everybody happy when using any sort or points system.

What about keeping a record of peoples highest scores?
Either a persons highest ever score, or their total over the past 3 months or 1 year.

[Expired for Launchpad because there has been no activity for 60 days.]

This problem is still happening, as demonstrated by bug 260307.

I fully agree with the previous posts, especially the issues described in bug #260307. I can follow the considerations to motivating people to give support and to write specifications.

Nevertheless, it should be kept in mind, that the most important activity within the area of OpenSource software is the writing of code, implementing of features and including of patches that fixes bugs to the source. According to this, the karma earned by real coding acitivities (commit a revision...) is much to low.

To make the karma system reasonable it is necessary to tune the weight of different activities.

Hi!
I've been a LP member for a reasonable amount of time and have at least a few bugs reports started, some comments on bugs, etc. I recently started my own project on Launchpad, reported bugs in it, fixed them, commented on them, linked them to Bazaar branches, etc. My Karma might have increased by 100 odd points for the work, which considering how much I've got for other activities, is what I'd like it to be.

But yesterday, I wrote two blueprints, and my Karma shot up from around 500-600 to 2230. To give you a break up:

Bazaar Branches 79
Bug Management 479
Specification Tracking 1670
Translations in Rosetta 2

I don't think I deserve 1670 for just starting two blueprints! "Not mine!" ... ;)

Umang

This seems to have improved very recently. A few weeks back, my karma was absurdly high (in a few if not many thousands). It is back to a sane 1992 today

I don't remember when I last checked before today, so I don't know how high it actually was and when exactly it came down.

I don't get the reductions. I'm new and I don't mind if you guys have a lot more karma than me. I rather see who has done what and how much experience they have in this community. I also don't want my karma to disappear when I get more of it.

If somehow karma degradation is important 65000 -> 2951 is too much in a few months. That is very demotivating from my perspective, someone who is new and doesn't know what time he can give to this project. If I do some work now to try it out at the cost of school time, if I need to stop to do more school, then all that work that I've done is worthless.

Some times I think people, especially us programmers, want to do something because it can be done and not because it's smart. That honestly is what I think the thought process was in forming this spec.

I kind of understand where the original poster is coming from, but I disagree with the notion of making “karma” based on minutes invested.

An action’s importance *does not* necessarily correlate to the time required to complete it. Although this is often the case, it isn’t guaranteed. I also think it would significantly diminish the importance of “low-hanging fruit” tasks—items which are quick and easy to do, but the user benefits because they see the results faster. It’s also beneficial to the project to complete low-hanging fruit tasks because then they aren’t sitting around forgotten while everyone’s focus is all the long, intimidating, difficult tasks. :)

Furthermore, everyone has different skillsets; a task might take you 10 minutes to complete, but only take me 5.

…

That said, I think tracking time would be a very useful statistic to track. I just don't think it should supplant karma, or be the only/primary measure of contribution.

I know that karma is a low priority for Launchpad devs, and it mostly seems to work well, but some of the weights given to some activities seem a bit odd.

I've been contributing a lot to documentation through both code commits and documentation bug triage for the past several months, and have seen my karma reach ~850 through these tasks. It has been a slow, gradual climb.

Within the past two days I've created two blueprints, and my karma score has nearly doubled (Launchpad tacked on ~700 points for the blueprint work). It may be the case that creating a blueprint demonstrates commitment to the strategy and goals of a project, and that is why it is given more weight. It still seems a bit odd to see my karma nearly double given the amount of work I had put in previously.

On Wed, May 4, 2011 at 6:48 AM, Jim Campbell <email address hidden> wrote:
> Within the past two days I've created two blueprints, and my karma score
> has nearly doubled (Launchpad tacked on ~700 points for the blueprint
> work). It may be the case that creating a blueprint demonstrates
> commitment to the strategy and goals of a project, and that is why it is
> given more weight. It still seems a bit odd to see my karma nearly
> double given the amount of work I had put in previously.

Very few folk use blueprints; so the work there is proportionally
larger in impact; we are going to be merging blueprints with bugs
which will address this I think.
https://dev.launchpad.net/IssueTracker

-Rob

max_scaling in the [karmacacheupdater] section of launchpad.conf can
be used to limit the maximum scaling factor if we want as a quick fix.

--
Stuart Bishop <email address hidden>
http://www.stuartbishop.net/

Hi. Stuart a quick dirty fix is tempting given that most blueprints never get implemented...they are wishlist items.

But can we just turn off rebalancing? The karma-cache update script consumes a lot of memory and time; users reports bugs or ask questions about the momentary zero karma. would removing the balance step improve Launchpad's performance?

On Wed, May 4, 2011 at 9:31 PM, Curtis Hovey <email address hidden> wrote:
> Hi. Stuart a quick dirty fix is tempting given that most blueprints
> never get implemented...they are wishlist items.
>
> But can we just turn off rebalancing? The karma-cache update script
> consumes a lot of memory and time; users reports bugs or ask questions
> about the momentary zero karma. would removing the balance step improve
> Launchpad's performance?

Change the setting to 1, but make sure people are warned - a lot of
peoples karma will drop hugely and that always causes fireworks. I
don't think the rebalancing is an issue on performance so no need to
rewrite the script.

--
Stuart Bishop <email address hidden>
http://www.stuartbishop.net/