Resumen

  • Las reglas publicadas por Apache distinguen el veto cualificado de una modificación de código, el voto formal de lanzamiento y la supervisión corporativa del Board.
  • Un recibo de autoridad debe conservar acción, artefacto, grupo con voto vinculante, regla, objeciones y acto corporativo separado, sin convertirlos en un solo mandato.

Una misma Foundation no convierte todos los actos en una sola decisión

La frase «Apache lo aprobó» puede referirse a un commit, a una conversación en una lista, a un voto de lanzamiento, a una decisión de PMC, a una resolución del Board o a la lectura de un informe trimestral. La arquitectura publicada por ASF evita precisamente esa fusión. Da dirección técnica a cada proyecto y mantiene en el nivel corporativo los activos, las políticas generales, los cargos y la supervisión.

La unidad correcta de análisis es la acción. Un committer que actualiza un repositorio no produce por sí solo un lanzamiento oficial. Un Director que hace una pregunta sobre un informe no adquiere una voz técnica vinculante. Una persona puede ocupar varias posiciones, pero cada posición tiene un alcance propio.

El acceso al repositorio no equivale a la autoridad de lanzamiento

La guía de PMC indica que los committers pueden actualizar el código, mientras que solo el PMC como cuerpo puede votar lanzamientos formales. El contraste no rebaja el trabajo de quien contribuye. Separa la posibilidad técnica de cambiar fuentes del acto institucional que presenta un artefacto como software oficial de Apache.

Por eso un lanzamiento necesita una identidad estable: candidato, revisión, firma, suma de comprobación o identificador final. Un resultado sin ese objeto no permite saber qué se decidió. Tampoco demuestra que el Board revisó cada cambio, que todos los contribuyentes coincidieron o que los usuarios adoptarán el paquete.

El veto de código tiene fuerza, pero no es un comodín universal

La página de votación distingue asuntos procedimentales, modificaciones de código y lanzamientos de paquetes. En una modificación de código no lazy, la regla exige tres +1 y ningún -1. Un -1 de un votante cualificado es un veto, debe aportar justificación técnica y no puede anularse hasta que el votante lo retire.

La regla no dice que cualquier comentario negativo en cualquier lista paralice toda actividad de Apache. Se requiere la propuesta de código pertinente, el grupo aplicable y la cualificación correspondiente. El registro debe conservar la propuesta y su versión, la razón técnica, la condición del voto y su resolución: retirada, cambio de código o abandono. No convierte una discrepancia técnica en una decisión corporativa o en una declaración de mercado.

El lanzamiento formal pasa por otro umbral

Para un lanzamiento, Apache establece al menos tres +1 vinculantes y más positivos que negativos vinculantes. La misma guía dice que los lanzamientos no pueden ser vetoados. No es una versión debilitada de la regla de código: es una regla diferente para una acción diferente.

Así, afirmar que un -1 «vetó el lanzamiento» sin identificar el tipo de acción y la regla puede ser falso. Ese voto podría pertenecer a una modificación, ser consultivo o expresar una preocupación previa. Del mismo modo, que el lanzamiento haya pasado no borra objeciones técnicas ni prueba seguridad, adopción o calidad universal. Solo certifica la decisión formal de ese artefacto según el umbral establecido.

El PMC dirige el proyecto; el Board sostiene el marco corporativo

Los PMC fijan dirección técnica y comunitaria, gestionan lanzamientos y responden por el proyecto dentro de requisitos de la Foundation. El Board crea PMC, nombra Vice Presidents/Chairs, gestiona activos y políticas generales, recibe informes y puede actuar cuando un PMC no puede gobernarse o no sigue requisitos. Pero ASF también aclara que el Board no dirige técnicamente los proyectos.

Los Directores no reciben automáticamente committership, pertenencia a PMC ni voto técnico vinculante. Para participar técnicamente deben ganar mérito dentro del proyecto. Los Members eligen Directores y votan en elecciones de Members, pero tampoco obtienen por ello poder técnico específico en todos los proyectos.

El Chair vincula ambos planos sin mezclarlos. Tiene una voz normal en el PMC y, como officer, responde por informes y por el roster oficial. La decisión de un PMC sobre un cambio de Chair necesita una resolución del Board para convertirse en un nombramiento corporativo oficial.

Un recibo para autoridad de lanzamiento

Para una modificación de código, el recibo debería identificar el cambio, canal de revisión, regla, votantes cualificados, posiciones expresas, fundamento de un veto válido y resultado. Para un lanzamiento, debería fijar el artefacto, PMC, ventana, regla de voto vinculante, resultado e identificador final. Para un evento corporativo, debe decir por separado si hubo resolución, nombramiento, solicitud o simple revisión de informe.

El objetivo no es añadir un procedimiento Apache ni afirmar que toda discusión necesita expediente. Es impedir que «veto», «lanzamiento», «PMC» y «Board» se usen como etiquetas de autoridad sin el registro que les da significado.

Sources

  1. Apache Corporate Governance — PMCs
  2. Apache Voting Process
  3. Apache Project Management Committee Guide
  4. Apache Corporate Governance — Board of Directors
  5. Apache Corporate Governance — Members
  6. Lu Heng, The Multi-Stakeholder Mirage