• Quiero ayudar al desarrollo del código, ¿qué puedo hacer?
Quizá lo mejor es comenzar con el arreglo de fallos o con pequeñas mejoras para familiarizarte con el código. Los excitantes planes de los recién llegados sobre la implementación de grandes cosas suelen acabar en el limbo, porque el código de LyX es hoy en día complejo y difícil de asimilar a corto plazo. ;)
  • ¿En qué fallos o mejoras debería trabajar?
Regla nº 1: arregla los fallos que te molestan personalmente o intenta aquellas mejoras que te entusiasmarían. El primer contacto con el código suele ser duro pero con ese ímpetu se pueden vencer los problemas. No disponemos de mucha documentación. No dudes en preguntar en la lista acerca de cómo se organizan las cosas. El tiempo del que dispone el personal para explicar código es variable, pero intentaremos prestar ayuda.
Otra sugerencia es empezar buscando aquellos fallos que ya disponen de parches, que están aquí. Trabajar en ellos suele conllevar la actualización de los parches y ver cómofuncionan, lo cuál es una buena forma de iniciarse con el código. Los fallos marcados con la clave "easyfix" (fáciles de arreglar) constituyen un punto de partida obvio para empezar.
  • ¿Cómo se determina la asignación de tareas o fallos?
No somos un grupo formalmente organizado, la gente hace lo que le apetece. Probablemente, lo más importante es leer la lista de desarrollo. Así uno sabe generalmente quién está trabajando en qué tarea. También se puede obetener información del estado de la cuestión en nuestro rastreador de fallos. El campo asignación en los fallos no significa gran cosa, en particular no quiere decir que que alguien en concreto esté trabajando en un fallo. Siempre puedes preguntar en la lista si no estás seguro... ;)
  • Una vez que tengo una tarea decidida, la tengo asignada en exclusiva o la trabaja otra gente paralelamente?
No hay exclusividad pero, naturalmente, nadie perderá tiempo en un asunto si se sabe que ya alguien lo está abordando. Por supuesto, hay excepciones, pero en general cada uno está en lo suyo y cuando el código está listo aparece en la lista con mensajes como "Tengo el parche para arreglar/mejorar esto, ¿hay comentarios u objeciones?"
Sin embargo, si empiezas a trabajar en un fallo concreto y te va a llevar algún tiempo, podrías añadir un comentario al fallo para que lo sepa la gente.
  • ¿Hay una lista de tareas pendientes ("todo list") donde pueda encontrar fallos para arreglar y nuevas características a implementar?
Sigue la lista de correo de desarrolladores.
Nuestro rastreador de fallos colecciona los informes de fallos y de tareas de los usuarios y es el sitio principal donde mirar.
Tenemos algunos planes, pero son sólo aproximados.
  • ¿Cómo puedo remitir el código que he mejorado? ¿Quién lo comprueba?
Los nuevos deberían enviar sus parches a la lista de desarrollo, y si un parche es aprobado alguien lo remitirá. Al principio prepárate para multitud de comentarios, incluyendo especialmente lo que tiene que ver con el estilo del código, aunque pueda parecer trivial. (Lee los archivos en desarrollo/código para ver algunas de nuestras reglas, pero por lo demás intenta seguir el estilo existente!) Cuando un recién llegado lleva por aquí unos meses, arreglando fallos etc., y se ha ganado la confianza del equipo de desarrollo, entonces él o ella obtendrá permiso de acceso y se convertirá en miembro del equipo. No hay normas estrictas para esto.
  • ¿Es posible codificar en Python?
LyX es sobre todo C++, así que la mayoría de características nuevas y arreglos implicarán código C++. No obstante, tenemos algunas partes en Python si ésta es tu área de conocimiento. En particular puedes buscar fallos en lyx2lyx aquí. Otra parte es nuestro código para detección y configuración de aplicaciones externas. Los fallos a resolver suelen estar relacionados con solicitudes para mejorar la detección de aplicaciones de terceros o los convertidores y se suelen señalar como "easyfix".