Gobernanza de NuGet

Este documento se basa en el modelo de gobernanza del dictador benevolente por la Universidad de Oxford. Tiene licencia bajo Creative Commons Atribución-CompartirIgual 2.0 UK: Inglaterra & Gales License.

El proyecto NuGet está dirigido por un dictador benevolente y administrado por la comunidad. Es decir, la comunidad contribuye activamente al mantenimiento diario del proyecto, pero la línea estratégica general está dibujada por el dictador benevolente. En caso de desacuerdo, el dictador benevolente tiene la última palabra.

Es el trabajo del dictador benevolente resolver controversias dentro de la comunidad y garantizar que el proyecto pueda avanzar de una manera coordinada. A su vez, es el trabajo de la comunidad guiar las decisiones del dictador benevolente a través de la participación y la contribución activas.

Roles y responsabilidades

Hay cuatro roles descritos aquí: Dictador Benevolente, Comprometedores, Colaboradores y Usuarios.

Dictador benevolente

El equipo principal de NuGet se nombra a sí mismo como dictador benevolente o líder del proyecto. Sin embargo, dado que la comunidad siempre tiene la capacidad de bifurcar, el equipo es totalmente responsable ante la comunidad. Se espera que el jefe del proyecto comprenda la comunidad en su conjunto y se esfuerza por satisfacer tantas necesidades conflictivas como sea posible, a la vez que garantiza que el proyecto sobrevive a largo plazo.

De muchas maneras, el papel del dictador benevolente es menos sobre la dictadura y más sobre la diplomacia. La clave es asegurarse de que, a medida que el proyecto se expanda, a las personas adecuadas se les otorgue influencia sobre éste y que la comunidad se una detrás de la visión del líder del proyecto. El trabajo del líder es asegurarse de que los colaboradores (consulte a continuación) toman las decisiones correctas en representación del proyecto. Por lo general, siempre que los colaboradores estén alineados con la estrategia del proyecto, el líder del proyecto les dará la libertad de proceder como lo deseen.

Además, el personal de .NET Foundation considera que el proyecto dirige el punto de contacto principal o el primer punto de contacto para NuGet con fines de operaciones empresariales, incluidos los registros de dominio y los servicios técnicos (por ejemplo, la firma de código).

Confirmadores

Los comisores son colaboradores que han realizado contribuciones valiosas y sostenidas a NuGet y son nombrados por el Dictador Benevolente. Una vez designados, se confía en los committers para escribir código directamente en el repositorio y revisar las contribuciones de otros. Los confirmadores suelen ser desarrolladores, pero pueden contribuir de otras maneras.

Normalmente, un colaborador se centra en un aspecto específico del proyecto, y aporta un nivel de experiencia y comprensión que le hace merecedor del respeto de la comunidad y el líder del proyecto. El rol de committer no es oficial, es simplemente una posición que los miembros influyentes de la comunidad asumen dado que el líder del proyecto los consulta para obtener orientación y apoyo.

Los commits no tienen autoridad cuando se trata de la orientación general de NuGet. Sin embargo, tienen el oído del jefe del proyecto. Es trabajo del integrante asegurarse de que el líder sea consciente de las necesidades y los objetivos colectivos de la comunidad, y que ayude a desarrollar o extraer contribuciones adecuadas al proyecto. A menudo, a los confirmadores se les da control informal sobre sus áreas específicas de responsabilidad y se les asignan derechos para modificar directamente determinadas áreas del código fuente. Es decir, aunque los committers no tienen autoridad explícita de toma de decisiones, a menudo encontrarán que sus acciones se alinean con las decisiones tomadas por la persona líder.

Colaboradores

Los colaboradores son miembros de la comunidad que envían revisiones a NuGet. Estas parches pueden ser un evento único o producirse a lo largo del tiempo. Las expectativas son que los colaboradores envíen parches que sean pequeños al principio y crezcan en tamaño cuando el colaborador, los confirmadores y el líder del proyecto hayan construido confianza en la calidad de los parches de un colaborador. En el documento de notas de la versión del producto asociado se reconocen a los colaboradores.

Antes de que la primera revisión de un colaborador se coloque en el repositorio, deben firmar un contrato de licencia de colaborador o un contrato de asignación a .NET Foundation. El parche se puede enviar y analizar, pero realmente no se puede integrar en el repositorio sin el papeleo adecuado. Para obtener un contrato de licencia de colaborador, envíe una solicitud por correo electrónico a contributions@nuget.org.

Para convertirse en colaborador, envíe una solicitud de incorporación de cambios a uno de los repositorios siguientes:

El proceso detallado para enviar una solicitud de incorporación de cambios varía según el repositorio:

Users

Los usuarios son miembros de la comunidad que necesitan y usan NuGet, como consumidores de paquetes o autores. Los usuarios son los miembros más importantes de la comunidad: sin ellos, el proyecto no tendría ningún propósito. Cualquier persona puede ser un usuario; no hay requisitos específicos.

Los usuarios deben animarse a participar en la vida de NuGet y la comunidad tanto como sea posible. Las contribuciones de usuario permiten al equipo del proyecto asegurarse de que satisfacen las necesidades de esos usuarios. Entre las actividades comunes del usuario se incluyen, entre otras, las siguientes:

  • Abogar por el uso del proyecto
  • Informar a los desarrolladores de puntos fuertes y débiles del proyecto desde la perspectiva de un nuevo usuario
  • Proporcionar apoyo moral (un agradecimiento puede hacer mucho)
  • Escritura de documentación y tutoriales
  • Presentación de informes de errores y solicitudes de características
  • Participar en eventos de la comunidad, como maratones de corrección de errores
  • Participar en foros o paneles de discusión

Los usuarios que siguen participando en el proyecto y su comunidad a menudo se encontrarán cada vez más implicados. Estos usuarios pueden pasar a convertirse en colaboradores, como se ha descrito anteriormente.

Sucesión de paquetes en circunstancias especiales

En la situación desafortunada en la que un titular de la cuenta NuGet está incapacitado o fallecido, trabajaremos con la comunidad para agregar los propietarios adecuados al paquete donde dicha cuenta tiene la única propiedad y el paquete se publica bajo una licencia aprobada por OSI. Para solicitar la propiedad, debe enviarnos los siguientes documentos:

  1. Una fotocopia de su identificación con foto emitida por el gobierno.
  2. Uno de los siguientes documentos que demuestran el estado del titular de la cuenta anterior:
    • Un certificado de muerte oficial emitido por el gobierno si el titular de la cuenta anterior está fallecido, o bien,
    • Un documento certificado como un certificado firmado por un profesional médico encargado del cuidado de un titular de cuenta incapacitado.
  3. Uno de los siguientes documentos demuestra su derecho a la propiedad:
    • Certificado de matrimonio que muestra que usted es el cónyuge superviviente del titular de la cuenta,
    • Poder firmado de abogado,
    • Copia de un documento de testamento o fideicomiso que le designe como ejecutor o beneficiario.
    • Certificado de nacimiento para el titular de la cuenta, si usted es su padre o madre,
    • Papeleo de custodia si es tutor legal del titular de la cuenta.

Si necesita invocar esta directiva, envíenos un correo electrónico con support@nuget.org el identificador y la versión del paquete.

Transparencia

La creación de confianza de la comunidad en la gobernanza de un proyecto de código abierto es fundamental para su éxito. Para ello, la toma de decisiones debe realizarse de forma transparente y abierta. La discusión sobre la dirección del proyecto debe realizarse públicamente. La comunidad nunca debe ser sorprendida por una decisión del Dictador Benevolente. Además, se debe archivar la discusión sobre las decisiones del proyecto para que los miembros de la comunidad puedan comprender todo el historial de una decisión y su contexto.

  • Last updated on