Active Topics
-
Firefox with Leste (5)
to Maemo 7 / Leste by teroyk - 3 days, 20 hrs ago -
Handbook (2)
to Maemo 7 / Leste by teroyk - 4 days, 19 hrs ago - more...
attila77 |
2009-09-10
, 21:32
|
|
Posts: 3,319 |
Thanked: 5,610 times |
Joined on Aug 2008
@ Finland
|
#11
|
Yep, I had that problem too. Either we're all dead blind, not seeing the forest from the trees or it's really missing. Considering this is a recurring thing, I filed a bug, hopefully it'll make this clearer...
 |
|
2009-09-10
, 21:33
|
|
Posts: 11,700 |
Thanked: 10,045 times |
Joined on Jun 2006
@ North Texas, USA
|
#12
|
Look, this is another one of those fuzzy things that tends to get pulled into polar corners. It shouldn't be.
In principle Quim's point is highly valid, and I doubt there would be much disagreement overall. The doubt and discomfort lie in the details.
The best mindset when approaching a fuzzy measuring challenge is to accept at the start that it will be imperfect, and you are looking for the least imperfect solution(s) without expending unreasonable effort.
To that extent we start by recognizing the obvious metrics, determining a useful algorithm and mitigating errors and unknowns.
One unknown is uninstalls. Ok, fair enough. But surely this unknown is mitigated by the fact that ratings tend to be applied after a download. And utlimately almost every app will be uninstalled, updated, reconfigured, etc so this is an acceptable, common risk not isolated to just a few apps but rather spread out over many.
Downloads are a very useful metric. So are ratings. But the point was made that a highly-rated app may have fewer downloads than one rated a bit lower. Fine-- then we weight them accordingly and/or introduce factors into the algorithm that accomodate this. Nothing new here; measurement systems encounter this all the time.
Statistics will tell you that reasonable perfection is attained at about 95% of your goal-- any further and you enter the realm of diminishing returns.
Anyway I think this is achievable... but maybe it does require more thought experiments...
In principle Quim's point is highly valid, and I doubt there would be much disagreement overall. The doubt and discomfort lie in the details.
The best mindset when approaching a fuzzy measuring challenge is to accept at the start that it will be imperfect, and you are looking for the least imperfect solution(s) without expending unreasonable effort.
To that extent we start by recognizing the obvious metrics, determining a useful algorithm and mitigating errors and unknowns.
One unknown is uninstalls. Ok, fair enough. But surely this unknown is mitigated by the fact that ratings tend to be applied after a download. And utlimately almost every app will be uninstalled, updated, reconfigured, etc so this is an acceptable, common risk not isolated to just a few apps but rather spread out over many.
Downloads are a very useful metric. So are ratings. But the point was made that a highly-rated app may have fewer downloads than one rated a bit lower. Fine-- then we weight them accordingly and/or introduce factors into the algorithm that accomodate this. Nothing new here; measurement systems encounter this all the time.
Statistics will tell you that reasonable perfection is attained at about 95% of your goal-- any further and you enter the realm of diminishing returns.
Anyway I think this is achievable... but maybe it does require more thought experiments...
__________________
Nokia Developer Champion
Different <> Wrong | Listen - Judgment = Progress | People + Trust = Success
My personal site: http://texrat.net
Nokia Developer Champion
Different <> Wrong | Listen - Judgment = Progress | People + Trust = Success
My personal site: http://texrat.net
 |
|
2009-09-10
, 21:37
|
|
Posts: 1,436 |
Thanked: 3,144 times |
Joined on Jul 2005
|
#13
|
I added a solution (typo in title and formatting didn't work (do I need to put <p></p> or <br/> tags?), can't find option to edit, please fix):
Combination of ratings and distribution among developers but per version
This proposed solution is combining solutions #2 and #3 but factoring in versioning.
The aim is for better apps, so if the developers themselves tell end-users to rate their apps as well as provide feedback, ratings and comments becomes then help improve the apps.
When rating apps, it should be by version (major release only). A version 1.0 of an app can get 3 stars but on the next major version release, say 2.0, it can get 5 stars.
As for distribution of karma, it should be by version (major release only) too. Version 1.0 karma can have 3 developers sharing, but for version 2.0, there can be 5 developers sharing.
Last edited by Reggie; 2009-09-10 at 21:41.
Combination of ratings and distribution among developers but per version
This proposed solution is combining solutions #2 and #3 but factoring in versioning.
The aim is for better apps, so if the developers themselves tell end-users to rate their apps as well as provide feedback, ratings and comments becomes then help improve the apps.
When rating apps, it should be by version (major release only). A version 1.0 of an app can get 3 stars but on the next major version release, say 2.0, it can get 5 stars.
As for distribution of karma, it should be by version (major release only) too. Version 1.0 karma can have 3 developers sharing, but for version 2.0, there can be 5 developers sharing.
__________________
Reggie Suplido
Reggie Suplido
Last edited by Reggie; 2009-09-10 at 21:41.
| The Following User Says Thank You to Reggie For This Useful Post: | ||
 |
|
2009-09-10
, 21:39
|
|
Posts: 528 |
Thanked: 895 times |
Joined on Oct 2007
@ Moscow, Russia
|
#14
|
I'm a good example of karma-looser 
I slightly disagree with "version" metrics Reggie proposed above, cause, for example, in our OMWeather project versions are 0.xx all along just because they started like this from the beginning and they are basically for developer and in less part for user (just to check if you have the newest version).
Maybe we can count update rate?
Last edited by wazd; 2009-09-10 at 21:43.
I slightly disagree with "version" metrics Reggie proposed above, cause, for example, in our OMWeather project versions are 0.xx all along just because they started like this from the beginning and they are basically for developer and in less part for user (just to check if you have the newest version).
Maybe we can count update rate?
__________________
Maemo UI improvements blog.
Maemo UI improvements blog.
Last edited by wazd; 2009-09-10 at 21:43.
|
|
2009-09-10
, 21:43
|
|
Posts: 63 |
Thanked: 27 times |
Joined on May 2009
@ NC
|
#15
|
Originally Posted by qgil
What does karma "do" for the developer or application?
A proposal just filed to the Maemo Brainstorm:
Developers should get karma based on the relevance of their software
Currently the developers receive karma basically based on how many Garage projects are maintaining or involved with. This is actually a not very relevant statistic: one developer might have only one project making happy to 100.000 users (see Mplayer) while other might have opened 14 garage projects for 14 command-line direct ports of Debian that actually nobody uses or could care less about.
This is not easy to address as there are many possibilities to be unfair e.g. several developers in a project with different degree of involvement, apps downloaded by thousands that are "easy" ports of projects developed hardly by someone else. I wouldn't make big fuzz of this karma for developers, but it would be good to take it into account somehow.
Currently it's easier to get plenty of karma blogging about apps, talking about apps and commenting bugs in apps... but at the end are the dvelopers who carry with a lot of the hard work. Let's praise them!
Please rate the solutions proposed in the Maemo Brainstorm, add your own solutions and comment (in the Brainstorm if possible).
Does it make Nokia support and maintain the application or will Nokia disregard these applications just like the ones they delivered with the device?
|
|
2009-09-10
, 21:45
|
|
Posts: 1,436 |
Thanked: 3,144 times |
Joined on Jul 2005
|
#16
|
Originally Posted by wazd
I agree -- there should be a tag on the version if it's a major release, minor, bug fix, etc.. That way you can tag v0.0105 and v0.0209 as major releases if you want to.
I'm a good example of karma-looser
I slightly disagree with "version" metrics Reggie proposed above, cause, for example, in our OMWeather project versions are 0.xx all along just because they started like this from the beginning and they are basically for developer and in less part for user (just to check if you have the newest version).
Maybe we can count update rate?
__________________
Reggie Suplido
Reggie Suplido
Last edited by Reggie; 2009-09-10 at 21:48.
|
|
2009-09-10
, 21:45
|
|
Posts: 528 |
Thanked: 895 times |
Joined on Oct 2007
@ Moscow, Russia
|
#17
|
Originally Posted by bummer
Well, basicaly, it's like "speciallist rating". You can ask a person with high karma something and you'll get your answer/help for sure. It's a community thing, not Nokia or IBM
What does karma "do" for the developer or application?
Does it make Nokia support and maintain the application or will Nokia disregard these applications just like the ones they delivered with the device?
__________________
Maemo UI improvements blog.
Maemo UI improvements blog.
| The Following User Says Thank You to wazd For This Useful Post: | ||
|
|
2009-09-10
, 21:46
|
|
Posts: 11,700 |
Thanked: 10,045 times |
Joined on Jun 2006
@ North Texas, USA
|
#18
|
Reggie, that's a great start to providing useful context. Post-beta and mature releases should, IMO, enjoy additional karma... but are we dependent on an honor system here, or is versioning strictly enforced?
__________________
Nokia Developer Champion
Different <> Wrong | Listen - Judgment = Progress | People + Trust = Success
My personal site: http://texrat.net
Nokia Developer Champion
Different <> Wrong | Listen - Judgment = Progress | People + Trust = Success
My personal site: http://texrat.net
|
|
2009-09-10
, 21:47
|
|
Posts: 11,700 |
Thanked: 10,045 times |
Joined on Jun 2006
@ North Texas, USA
|
#19
|
Originally Posted by bummer
It would be nice to avoid provocation... I don't see it as productive.
What does karma "do" for the developer or application?
Does it make Nokia support and maintain the application or will Nokia disregard these applications just like the ones they delivered with the device?
__________________
Nokia Developer Champion
Different <> Wrong | Listen - Judgment = Progress | People + Trust = Success
My personal site: http://texrat.net
Nokia Developer Champion
Different <> Wrong | Listen - Judgment = Progress | People + Trust = Success
My personal site: http://texrat.net
| The Following User Says Thank You to Texrat For This Useful Post: | ||
|
|
2009-09-10
, 21:50
|
|
Posts: 63 |
Thanked: 27 times |
Joined on May 2009
@ NC
|
#20
|
Originally Posted by Texrat
Is that;
It would be nice to avoid provocation... I don't see it as productive.
a) "If you don't have anything nice to say then don't say anything"
or
b) "It's a community as long as you agree and like it - if you don't shut up".
Just curious.
 |
| Tags |
| application karma, brainstorm, developers, downloads, karma, karma from applications, maemo.org |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 06:52.