Contribuir a RWTS™
Las propuestas son bienvenidas. Los parches, no. Esta página explica ambas cosas y cómo enviar una propuesta.
Proponga un cambio
Si está implementando RWTS y el estándar no cubre lo que necesita, eso es lo más útil que nos puede decir. Un tipo de equipo que falta, un código de alarma sin entrada, un comportamiento del dispositivo que la especificación deja sin definir: envíelo.
Lo que más ayuda:
- El problema, no la solución: qué intentaba hacer y dónde se quedó corta la especificación
- El equipo o la instalación a los que corresponde, para que el cambio quede en la familia correcta
- Un caso fallido o un mensaje de ejemplo, si lo tiene
- La versión y el perfil que está implementando
Leemos cada propuesta. Las propuestas adoptadas se reconocen con el nombre de su autor en el registro público de cambios, salvo que usted pida lo contrario.
Por qué no aceptamos código
EPU no acepta pull requests ni contribuciones de código a la biblioteca de referencia en Python, y no acepta texto redactado para la especificación. Decirlo con claridad es mejor que una política silenciosa, así que a continuación explicamos el razonamiento.
Así se mantiene la doble licencia de la biblioteca de referencia. La biblioteca se ofrece bajo AGPL-3.0-only y, por separado, bajo una licencia comercial para fabricantes que no pueden aceptar copyleft. Esa segunda opción solo existe mientras EPU sea titular de todos los derechos de autor del código. Una sola contribución externa sin una cesión de derechos por escrito la eliminaría para siempre, porque volver a licenciar requeriría el consentimiento de ese colaborador de ahí en adelante.
Las ideas no están protegidas por derechos de autor. La expresión, sí. Describa un problema y el comportamiento que necesita, y podremos implementarlo libremente, sin reclamo alguno de derechos. Pegue un fragmento de código funcional que se use tal cual, y ese fragmento es su expresión protegida por derechos de autor, que entra en el código base sin licencia. La política existe para mantener clara esa línea, en ambas direcciones.
Así funcionan normalmente los estándares. Los estándares publicados evolucionan mediante propuestas y comentarios, con un editor que se encarga de la redacción, no mediante fusiones de código. Lo mismo aplica al texto de la especificación: EPU reescribe cada propuesta adoptada antes de que se vuelva normativa.
Si el código es la forma más clara de describir lo que quiere decir, envíelo e indíquelo. Construiremos una versión independiente a partir de su descripción, sin trabajar a partir de su código, o le pediremos una breve cesión de derechos por escrito.
Lo que esto no restringe
Nada de lo anterior limita lo que usted puede hacer con RWTS. La especificación tiene licencia abierta y puede implementarse libremente en cualquier producto, incluido firmware propietario. Puede bifurcar (fork) la biblioteca de referencia bajo AGPL y llevarla adonde quiera. No necesita permiso, un acuerdo ni una conversación con nosotros para construir sobre el estándar.
Esta página trata solo de lo que se incorpora a la especificación canónica y a la biblioteca canónica, y de nada más.
Proponga un cambio a RWTS™
Un nuevo tipo de equipo, un nuevo código de alarma, un comportamiento que el estándar aún no cubre.
Únase a la lista de espera
Reciba la especificación de RWTS™, el enlace a GitHub y la biblioteca de referencia en Python en cuanto se publiquen.