[spip-dev] Re: Plusieurs versions d'un même article

A mon avis c'est quelque chose de trop lourd pour spip. On a déjà du mal à
maintenir les admins restreints :wink:

@ Abdoulaye BA <aba@clever-age.com> :

Je viens de réaliser une petite fonctionnalité qui consiste à gérer
plusieurs versions d'un même article. Le principe est assez simple :
From antoine@rezo.net Mon Aug 26 23:22:32 2002

Return-Path: <antoine@rezo.net>
Received: from kraid.nerim.net (kraid.nerim.net [62.4.16.95])
  by miel.brainstorm.fr (Postfix) with ESMTP id 0CE1B1C01D
  for <spip-dev@rezo.net>; Mon, 26 Aug 2002 23:22:32 +0200 (CEST)
Received: from rezo.net (telehouse-103-1-202.net1.nerim.net [213.41.186.202])
  by kraid.nerim.net (Postfix) with ESMTP id C059C410F1
  for <spip-dev@rezo.net>; Mon, 26 Aug 2002 23:14:19 +0200 (CEST)
Message-ID: <3D6A9C18.6020200@rezo.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
  rv:1.1b) Gecko/20020823
X-Accept-Language: fr,en
MIME-Version: 1.0
References: <a05100300b99030087646@[192.168.0.2]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-BeenThere: spip-dev@rezo.net
X-Mailman-Version: 2.1b2+
Precedence: list
List-Help: <mailto:spip-dev-request@rezo.net?subject=help>
List-Archive: <Discuter chez rezo.net;
List-Unsubscribe: <http://listes.rezo.net/mailman/listinfo/spip-dev&gt;,
  <mailto:spip-dev-request@rezo.net?subject=unsubscribe>
List-Subscribe: <http://listes.rezo.net/mailman/listinfo/spip-dev&gt;,
  <mailto:spip-dev-request@rezo.net?subject=subscribe>
List-Post: <mailto:spip-dev@rezo.net>
List-Id: SPIP : developpement <spip-dev.rezo.net>
X-List-Received-Date: Mon, 26 Aug 2002 21:22:32 -0000
Status: O
Content-Length: 2077
Lines: 50

Après 10 jours de "statistiques" sur uZine, le calcul de la popularite
s'avère très incohérent:

Par rapport à quoi ?

et ça donne la plupart des articles avec une popularite de zéro

Peut-être parce que la plupart des articles sont impopulaires.

Et, surtout, des articles "pas
importants" totalement surestimés sans que l'on sache trop pourquoi.

Pas "importants" mais peut-être populaires (indice : ils contiennent
peut-être "napster", "sexe" ou "mp3"). S'il s'agit de classer les articles
par importance, tu peux mettre des mots-clés :-))

Sur uZine, où l'on a des entrées et référencements vraiment très divers,
ça donne des résultats qui semblent bien cohérents pour l'instant.

Cohérents avec quoi ?

Du coup, on obtient une popularité qui dépend du nombre de visites et du
nombre d'entrées directes sur l'article. Mais pas de l'âge de l'article.
C'est ce que je prévoyais au départ, car la difficulté est de calculer
une valeur "relative" sur tout le site (sur 100), et non un problème
d'âge de l'article.

Du coup :

- soit on prend la popularité et on peut avoir un article "populaire"
alors qu'il n'est plus visité du tout (mais il a eu beaucoup de visites
au début)
- soit on prend l'activité et on peut avoir un article "inactif" alors
qu'il est actuellement populaire (mais il est très vieux)

Du coup, on n'a plus de variable permettant de savoir ce qui est populaire
_en ce moment_. Avant, c'était simple : "visites" pour l'ensemble de
l'historique, "popularité" pour la popularité actuelle. Maintenant, on a
une "popularité" fortement corrélée avec le nombre de visites total (donc
pas très utile), et une "activité" fortement corrélée avec l'âge de l'article
(donc pas très utile).

Donc, nouveau critère de classement dans les boucles ARTICLES: {par
activite}, l'activité étant la popularité au carré divisé par l'âge de
l'article. Là encore, sur uZine, ça donne des résultats cohérents.

Cohérents avec quoi ?
Pour niveler, on pouvait ajouter un sqrt() sans toucher au reste....

Note, sur le Diplo, ça marchait bien.