From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29091 invoked by alias); 4 Dec 2004 17:08:03 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 28978 invoked from network); 4 Dec 2004 17:07:57 -0000 Received: from unknown (HELO sccrmhc13.comcast.net) (204.127.202.64) by sourceware.org with SMTP; 4 Dec 2004 17:07:57 -0000 Received: from [192.168.181.128] (c-67-176-41-158.client.comcast.net[67.176.41.158]) by comcast.net (sccrmhc13) with ESMTP id <2004120417075601600bdulme>; Sat, 4 Dec 2004 17:07:56 +0000 Message-ID: <41B1EEE5.8020900@phy.cmich.edu> Date: Sat, 04 Dec 2004 22:38:00 -0000 From: Eric McDonald User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) MIME-Version: 1.0 To: Erik CC: xconq7@sources.redhat.com, xconq-general@lists.sourceforge.net Subject: Re: [Xconq-general] Xconq Ranking at Sourceforge References: <20041203173156.24046.qmail@web13125.mail.yahoo.com> <41B1078E.4030508@phy.cmich.edu> <200412041339.02982.freeciv@home.se> In-Reply-To: <200412041339.02982.freeciv@home.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg01461.txt.bz2 Erik wrote: > When I saw that formula it was obvious to me that it does not weight the > data. Since I found that strange I searched for the documentation. And it > says: "We are aware that the current formula does not actually weight the > data aggregated for rankings (the formula was misdesigned and has not yet > been replaced)." > > [http://sourceforge.net/docman/display_doc.php?docid=14040&group_id=1] Well yes, I saw that too; it is the document from which I quoted in my previous message. I wasn't offering a critique on the relative merits or flaws of the existing formula. I was just explaining how it is that we ended up with the ranking we did. I think it would be understandable if another project was a bit annoyed because it had 100 times the downloads but was active in fewer of the areas that logs are taken of. And, as Matthew points out in the next message in this thread, the multiplicative factors inside the logs are the same as adding small constants outside the logs; definitely not a good "weighting" scheme. Eric P.S. The Sourceforge expression is actually a bit simplified, since log(0) must be avoided. Thus it is not a pure formula, but some logical selection must be occurring as well. The other thing to note is that projects that have between 1 and 3, inclusive, new downloads per week would seem to be actually penalized in the scoring, unless there is logic that says to apply the downloads calculation for only those projects with 4 or more downloads per week.