OK, let's just clarify a few things beforehand, as there is no edit.

Not sure if it's just terminology, but I strongly suggest peak volume instead of peak value. It would be a shame to loose karma because your peak was at night (split across two days), influenced by day-of-week, holidays, etc.

BTW, you say 100 : 1 but the ratio is 10 : 1 karma in the examples

Can someone clarify the X axis relation in the graphs (Niels) ? I can see the data points are weekly, but I don't know if it means the value is SUM of dowloads that week, just a snapshot for a single day or daily AVG for that week which might influence karma multiplier choice... Or, if it is possible, could I get daily resolution data for a project just to see clearer ?

About updates being too close - this is actually not that big of a problem as I initially thought. It is on the current graphs as you can't differentiate between versions, but since these ARE separate files, they might just as well be statted separately for karma purposes.

Here's another graph, this time for OMWeather - it has updates more often than mapper so you can see the principle even better:

Ok some observations:

1. There is no way to edit your submitted solution in Brainstorm (Bug submitted). There is no 'Brainstorm' component in bugzilla either.

2. The discussion of this brainstorm topic at the Brainstorm page itself has only about 13 replies, here at Talk has reached 7 pages already. I propose using Talk to discuss brainstorm ideas, or at least provide a way to link a brainstorm idea to a Talk thread.

3. I propose prompting for a reason why you are voting 'no' on a proposed solution. I think it is good to gather the 'cons' of a proposed solution to give way to a new proposed solution, or to clarify misunderstandings. Also, it might be good to provide a way to change your vote for a proposed solution from yes to no or no to yes.

Just to comment on peaks. This can be abused as well. A version 1.0 can get a high peak, and v1.0001 can also get a high peak for fixing a bug. v1.0002 can get a high peak again for fixing another bug. A developer can get more karma by spreading bug fixes across different versions.

Err, the way I understood it peak karma is not cumulative, you always get the value for the last peak.

Why are we even discussing changing this metric now, so close to a new device release?

(...and before anyone jumps down my throat I am just playing the devils advocate here.)

To a casual observer it appears that someone doesn't like or think that a member or members who have high karma now, deserve any of the future perks that may come from that metric.

If this is the case, what's going to happen the next time if high karma earners from this change fall out of favor?


What I'm saying is that if a future perk, developers device, or all expense paid trip to Las Vegas (release rumors early and update often ) or something is going to be determined by karma, changing the equation of how karma is calculated now might seem a bit tacky and disingenuous.

Some may discount my post based on my relatively low karma but I am an observer of the process.

I'm proposing to discuss this now in order to have the machinery totally fine with a post-N900 device comes. Yes, we are that slow...

Is having some kind of routine to keep track of installed software built into application manager that can report back to maemo.org what is currently installed when it performs an update. Perhaps this is going to far, to much like big brother?

http://popcon.debian.org/

This has been done and is available for quite some time.

Here are the formulas in use: http://wiki.maemo.org/Karma

I've proposed that there be more links to get to that and similar pages. See bug 4959 (vote and comment please!)

https://bugs.maemo.org/show_bug.cgi?id=4959