Saltar al contenido

Comunidad

Política de Moderación de Feedback

Última actualización: 5 de junio de 2026

El sistema de feedback estructurado es el corazón de Momus. Para que funcione bien, necesitamos un proceso claro y justo para identificar feedback de mala fe y proteger tanto a Builders como a Testers.

Tipos de feedback que moderamos

1. Feedback spam

Es feedback que no aporta valor real al Builder. Incluye:

  • Contenido genérico: respuestas tipo "buen producto, sigue así" sin mencionar nada específico del proyecto.
  • Contenido copiado entre múltiples proyectos del mismo tester (detectable con similarity matching).
  • Contenido off-topic: hablar de cualquier cosa excepto el producto que se probó.
  • Auto-promoción: incluir links a tu propio producto/servicio sin relación con el feedback.
  • Texto generado por IA sin revisión humana: el feedback debe reflejar tu prueba real. Usar IA para escribir es bienvenido, pero si pegas un texto IA sin verificar y se nota que no probaste el producto, es spam.

2. Feedback abusivo

  • Insultos personales al Builder.
  • Lenguaje discriminatorio (género, raza, orientación, etc.).
  • Amenazas o intentos de extorsión ("sube mi rating o publico algo malo").

3. Feedback fraudulento

  • Rating alto que tú declaraste haber recibido como pago del Builder a cambio (soborno).
  • Rating bajo malicioso por competidores o stakeholders interesados, sin haber probado de buena fe.
  • Feedback en proyectos a los que no se aplicó legítimamente (uso de cuentas múltiples).

Cómo se marca como spam

Por el Builder

El Builder que recibe feedback tiene un botón "Reportar spam" visible junto a cada feedback. Al usarlo:

  • El feedback queda oculto de la vista pública del proyecto inmediatamente.
  • El feedback entra a la cola de moderación con el motivo declarado por el Builder.
  • Un moderador humano revisa en plazo máximo de 48 horas hábiles.
  • Si confirma spam: el TesterScore del Tester se penaliza con −50 puntos y queda registrado.
  • Si NO confirma spam (era feedback legítimo aunque negativo): el feedback se restaura, el Builder queda registrado por un reporte improcedente (3+ reportes improcedentes resultan en advertencia al Builder).

Por la Plataforma (automatizado)

Marcamos para revisión automáticamente si detectamos:

  • Similarity score > 90% con otro feedback del mismo tester en proyecto distinto en los últimos 30 días.
  • Lenguaje ofensivo según diccionarios automatizados (sólo marcación, no acción automática — humano decide).
  • Patrón sospechoso de cuentas múltiples (mismo IP, mismo device fingerprint, mismo método de pago).

Proceso de moderación

  1. Recepción: el feedback entra a la cola con el motivo (auto-detección o reporte humano).
  2. Revisión humana: un moderador del equipo de Momus (no hay decisiones únicamente automatizadas) revisa el feedback en contexto: historial del tester, historial del builder, contenido específico, evidencia adjunta.
  3. Decisión: una de tres:
    • No spam: feedback se restaura.
    • Spam confirmado: feedback queda eliminado de la vista pública. TesterScore del tester se penaliza −50 pts.
    • Caso grave (acoso, fraude, threats): suspensión inmediata de la cuenta del tester.
  4. Notificación: ambas partes (tester y builder) reciben la decisión por email + in-app.
  5. Apelación: el afectado tiene 30 días para apelar escribiendo a [email protected] con argumentos adicionales. Un segundo moderador revisa la apelación.

Reincidencia

Testers

  • 3 feedbacks marcados como spam confirmado: 30 días de suspensión de aplicaciones nuevas. El TesterScore se reduce a 0.
  • 5+ feedbacks como spam: ban permanente de la cuenta.

Builders

  • 3 reportes de spam improcedentes en 90 días: advertencia formal.
  • 5+ improcedentes: revocación del derecho a marcar spam unilateralmente por 90 días — todos los reportes pasan por moderación obligatoria.
  • Patrón claro de retaliación (reportar siempre feedback negativo, nunca positivo): suspensión del Builder.

Datos que considera el moderador

Para decisiones justas, los moderadores ven:

  • El contenido completo del feedback en disputa.
  • El historial del tester: feedbacks anteriores, TesterScore, status de verificaciones.
  • El historial del builder: reportes hechos previamente, response rate, status de su proyecto.
  • Logs técnicos relevantes (mismo IP, device, patrones de timing).

NO tienen acceso a:

  • Datos de pago.
  • Contraseñas.
  • Comunicaciones privadas no relacionadas con el feedback en disputa.

Compromiso de transparencia

Una vez al trimestre publicamos estadísticas agregadas y anónimas de moderación: número de reportes recibidos, % confirmados, % apelados, % apelaciones aceptadas. Estará en /transparencia (a publicarse cuando tengamos volumen suficiente).

Contacto