source proyectos para open mejores herramientas desarrollo open-source project-management installation

open-source - proyectos - mejores herramientas open source



Mejores prácticas para la configuración y gestión de un proyecto de código abierto (8)

Más adelante este año, quiero lanzar un framework PHP en el que he estado trabajando como código abierto. Yo uso control de fuente (SVN), pero es sobre una base extremadamente limitada. Soy autodidacta, me desarrollo solo y no tengo la experiencia de trabajar con grandes equipos. Tengo algunas ideas sobre lo que puede ayudar a que un proyecto sea exitoso, pero estoy confuso en algunos de los detalles. Como aún no se ha lanzado, quiero hacer todo lo posible para configurar la infraestructura adecuada desde el principio. ¿Qué necesito saber para configurar y administrar un proyecto exitoso?

Algunas ideas que tengo para hacerlo exitoso (más allá de su comercialización):

  • Buena documentación y tutoriales.
  • Pruebas unitarias automatizadas y compilaciones para actualizar el sitio web
  • Una hoja de ruta clara
  • Seguimiento de errores integrado con el control de fuente.
  • Una guía de estilo para mantener el código consistente.
  • Un foro para que la comunidad obtenga apoyo, comparta ideas, etc.
  • Un buen ejemplo de aplicación construida con el framework.
  • Un blog para mantener informada a la comunidad.
  • Mantener la compatibilidad hacia atrás siempre que sea posible.

Algunas de mis preguntas:

  • ¿Cómo configuro y automatizo una actualización de docs-push de la API de envío-prueba-confirmación-generación-generación en el proceso del sitio web? Edit : ¿Serían Ant o Maven buenos candidatos para esto? Si es así, ¿conoce algún recurso para configurar un proyecto PHP usándolos?
  • ¿Cómo manejo (técnicamente) los envíos de otros usuarios? ¿Cómo puedo asegurarme de que esas presentaciones deben aprobarse antes de integrarse?
  • ¿Cuáles son algunas de las trampas que se pueden evitar en términos de la comunidad del proyecto? Preferiría que fuera lo más amable y servicial posible sin mucho drama.

Me encantaría aprender de tu experiencia en cualquiera de estos puntos. Si crees que me estoy perdiendo algo grande, por favor comparte eso también. Cualquier recurso (preferiblemente orientado hacia un principiante) al que me podría dirigir también sería muy apreciado.

Estoy empezando en proyectos comunitarios, pero te daré algunos consejos sobre lo que sé.

¿Cómo configuro y automatizo una actualización de docs-push de la API de enviar-probar-comprometer-generar-un-paso al proceso del sitio web?

Nunca lo he implementado como un proceso. Podría simplemente tener una lista de verificación, y posiblemente incluso crear algunos scripts para realizar ciertas tareas. Nunca he trabajado con ningún control de origen que automatice la carga y que se realice mediante un script. La mayoría de las veces, hay alguna interacción en la web para participar.

No quieres impulsar cambios en la API hasta que sea un lanzamiento oficial.

EDITAR: Ambiente de trabajo

Para PHP, la mayoría de las veces, edito directamente en el servidor y lo pruebo allí, utilizando un beta.example.com , o similar, antes de pasar a example.com. También puede configurar un entorno web en la PC de su hogar (utilizando XAMPP para Windows o la instalación estándar de LAMP en Linux). Probablemente solo usaría un espejo de su repositorio aquí, por lo que haría svn commit , o lo que sea apropiado para el VCS o DVCS que elija.

La parte divertida es probar esto con diferentes versiones de PHP. No lo he hecho yo mismo, pero probablemente podría usar un archivo .htaccess para ejecutar un binario PHP diferente para probarlo. No estoy realmente seguro de cuál es la mejor opción para esto.

No he hecho mucho con la API, ya que nunca he creado una biblioteca, solo hice una búsqueda rápida que encontré en http://www.phpdoc.org/ . Parece un proyecto maduro, por lo que podría ser un punto de partida.

En cuanto a la creación de versiones, generalmente creo un script que solo incluye los archivos que forman parte de la distribución (filtrará los archivos VCS y cualquier cosa que no desee en el archivo distribuido). Podría escribir un script alrededor de find en Linux (que es lo que hago la mayor parte del tiempo), o puede haber otras opciones mejores.

¿Cómo manejo (técnicamente) los envíos de otros usuarios? ¿Cómo puedo asegurarme de que esas presentaciones deben aprobarse antes de integrarse?

Esto es manejado principalmente por el rastreador de errores, y acceso limitado en el Sistema de Control de Versiones. Por lo general, usted y las personas que permite pueden comprometerse con el VCS. Otros usuarios pueden enviar parches, pero es posible que alguien haga que lo revisen, lo prueben y lo confirmen. Puede dividir estas tareas en equipo o asignar un parche a una persona y hacer que lo hagan todo.

¿Cuáles son algunas de las trampas que se pueden evitar en términos de la comunidad del proyecto? Preferiría que fuera lo más amable y servicial posible sin mucho drama.

Solo me aseguraría de mantenerlo lo más positivo posible con los miembros del proyecto y la comunidad. Habrá algunos desacuerdos, y ahuyentarán a algunas personas, pero mientras tengas un producto estable que satisfaga las necesidades de la mayoría de las personas, creo que eso es todo lo que cualquiera puede esperar.

Lo más importante que debes hacer es atraer usuarios. Sin usuarios, no recibirás ninguna contribución y los desarrolladores te ayudarán. Porque los desarrolladores son usuarios primero, y luego deciden extender / arreglar algo que usan y podrían convertirse en contribuyentes.

Así que para conseguir usuarios, deberías considerar

  • describe lo que hace tu marco en una o dos oraciones en la parte superior de la página de tu proyecto
  • mencione cómo se puede usar su marco y para qué, para qué situaciones es más útil
  • Agrega muchos ejemplos sobre cómo usarlo.
  • Menciona si tu framework es estable, beta o alfa. Eso es importante porque el usuario debe saber que antes de comenzar a usarlo
  • también menciona si quieres seguir mejorándolo y sigue trabajando en él (la mayoría de los usuarios no quieren usar un marco que está abandonado (también debes tener en cuenta que muchos usuarios verifican tus confirmaciones para ver si realmente estás trabajando en él) Si su último compromiso con el repositorio fue hace meses, entonces realmente no está trabajando en él, por lo que no es posible hacer trampa.

Si tienes todo esto y la gente comienza a enviar parches, puedes usar una herramienta de parches para aplicarlos a tu fuente. Dependiendo de su sistema de control de versiones, puede usar el parche de GNU, una herramienta de parches / diferencias que viene con su control de versiones o tal vez incluso una herramienta de GUI que lo ayude con esto. SVN no tiene una herramienta de parche (todavía), pero ''svn diff'' creará un archivo de parche que luego puede aplicar con la herramienta de parche GNU, o si está usando TortoiseSVN, arrastre el archivo de parche derecho a su copia de trabajo y haz que TortoiseMerge lo aplique por ti.

Y sobre cómo tratar mejor con la comunidad:

  • responda las preguntas a tiempo, no espere más de dos o tres días para responderlas
  • Trate de ser amable, incluso con gente molesta y enojada. Solo si siguen molestando, díganles que (aún de una manera agradable si es posible) vayan a otro lado
  • siempre mantenga las discusiones sobre el proyecto en una lista de correo. No desea repetir las mismas discusiones una y otra vez; si tiene una lista de correo, simplemente señale a los usuarios los archivos antes de que la discusión comience nuevamente.

Y debería ver la charla " Cómo los proyectos de código abierto sobreviven a las personas venenosas (y usted también puede hacerlo ) ": es realmente bueno y le dice mucho sobre cómo tratar no solo con las "personas venenosas" sino también cómo tratar con todas las personas involucradas. en tu proyecto

Me gustaría agregar que debería hacer que los usuarios puedan ejecutar todo el proceso y modificar el código de la forma más fácil posible: estos "usuarios avanzados" se pueden "convertir" en desarrolladores o al menos a las personas que envían parches más pequeños.

No intente hacerlo todo usted mismo: para proyectos de código abierto hay varios proveedores de alojamiento que resuelven la mayoría de los problemas. Recomiendo codeplex o google code.

La configuración de los scripts de construcción dependerá de la cantidad de plataformas que configure, pero en general, es fácil agregar cualquier herramienta que desee al script una vez que comience a usar cualquier tipo de script de construcción.

Si realmente necesita el proceso de un solo paso que describe, necesita un servidor de compilación. Utilizo TeamCity, que he configurado para vigilar cualquier cambio en svn y desencadenar compilación / prueba cada vez que se registre algo. El servidor de compilación generalmente podrá realizar los pasos que usted coloque en el script de compilación.

Tienes un gran conjunto de ideas para comenzar. ¡Puede que tengas que empezar por recortarlos! Pregúntate a ti mismo qué es necesario para un primer lanzamiento.

  1. Para automatizar las compilaciones y las pruebas, los scripts se pueden hacer con ant, maven o phing para proyectos PHP.

  2. Probablemente necesitará un host para poder demostrar el producto. Para PHP es bastante fácil de encontrar.

  3. Necesita un proveedor de alojamiento de código abierto, especialmente github (pero también código de Google, forge de origen, etc.). Github proporciona seguimiento de errores, licencias predeterminadas, blog y excelentes mecanismos para aceptar cambios de la comunidad. Construido sobre git, facilita bastante bien los proyectos distribuidos.

Si bien es bueno tener una compilación e instalación en un solo paso, automatizar la integración de otros cambios probablemente no sea importante (o deseable) fuera de control.

¡Buena suerte!

Una sugerencia menor que me ha funcionado bien: comience a usar los pronombres en plural en primera persona, en lugar de los singulares. Es decir, hablar de "nosotros" y "nosotros" en lugar de "yo" y "yo". Alienta a otras personas a participar cuando se sienten parte de un equipo, en lugar de sentir que contribuyen con su propio engrandecimiento.

Lea sobre Git como una alternativa a SVN

  • repositorio público gratuito / bug tracker / wiki / fork-enabled en Github (que aloja symfony y PHPUnit entre otros)
  • " ¿Cómo gestiono (técnicamente) las presentaciones de otros usuarios? ¿Cómo puedo asegurarme de que esas presentaciones deben aprobarse antes de integrarse? " - con Git, extraiga lo que usted / su equipo más cercano encuentre más interesante para la rama maestra

API consistente

  • inspirarse en otras API públicas: s
  • solo cambio en versiones mayores
  • adivinable

Interesante tanto para usuarios como para desarrolladores.

  • objetivo claro (su hoja de ruta - excelente)
  • Útil, contra todo lo demás disponible.
  • fácil de usar, pero no es lo suficientemente fácil de escribir / mantener por sí mismo

Puedes revisar Ant o Phing para construir tu proyecto. Incluya CodeSniffer en la compilación y ahorrará tiempo en la comprobación de errores / diferencias de formato básicos.

Estos son todos consejos técnicos, sobre la parte suave ... trate a los humanos con respeto, mucho interés y esté muy entusiasmado con sus contribuciones y hágales sentir que no están perdiendo el tiempo. Eso me atraería.