Explicación simple del algoritmo de promoción de noticias (promote)

Septiembre 22, 2008 by gallir

Siempre que una noticia controvertida con varios votos negativos  (y/o que algunos piensen que no “queremos que salga” aunque le hayamos votado positivo o dado publicidad en nuestros blogs) no sale publicada surgen sospechas o conspiranoias de que “hay manipulación”, aunque el algoritmo de promoción es público, como así también los cálculos que realiza.

Suele pasar porque hay parámetros que ajustan el valor del karma de la noticia y hay poca gente capaz o con tiempo para tomarse el trabajo de leer el código y  de seguir la evolución del karma de cada noticia. Para esas personas intentaré explicar el funcionamiento básico del promote, y porqué lo hemos implementado de esa forma.

Los parámetros que más afectan al karma son los siguientes, ordenados más o menos de los que más influyen a los que menos:

  1. Bonus temporal a las nuevas noticias
  2. Coeficiente por metacategorías
  3. Añejamiento de noticias antiguas
  4. Control de diversidad de votos (o de afinidad)
  5. Control de media de votos

(Recalco lo de “más o menos”, ya que depende de varios factores, por ejemplo si la media de votos de una noticia es muy baja, afectará más que los demás, pero está al último porque no se suele llegar a esos extremos, salvo casos de intento de spam con muchos usuarios nuevos o inactivos por mucho tiempo, por ejemplo)

1. Bonus temporal a las nuevas noticias

El objetivo es publicar rápidamente aquellas noticias que reciben muchos votos apenas se envió la noticia. Este algoritmo funciona desde el primer día. Básicamente multiplica el karma de la noticia por un coeficiente decreciente tempral entre 2 y 1. A las dos horas el coeficiente se hace igual a uno por lo que deja de influenciar. Este coeficiente es visible en el promote, la columna COEF. La explicación más completa.

2. Coeficiente por metacategorías

En Menéame hay cuatro metacategorías: ocio, cultura, actualidad y tecnología. El objetivo es intentar tender a un balance entre número de enviadas y publicadas en cada categoría. De esta forma también se evita que el Menéame sea monotemático –o dominado por unas pocas categorías–.

Basado en el número de enviadas / número de publicadas de cada metacategoría se calcula un coeficiente. Los coeficientes de cada una son visibles en el promote. Por ejemplo ahora mismo:

Karma coefficient for tecnología: 1.31632555175
Karma coefficient for cultura: 0.982548801982
Karma coefficient for actualidad: 0.93282154627
Karma coefficient for ocio: 0.872050062752

Los números anteriores significan que a las noticia de tecnología se multiplica por 1.31 mientras que a las de actualidad 0.92. Esos coeficientes son medias entre las enviadas y publicadas de cada una en los últimos 2 días. Están también disponibles justo arriba de los coeficientes anteriores:

2 days stats for tecnología (queued/published/total): 157/13/98 -> 0.0679107630313
2 days stats for cultura (queued/published/total): 175/19/98 -> 0.0905408163265
2 days stats for actualidad (queued/published/total): 455/44/98 -> 0.10136577708
2 days stats for ocio (queued/published/total): 176/22/98 -> 0.104336734694

Los tres números de cada meta significan respectivamente: número de enviadas, número de publicadas y publicadas totales.

3. Añejamiento de noticias antiguas

El objetivo del algoritmo es quitar progresivamente la relevancia de las noticias después de varias horas (nueve). Se hace así para evitar que salgan publicadas siempre noticias de hace varios días, ya que por razones lógicas –el tiempo que están en pendientes– las más antiguas tienen más posibilidades y probabilidad de tener más votos que una noticia reciente.

El coeficiente varía progresivamente desde 1 a 0.4 una vez que han pasado nueve horas desde que se envió la noticia. Este coeficiente es visible también en la columna COEF del promote.

La parte del código que lo calcula es:

// Aged karma
$diff = max(0, $now - ($link->date + 9*3600)); // 9 hours without decreasing
$oldd = 1 - $diff/(3600*60);
$oldd = max(0.4, $oldd);
$oldd = min(1, $oldd);
$link->new_coef = $oldd;

El añejamiento de cada noticia también funciona desde el principio del Menéame.

4. Control de diversidad de votos (o de afinidad)

El objetivo de este control es evitar que grupos de usuarios se voten las noticias entre ellos y logren publicarlas (eso que algunos dicen que existen y llaman “mafias”).

El algoritmo calcula un porcentaje de afinidad entre usuarios y decrementa el karma que “aportan” a la noticia dependiendo de la afinidad con el usuario que le envió: a mayor afinidad menor es su influencia final (aunque el voto siempre suma). Con esto se asegura que para que una noticia salga publicada tiene que haber un mínimo de diversidad de votos.

El algoritmo está explicado en detalle en otro apunte. Está activo desde principios de setiembre de este año (2008).

La parte esencial del código que calcula el coeficiente de afinidad es el siguiente:

foreach ($votes as $vote) {
	if ($vote->id > 0 &&
			$vote->id != $uid &&
			abs($vote->count) > max(1, $nlinks/10) ) {
		$c = $vote->count/$nlinks * 0.75;
		if ($vote->count > 0) {
			$affinity[$vote->id] = round((1 - $c)*100);
		} else {
			$affinity[$vote->id] = round((-1 - $c)*100);
		}
	}
}

5. Control de media de votos

El objetivo de este control es evitar que se creen usuarios nuevos –o se tengan usuarios “inactivos”– con el único objetivo de publicar noticias de un determinado sitio. Por ejemplo que se pongan de acuerdo en un foro, o que haya grupos o empresas con muchos usuarios los intenten “vender” para promocionar sitios.

El promote analiza las medias de votos en los últimos días y usa esa media para controlar que no haya desvíos importantes. La media es visible en el promote:

Karma average for each link: 9.15856554197

Esto significar que la media ponderada de los votos a cada noticia en los últimos días es igual a 9.16.

Para cada noticia se calcula cuál es la media de sus votos. Si la diferencia de la media de un enlace es inferior al 3% de la global –para permitir variaciones hacia abajo–, entonces no toma en cuenta votos inferiores a la media para hacerla como mínimo igual a 9.16 * 0.97 (el -3%) aproximadamente.

Este control funciona desde el primer semestre de 2007.

Tuvimos que hacerlo cuando empezamos a detectar los intentos de spams mediante la creación de decenas de usuarios, especialmente cuando se acercaban fechas electorales o campus parties (ademas incluimos más controles de frecuencia de registros que se pueden hacer por IP y subred).

// Make sure we don't deviate too much from the average
// (it avoids vote spams and abuses)
// Allowed difference up to 3%
$karma_pos_user = (int) $karma_pos_user_high +
                  (int) min($karma_pos_user_high * 1.07, $karma_pos_user_low);

El karma es fundamental

Espero que esta breve explicación elimine algunas dudas sobre el funcionamiento del algoritmo de promoción y que de más tranquilidad, ya que está claro que se intenta asegurar que no haya abusos y grupos que tengan más influencia –llámese mafias o fanboys– capaces de publicar noticias sólo con sus votos.

En toda la explicación de las diferentes técnicas, el parámetro fundamental que evoluciona con el tiempo es el karma –en este caso el de las noticias, pero también el de cada usuario–. Ojalá que aclare mejor lo que comentábamos hace tiempo sobre la potencia y utilidad de ese numerito que llamamos “karma” [*]:

Lo anterior creo que explica más o menos los fundamentos de tener un karma: es un sistema básico de protección “anti abusos” que evita tener que tomar medidas más “drásticas”, además hace posible el voto anónimo.

[...]

Sí, admitimos que no es perfecto, ni de lejos, pero el karma ha sido fundamental para controlar y evitar abusos sin tener que recurrir a medidas extremas y un coste de administración que hubiese sido prohibitivo para nosotros.

(y permite publicar todo, el algoritmo y sus cálculos)

[*] Es decir, la potencia de las matemáticas de nivel de ESO para hacer cálculos y controles complejos y a la vez resumirlos en un número que todos podemos entender para darnos una idea de la “situación” :-)

Penalización de “endogamia de votos”

Septiembre 8, 2008 by gallir

Desde hace unas horas está funcionando el nuevo “promote” (código fuente) que calcula y penaliza las “altas endogamias” (o afinidades) de votos entre usuarios. Así se evitarán que un grupo de usuarios se voten siempre entre ellos y puedan publicar las noticias más fácilmente.

La técnica es algo similar a la “diversidad” que usan en Digg –al menos así lo cuentan– pero en nuestro caso se usa directamente el karma que aporta cada usuario a una noticia y se aplicará a aquellos usuarios que votan a [casi] todos los envíos de otros usuarios.

La penalización consiste de un coeficiente entre 0 y <1  que se calcula al karma aportado por cada usuario. El coeficiente de afinidad representa el porcentaje de votos a los envíos de un usuario. Así en el último mes A votó un 30% de los envíos de B que obtuvieron muchos votos (aunque no haya salido publicada), los siguientes votos de A a B valdrán 0.7. Si en cambio votó al 90%, el voto valdrá 0.1 de su valor original –con un mínimo de 5–. Si en cambió no llegó a votar al 10% (por ahora, mientras está de pruebas) el voto no sufrirá penalización alguna.

Además de la ventaja fundamental de evitar “endogamias”, también penaliza a aquellos usuarios que votan “a lo loco” basado sólo en el título o autor del envío.

Pueden surgir problemas, como que requiera varias horas hasta que los coeficientes de cálculo se estabilicen, o que haya que hacer ajustes al promote por penalizaciones injustas. Estaremos muy pendientes de esto en los días siguientes.

Actualización (9/10 21 hs): Después de probar en parelelo durante casi 24 horas –casi no hay casos para comprobar–, lo mismo funciona para los votos negativos. El cálculo es similar pero negativos, es decir que el mínimo valor negativo que puede dar es -5.

Aclaración: No afecta al karma de los usuarios, sólo afecta al cálculo del karma total de las noticias. Aunque haya “afinidad” del 100% el voto siempre cuenta como positivo y suma karma según lo explicado arriba.

Nota: Para los que vayan a mirar el código fuente, la función que calcula la afinidad está al final, se llama check_affinity(). Puede verse como se aplica en el coeficiente un par de líneas más abajo desde donde es llamada la función (que devuelve un diccionario con los coeficientes para cada usuario).

[*] Sí, los hay, especialmente esos que usan foros –y mésenyers– para avisar que han subido noticias de sus sitios/foros/temáticas. Últimamente hemos detectado varios, es la motivación, para evitar estos “abusos” sin que nos obliguen a banear sitios o cuentas de usuarios.

Chrome, la noticia cansina, pero…

Septiembre 5, 2008 by gallir
Los usuarios del Menéame consideraron agobiante la cantidad de noticias relacionadas con el Chrome. Pero hay algo interesante. En las estadísticas de visitantes del día 1 de setiembre ni siquiera aparece el Chrome, sin embargo cambia radicalmente durante los dos días siguientes.
Día 2: 2.25%
porcentaje de navegadores 2 de setiembre

Porcentaje de navegadores 2 de setiembre

Día 3: 3.55%

Porcentaje de navegadores 3 de setiembre

Porcentaje de navegadores 3 de setiembre

Finalmente esto es parcial del día 4 de setiembre: 7.35%

Porcentaje de navegadores 4 de setiembre

Porcentaje de navegadores 4 de setiembre

Nunca había visto semejante crecimiento, en unos días superó a sus antecesores: el Safari y su original de KHTML (Konqueror, que los “medios” sólo citan al Webkit pero el padre de la criatura –del renderer– fueron los chicos de KDE).

Un usuario molesto, con razón

Agosto 18, 2008 by gallir

Recibimos bastantes quejas en el Menéame por envíos de sitios que han plagiado y/o copiado al sitio original y no lo citan ni cumplen con las habituales CC con exigencia de citar al original. En estos casos solemos cambiar el enlace si no hay dudas sobre el plagio, incluso tuvimos que penalizar o prohibir el envío de sitios donde se detectaron plagios. Nos suele ocasionar bastantes discusiones, pero al menos podemos remediar aunque sea parcialmente el malestar ocasionado al blogger o autor original.

Hoy nos ha tocado un caso bastante extraño y que no podíamos hacer nada por remediarlo. Un usuario del menéame hace un comentario y otro “medio digital” lo copia textualmente sin citar al autor original. Por supuesto no  cumple con la licencia para el contenido que usamos en el Menéame.

Amigos ‘admin’ de Menéame

[...] la web de www.periodistadigital.com, se han montado una noticia a base de copiar textualmente el comentario íntegro de una traducción del danés que puse, junto con el enlace al diario danés «Ekstra Bladet» (www.eb.dk), en Menéame.net ( http://meneame.net/story/polemica-entre-espana-dinamarca-calienta-titular-periodico-danes-espan/1#comment-1 )

Periodista Digital, [...] escriben (pegan) en http://blogs.periodistadigital.com/deportes.php/2008/08/18/honor-regata-nacion-dinamarca-4747?blog=120&c=1&page=1&more=1&title=honor-regata-nacion-dinamarca-4747&tb=1&pb=1&disp=single todo lo que yo he traducido del diario danés sin dar el más mínimo crédito a la fuente de la información en castellano que es mi comentario en Menéame.net.

No contentos con copiar este comentario, confunden la sección «Nationen» (La Nación) del diario danés Ekstra Bladet con el nombre del periódico en sí y, ponen en boca de «Un alto delegado del comité danés» inexistente, lo que en realidad es un comentario de un lector del diario danés.

[...]

Os adjunto los ’screendump’ de la página de Periodista Digital, por si deciden cambiarla para evitar las pruebas del plagio.

Y aquí debajo también os adjunto el texto de ambos enlaces.

Un saludo

Malahostia
Usuario de Menéame.

Hemos verificado la queja del usuario y tiene razón, el artículo referido era en gran parte un copy&paste de la traducción de su comentario, es entendible su enfado. Lo único que podemos hacer al usuario “malahostia” es disculparnos, y hacer público su caso.

Pues eso, disculpas. De paso nuestro más firme desacuerdo con el autor de la “noticia”: estamos a favor, queremos potenciar el reuso de contenido –de hecho nos enorgullece–, pero así también hay que respetar  la licencia libre de los contenidos del Menéame, es fácil y está enlazada en el pie de cada página.

Beta del Menéame v3

Julio 11, 2008 by gallir

Finalmente después de semanas de estrés. agobios, discusiones pruebas y correcciones ya podemos hacer pública para pruebas la tercera iteración del Menéame: beta.meneame.net.

El diseño lo hicieron y maquetaron Damián Vila y Benjamí, este pringao se ocupó de código y dar el coñazo a los dos. Pusimos tambień mucho esfuerzo en mantener la velocidad de carga y visualización de las páginas.

Pasamos los últimos días corrigiendo errores graves de visualización y usabilidad para IE, especialmente IE6 (incluso tuvimos que poner un fichero especial de hacks para el IE6) que representa más o menos un 16% de la audiencia del Menéame.

Aunque podríamos estar semanas perfeccionándolo, es hora de parar y que nos aviséis en los comentarios si veis problemas graves de usabilidad o visualización.

Si todo va razonablemente bien, lo pasaremos a “producción” a principios de la semana qe viene.

Qué hay de nuevo

En principio no queríamos cambiar la estructura básica. Pero con el tiempo nos dimos cuenta que la barra de la izquierda, con sus casi infinitas opciones, era prácticamente invisible a pesar que ocupaba la mejor parte de la pantalla. El objetivo era poner las noticias a la izquierda así darles más notoriedad y que sean más fáciles de leer en monitores pequeños o dispositivos móviles.

En la barra de la izquierda sí había unos enlaces importantes (enviar noticias, fisgona…) que debían seguir siendo relevantes, así que tomamos la decisión de ponerlas al lado del logo pero el mismo tiempo dar una imagen no tan tradicional y que al mismo tiempo “envolviese” mejor al megabanner superior. De allí la posición actual en diagonal. Además trabajamos en la cabecera para reducir al mínimo el espacio ocupado y que además diese más funcionalidad.

Las demás opciones de la barra de la izquierda las pusimos en el pié de página de las “página largas”, fundamentalmente los índices.

El otro objetivo importante era mostrar con más relevancia los comentarios más votados  y además mostrar en la misma portada las noticias más “populares” de las últimas horas. Así es que se hizo la barra lateral más ancha que además sirve para colocar el “robapáginas” de publicidad, que es lo más solicitado por los publicistas.

Aunque desde hace tiempo existe la pestaña de populares, esta no era muy visitada, y de hecho nos preguntaban muchas veces cómo hacer para ver esas noticias. Otros nos criticaban de que no lo hayamos hecho antes cuando es obvio. Había que darles más visibilidad, pero eso exigía una restructuración importante como la de ahora. Así, ahora  se muestran las más votadas en las últimas 24 horas pero ordenadas con una función que da prioridad a las más nuevas (un decay temporal). Usamos la misma técnica para ordenar los mejores comentarios, aunque en ese caso sólo se consideran los de las últimas 6 horas.

Siguiendo con la idea de ahorrar espacio vertical entre la cabecera y las noticias hemos reducido el espacio necesario para mostrar las meta y categorías que se están visualizando.

Aprovechando el espacio de la barra lateral también agregamos:

  • Las candidatas a ser publicadas –pero para votar con responsabilidad, recordad que el voto karmawhore o becerro está fuertemente penalizado :-)– en la página de pendientes. Esta información era accesible desde la pestaña “popular” en pendientes y también en el promote, pero poniéndolas allí damos una visión rápida.
  • Mapa de geolocalización de la noticia. Antes estaba incrustada en el texto, era muy pequeña y “molestaba” a la lectura. Ahora es más grande y a la derecha.
  • Comentarios más populares de la noticia. Cuando una noticia supera los 20 comentarios se le agrega una caja lateral que muestra ordenado los comentarios más valorados. El número de comentarios que aparecen en la caja depende del número de comentarios de la noticia (total/4 con un máximo de 25).
  • También agregamos la misma barra al nótame, allí también hay una caja con las notas más votadas (y más abajo la de comentarios).
  • La nube de etiquetas. Ya estaba en la versión anterior, pero ahora es más legible. Cuando se está en portada muestra las etiquetas más usadas –48 horas– en las publicadas, la nube de pendientes las etiquetas de pendientes.

Luego mejoramos o arreglamos varios detalles, entre ellos (me olvido de unos cuantos):

  • La referencia #0 –bastante usada en los comentarios para señalar al texto del envío– ahora se comporta igual que para las referencias cruzadas a otros comentarios. Es decir, mostrará un tooltip con el contenido.
  • El promote ya obtiene los datos de la base de datos (y valida correctamente).
  • Se agregó un ranking a cada usuario. Eso da una idea de cuántas personas tiene un karma superior. Así todos los que tengan 20 serán el #1, y los que tengan 6 –por ejemplo– también tendran el mismo ranking que todos los demás con el mismo karma. El ranking es visible en el perfil del usuario y también en los tooltips. Se actualiza al instante, es decir que si a alguien se le modifica el karma durante el día el cambio se refleja inmediatamente.

Sabemos que hay muchos otros detalles que mejorar y optimizar (o espacios que rellenar). Pero eso es parte de la evolución de esta versión –como las dos anteriores–, que esperemos tarde mucho en hacerse obsoleta, es como un parto y este ya es el tercero :-)

PS: Ojalá que para la siguiente iteración el IE6 ya no exista, en serio.

Organización, organización…

Junio 27, 2008 by gallir

Después del follón que se montó después del partido contra Italia (y antes con otros partidos) hubo que definir criterios claros que fueron decisivos para que ayer no hubiese ningún problema. La noticia salió publicada en cuatro minutos, todo un record, sin ninguna discusión (aunque hay algunos muy despistados).

También ayudó mucho el tercer servidor que pusimos en marcha en Amazon EC2 (que se puso al 100% de CPU todo el tiempo que estuvo sirviendo páginas para meneame.net, mientas que los dos habituales no llegaban ni al 30%).

Muchas gracias a los admins que estuvieron muy alertas, han colaborado y tomaron las decisiones correctas muy rápidamente.

Al final es todo cuestión de organización y fijar criterios, vamos aprendiendo. Como el cuento aquél del tío chillando:

¡Organización! ¡organización! que no todavía no hice nada y ya me han dado varias veces por… :-)

Novedades: votos a comentarios, anotaciones, cálculo del karma, promote, Amazon EC2 y fútbol

Junio 26, 2008 by gallir

Estos últimos días hemos hecho varias mejoras importantes (si fuésemos anglosajones diríamos algo como estamos realmente excitados). La principal es que los votos a comentarios son públicos desde hace unos días, se muestran en una ventana modal.

Votos de comentarios públicos

La idea de los votos a comentarios es para resaltar a los buenos comentarios y penalizar a aquellos que insultan o provocan gratuitamente. Al principio no pensábamos que hiciese falta hacer público los datos de estos votos, ya que hay suficientes controles para evitar los abusos de negativos y en general funcionan bastante bien.

Pero hay usuarios que abusan y votan negativo sólo para expresar su desconformidad con los argumentos expuestos, otros como “venganza”, esto generaba bastantes cabreos y consultas a los admins.

Así que habíamos decidido hace tiempo hacerlos públicos, sólo nos demoramos porque estábamos buscando la forma de hacerlo usable, simple y que no afecte la velocidad de todo el sitio. Creo que lo hemos logrado, so we are excited:-)

Servidor adicional en Amazon EC2

El otro cambio importante es más técnico y de las tripas del Menéame, pero casi obligaron a acelerar la implementación de las otras  características, tiene que ver con la avalancha de visitas que recibimos durantes las hora siguientes al partido contra Italia, tanto que la primera hora el sitio iba muy lento por llegar al límite de las 800 conexiones simultáneas.

Para prepararnos para el partido contra Rusia tuvimos que hacer modificaciones importantes al código del Menéame –pre-diseñada, pero pendientes de implementar– para permitir agregar servidores y réplicas remotas temporales de la base de datos.

Así fue que implementamos esta característica y ya está funcionan en un servidor alquilado en Amazon EC2 (amazon1.meneame.net). Si esta noche se produce otra vez la saturación lo habilitaremos para que también sirva al dominio meneame.net.

Sólo tiene un problema importante.

Los tiempos de latencias entre los centros de datos de Amazon en EEUU y nuestros servidores de Ferca en Madrid son muy elevados. Cuando un usuario modifica algo –comentario, voto, chat en la fisgona–, el servidor de Amazon tiene que enviar sincrónicamente los datos al de Madrid para que la visualización sea consistente. Así que en estos casos mencionados veréis –si lo habilitamos para después del partido– que la respuesta es lenta [*]. Pero compensa con la velocidad de navegación que aportará.

[*] No habría este problema si tuviésemos todos los servidores en Amazon EC2, pero los tiempos de ping de estos con Europa son muy malos.

Anotaciones

Al permitir tener varios servidores distribuidos y con altas latencias  ya no podíamos usar ficheros estáticos (compartidos vía NFS). Eso nos generó problemas con los logs públicos del promote y del karma que son visibles en el perfil de usuarios. Para solucionarlo hemos implementado un sistema de “anotaciones” de texto que permiten guardar los logs en la base de datos y así ser accesibles desde cualquier servidor.

Está diseñado para ser muy rápida y de uso genérico. En el futuro seguramente usaremos esta característica para otros tipos de avisos.

Cálculo del karma

En el perfil de cada usuario se puede consultar los resultados del karma. Al mismo tiempo que implementamos la visualización de votos comentarios hicimos algo similar para visualizar el log del cálculo.

Al tener las anotaciones hicimos los cambios para adaptarla y además tradujimos todo el texto al castellano, con mensajes más comprensibles.

Además aprovechando las características de las anotaciones, también se añaden en “tiempo real” los registros de cambios en el karma, por ejemplo con registros de incremento de karma por publicación de una noticia, las penalizaciones por votos cowboys, el descarte de noticias, comentarios con spam, etc. Esta información adicional al usuario ayudará a mejorar todavía más la “transparencia” del Menéame.

Promote

Al igual que tuvimos que adaptar el karma, también el log del promote donde se muestra el ajuste de karma que se hace a cada noticia (cada cinco minutos), o cuándo son seleccionadas para publicarse. Ahora tiene una nueva dirección meneame.net/promote.php.

Fútbol

Algunos dicen que el fútbol es pan y circo. Otros lo defienden. A otros les es indiferente (¿recordáis que podéis seleccionar o “anular” categorías en vuestro perfil?).

En cambio a nosotros nos da no sólo problemas y flames, también mucho trabajo de programación… y algo de gastos adicionales. But, it was quite exciting. ;-)

El problema al final de los partidos: disculpas y criterio que seguiremos desde ahora

Junio 23, 2008 by gallir

Cada vez que hay algún partido de fútbol importante se repite el siguiente problema:

  • Antes que acabe el partido ya hay varios usuarios con el borrador preparado para enviar.
  • Al no poder enlazar a noticias ya redactadas enlazan habitualmente a páginas webs que transmiten o actualizan en tiempo real (”marcadores”).
  • Pocos segundos antes o después del pitido final envían la noticia, casi todos simultáneamente.
  • Se produce una saturación de noticias sobre lo mismo en la cola de pendientes, con votos por erróneas, duplicadas más los ya infaltables irrelevantes.
  • Durante varios minutos se siguen enviando noticias de lo mismo, a veces por no darse cuenta, otras por simple cachondeo o para molestar.
  • Con todo ese cruce de votos negativos al final terminan tardando mucho tiempo en salir o en casos extremos –como la del Madrid cuando ganó la liga– acaba no saliendo la noticia publicada.

Resultado: Acusaciones de mafia o que desde el Menéame censuramos esas noticias. No sé que sentido tendría censurar algo que es harto conocido y que al fin y al cabo es una tontería. Pero desde lo del Madrid, ese tema ha sido el centro de muchos flames e incluso de preguntas en alguna conferencia.

Con la Eurocopa el problema se agravó aún más y entre los admins estábamos discutiendo cómo solucionar el problema. Habíamos visto que el mayor problema eran los envíos precipitados de esos sitios de “marcadores” que muchas veces no están actualizados al momento del envío a la cola, y otras –como me pasó a mí– muestran información desactualizada.

La opción que discutimos es la de no permitir el envío de esos “marcadores” para así premiar al que envíe ya un artículo redactado –los periódicos deportivos los suelen publicar muy rápido–. Fue una opción discutida pero no decidida… y de aquí vino el error que cometimos. Con toda la buena voluntad pero fue un error.

Al momento que terminó el partido de España contra Italia se envió esta noticia de un “marcador”. Varios admins que estaban presentes recordaron la discusión anterior y además vieron que el marcador no estaba actualizado con el resultado final de los penaltis. Eso, junto con el nerviosismo porque el servidor estaba saturado –teníamos el límite de conexiones simultáneas, 800, un record nunca alcanzado– llevó a cometer el error de descartarla cuando no habíamos avisado claramente que seguiríamos esa política ni tan siquiera la habíamos aplicado en casos anteriores.

Aunque le decisión al final tuvo tuvo un buen resultado –se publicó una que sí era completa–, fue un claro error. Así que disculpas nuevamente, la intención era buena pero cometimos tres errores: exceso de celo, no avisar antes, falta de “mano izquierda” al tomar una decisión en principio sin demasiada importancia pero que generó malentendidos y discusiones.

Desde anoche que estamos discutiendo cómo mejorar y evitar estos problemas y flames. Había varias opciones que se discutieron (copia literal):

1) dejar hacer y listo

2) lo de hoy (pero previo aviso en el blog oficial)

3.a) avisar en el blog de los marcadores no darán karma y aplicar un
SDK al día siguiente al afortunado que consiga portada
3.b) lo mismo que 3) pero editando el meneo en portada para poner una
URL decente.

Después de decenas de intercambio de correos y ante la difícil de rebatir las siguientes dos opiniones de dos admins diferentes (copia literal):

Al fin y al cabo, no vamos a conseguir evitar que la gente mande los resultados en seguida. Ni aunque mandar noticias deportivas reste karma [...] Creo que debemos tener presente, en la medida de lo posible, la opinión de los usuarios. Y en este caso, claramente se prefiere inmediatez sobre calidad del artículo.

En principio las normas “de calidad” son para que el usuario esté contento… y aquí el usuario objetivo de esas noticias se contenta con un marcador o cualquier cosa, ¿así que por qué preocuparnos? No es contenido chungo, porno ni similar [...] Si están contentos con un marcador, pues ya está, que ellos lo disfruten.

Después de escuchar las opiniones y alternativas hemos decidido con Benjamí que la criterio para estos casos será la siguiente.

Reglas y recomendaciones para el envío de noticias de “eventos singulares”

  1. Se permitirá el envío de “marcadores” siempre y cuando se haga al final del evento y el enlace sea correcto y con datos actualizados. No se considerarán “marcadores” válidos artículos sin casi texto ni explicaciones  y envíados con el único objetivo de autobombo o spam comercial.
  2. El envío de noticias similares, ya sea en forma masiva o para entorpecer el voto a las anteriores será considerado un abuso (por lo que se descartaría la noticia y quizás anulación de la cuenta del que la envía).
  3. Si vemos que hay muchas noticias sobre lo mismo que entorpece la votación de la/s primera/s las descartaremos.
  4. Nos reservamos el derecho a descartar todas las otras duplicadas una vez que haya salido publicada una de ellas, o que esté a punto de salir publicada (se puede controlar en el promote –atención que es una direción nueva–).
  5. Antes de enviar una noticia sobre el evento mira que no haya sido enviada, seguramente ya está en la cola.
  6. Si envías una noticia y te das cuenta que está duplicada, edítala y ponla en autodescartada. Así no afecta el karma de nadie y permite que la primera enviada tenga más votos de los interesados.
  7. Antes de votar a una noticia sobre el evento, busca cuál es la primera y vota a ella. Así ayudarás a que sea publicada más rápidamente.

Inmediatamente después que publique este apunte lo enviaré al Menéame, para informar a sus usuarios y sobre todo para que den sus sugerencias en los comentarios, por lo que cerraré los comentarios aquí y así centralizar la discusión en el sitio donde más interesa.

De nuevo, disculpas por los malentendidos, sobre todo al usuario new y a los que votaron ese primer envío.

Discusión en Menéame.

Bonus temporal de las noticias

Junio 15, 2008 by gallir

Casi desde el primer día del menéame, el programa que selecciona la noticia a publicar aplica un bonus a las noticias más recientes. El único objetivo de dichos bonus es publicar rápidamente las noticias que captan el interés de los que votan, en son aquellas que impactan más o que se refieren a un suceso importante.

Obviamente, una noticia que sale publicada en poco tiempo gracias a ese bonus tiene menos votos que las “normales”. Así, cada vez que se publica una noticia gracias a su bonus surgen comentarios conspiranoicos de que hay manipulación o que existe una “mafia” que hace que ocurra esto. Nada más lejos de la realidad, es así como funciona el algoritmo y se puede verificar en los resultados del cálculo: la columna BONUS indica el coeficiente que se le aplica, normalmente vale uno, pero en caso de noticias recientes se observará que el coeficiente es mayor que uno.

Cómo funciona

La parte fundamental del código es el siguiente

// BONUS
// Give more karma to news voted very fast during the first two hours (ish)
if ($link->content_type != 'image'
		&& $link->negatives < ($link->votes/10)
		&& $now - $link->date < 7200
		&& $now - $link->date > 600) {
	$link->new_coef = 2 - ($now-$link->date)/7200;
	// if it's has bonus and therefore time-related, use the base min_karma
	if ($decay > 1)
		$karma_threshold = $past_karma;
	else
		$karma_threshold = $min_karma;
} else {
	// Otherwise use normal decayed min_karma
	$karma_threshold = $min_karma;
	$link->new_coef = 1;
}

Lo que hace es muy sencillo. Si una noticia fue enviada hace menos de 2 horas y más de 10 minutos –para evitar que salga demasiado rápido sin que otros tengan oportunidad de votar– su karma se verá multiplicado por un coeficente mayor que  1 y menor 2. Este es el valor que se puede ver en la columna BONUS explicada anteriormente.

El valor del coeficiente depende del tiempo que ha pasado –decae proporcionalmente–, es lo que se hace la primera línea resaltada.  Valdrá casi 2 a los pocos minutos de haber sido enviada y decaerá proporcionalmente a 1 al llegar a las 2 horas

Además hay otra restricción. El bonus no se aplica si la noticia tiene más de un 10% de votos negativos.

No hay magia, no hay manipulación. Es un algoritmo que está implementado desde el principio y que funcionó en general muy bien para publicar rápidamente aquellas noticias que los votantes consideran muy relevantes.

Voto negativos a publicadas (II), ahora con efecto

Junio 8, 2008 by gallir

En setiembre del año pasado pusimos en marcha los votos negativos a publicadas.   Ahora estamos a punto de introducir una modificación que hará que los votos negativos sí tengan efecto: enviar de nuevo a cola de pendientes a las noticias con más votos negativos que positivos durante la primer hora de publicación.

Es una prueba atendiendo a la sugerencia de muchas personas –Digg lo hace así desde que puso el voto negativo –o bury–. Si no funciona o no cumple los objetivos, lo cambiaremos, mejoraremos o quitaremos. Las reglas son muy restrictivas y se aplica sólo a los votos errónea y copia/plagio:

  1. La noticia tiene que haber sido publicada en las últimas tres horas.
  2. El total de votos negativos debe ser al menos un 25% del número de votos positivos.
  3. Para las siguientes reglas sólo se cuentan los votos de usuarios autentificados y emitidos después que la noticia haya sido publicada.
  4. La suma del karma negativo de los votos debe ser superior al karma de los votos negativos en el mismo período.
  5. La suma del karma negativo debe ser como mínimo el 25% del karma con que ha salido publicada una noticia (para asegurar que haya los votos suficientes y evitar efectos ping-pong).
  6. En los logs de la noticia se verá un evento nuevo para este caso: link_depublished.

¿Qué quiere decir esto? Que si te das cuenta sólo al momento que sale publicada –como pasa algunas veces–  que una noticia es un magufo, un engaño claro, o es plagio evidente [*] puedes votarla negativo y ese voto tendrá efecto, no será inútil como hasta ahora.

Esperemos que mejore y que no haya abusos (aunque con las reglas tan restrictivas es bastante difícil).

Muchos no estarán de acuerdo o les parecerá mal. Esperad un tiempo por favor, veremos como funciona, estará todo visible y siempre podemos deshacerlo si es un error.  Otorgadnos la duda razonable que quizás sea una buena idea –además sugerida por muchas personas–.

[*] Tuvimos muchas quejas de autores que se quejaban por apuntes plagiados de ellos subieran a portada y no el original. Por eso hace tiempo agregamos el voto negativo copia/plagio y estamos sensibles con el tema.