Un buen algorithm para dividir pagos entre TODOS los desarrolladores de un repository Github basado en statistics

Recientemente, alguien en r / bitcoin comenzó a usar nuestro sistema de pago colectivo para recompensar directamente a los desarrolladores principales de Bitcoin. Nuestro sistema divide los pagos según los niveles de participación. Una especie de pago de uno a muchos.

Esto resultó en una gran discusión (pero también en $ 600 de donaciones y 20-25 de los desarrolladores principales que se registraron rápidamente para recoger sus recompensas ). Uno de los principales arguments es que es imposible recompensar a los desarrolladores en base a statistics simples como LOC.

Solo estamos parcialmente de acuerdo, y uno de sus desarrolladores principales, Gavin Andreesen, dijo que nuestro algorithm lo hizo bastante bien .

Mi pregunta es, si tuvieras que dividir las recompensas entre todos los contribuyentes a un repository de Github, basado en las statistics de Github del repo, ¿qué algorithm / cálculo TÚ sugerirías?

En Github solo se miden / clasifican algunos types de participación. En ese sentido, no es una plataforma muy social (todavía). En lugar de simplemente usar LOC, nuestro algorithm pesa:

  • el número de confirmaciones aceptadas en la twig principal
  • número de líneas agregadas
  • número de líneas eliminadas
  • reciente de una contribución
  • Hace un poco de normalización para networkingucir los extremos

También recuerde que los repos se moderan mediante pull-request. Entonces hay un control de calidad antes de que el algorithm haga su trabajo.

Para demostrar el concepto, comprometimos EUR100 a esta pregunta . Cuando se acepta una respuesta, se dividirá entre TODAS las respuestas basadas en las votaciones. Las recompensas pueden ser recolectadas por OAUTH-ing su count stackoverflow.

https://mobbr.com/#/task/aHR0cHM6Ly9zdGFja292ZXJmbG93LmNvbS9xdWVzdGlvbnMvMjk2MDY3NTgvYS1nb29kLWFsZ29yaXRobS10by1kaXZpZGUtcGF5bWVudHMtYW1vbmctYWxsLWRldmVsb3BlcnMtb2YtYS1naXRodWItcmVwby1iYXNlZA==

Mi teoría: cada medida que puede ser determinada únicamente por un progtwig (por ejemplo, # de líneas de código agregadas o eliminadas) es vulnerable a juegos triviales . Por definición, cualquier otra medida depende en parte del aporte humano (por ejemplo, # confirmaciones aceptadas en la twig principal) y es vulnerable a los problemas "sociales" usuales como la corrupción y el favoritismo, pero estos son infinitamente mejores que el primer tipo. Las mediciones automáticas solo deben usarse como "reglas de límite inferior", como "Ni siquiera ha visitado el sitio en el último año ==> No es elegible para nada".

No envía código, envía características. (Bueno, en realidad, tal vez no envíes nada, pero aún así, te importa que tu código haga cosas, no solo estar sentado allí)

OMI, la única forma razonable de gastar subvenciones para proyectos de código abierto es un sistema basado en recompensas.

Por un lado, puedes gastar el dinero que tienes ahora para futuros desarrolladores.

En segundo lugar, puede involucrar a la comunidad mucho más directamente, al permitirles prometer una recompensa específica (por una característica o error) O NO.

Finalmente, alguna entidad impulsora prioriza el trabajo al otorgar recompensas más altas o tareas de mayor prioridad o más difíciles.

PD: "Pero no tenemos tal entidad". Entonces eres pirata. Toma el dinero y corre.

EDITAR:

Entiendo que le gustaría recompensar a las personas por el trabajo que ya han hecho. Puede ser que esto se sienta como lo necesite su comunidad, y yo no pretendería conocer la política involucrada.

Sin embargo, para un punto más grande, creo que estás tratando de resolver con un algorithm, a posteriori, algún problema que debe ser resuelto por un comité directivo y la comunidad, a priori.

Todo el dinero que tiene que no se compromete directamente a una característica específica o un problema relacionado con errores, lo puede utilizar para financiar el trabajo de refactorización y fontanería (que los backgrounds de los usuarios no reciben a través del sistema de recompensas).

Nunca es demasiado tarde para poner en marcha un sistema de este tipo y considerar que el dinero comprometido hasta ahora era una promise para el proyecto en general y debería ser reasignado dentro del proyecto por el comité directivo antes mencionado.

Solo una idea muy simple:

Divida el dinero por igual entre todos los desarrolladores que contribuyeron durante el último mes.

Puede ayudar a mantener a algunos de los desarrolladores involucrados en el proyecto, evitando que se peleen por dinero ya que todos recibirán la misma cantidad.

El dinero no era la razón por la que comenzaron a contribuir de todos modos. No debería ser así y probablemente no sea su principal motivación ya que el dinero de la donación probablemente nunca represente lo suficiente para pagar el valor real de las características que desarrollaron.

Aquellos que dicen que no sería justo recompensar a los desarrolladores basados ​​en statistics simples son los que no influyen lo suficiente en las statistics. Supongo que es tan simple como eso.

Me gusta mucho el sistema Mobbr. El que tuvo una participación influyente obtiene para lo que trabajó. ¡Solo puede haber muchos!

Diría que el mejor indicador de la calidad de participación de un usuario es la cantidad de confirmaciones aceptadas en la sucursal principal . Es decir, si recompensas a las personas que agregan más líneas, obtendrás algunos progtwigdores repitiendo el código y agregando líneas irrelevantes o networkingundantes solo para get una mejor participación. Eliminar líneas no es la mejor manera de identificar a los usuarios que mejoraron la calidad de su código, en mi opinión. Finalmente, la reciente contribución no define su calidad e incentivaría a los progtwigdores a entregar su trabajo lo más tarde posible … ¡Espero que haya sido de ayuda!