HellCode Collective separates experimentation from publication. New projects incubate privately and receive the minimum access necessary. Public release is an explicit owner decision after the readiness gate has passed.
- Founding steward: @MrDevilinDisguise safeguards the mission, publication standard and initial maintenance direction. This stewardship does not replace repository ownership or contributor credit.
- Organization owners manage membership, visibility, organization settings and emergency access. This role stays small.
- Project maintainers own technical direction, review, releases and ongoing support for one project.
- Community moderators maintain healthy Discussions and apply the code of conduct.
- Security responders coordinate private vulnerability intake and disclosure.
- Contributors propose and deliver scoped changes through the documented workflow.
HellCode Collective is the institutional publisher. Human commits, reviews and
releases identify the responsible account; automated publications identify the
automation actor. The canonical attribution policy is documented in
MAINTAINERS.md.
The teams community-moderators and security are created when a second member
joins. Project-specific maintainer teams are created only when a project needs
shared access.
GitHub Free requires organization members to retain the technical ability to
create public repositories. HellCode Collective therefore treats public
creation as an owner-only policy even when the interface cannot enforce it:
members create incubator repositories as private, and an owner approves every
public repository or visibility change. The base repository permission is
none; access is granted explicitly by project.
- Reversible project decisions are made by project maintainers and recorded in the repository decision log.
- Cross-organization policy changes require an organization owner and a public rationale.
- Security incidents may be handled privately until disclosure is safe.
- Unresolved technical disagreements are escalated from evidence gathering, to a written proposal, to an owner decision as a last resort.
A private prototype may become public only when it has a clear purpose, replaced all template placeholders, selected a license, documented setup and support, defined maintainers, passed its checks, enabled appropriate security controls and completed a final secret scan.
HellCode Collective separa la experimentación de la publicación. Los proyectos nuevos se incuban de forma privada y reciben el acceso mínimo necesario. La publicación es una decisión explícita de una persona propietaria después de superar la lista de preparación.
- Fundador responsable: @MrDevilinDisguise protege la misión, el estándar de publicación y la dirección inicial de mantenimiento. Esta responsabilidad no sustituye la propiedad de los repositorios ni el crédito de cada persona contribuidora.
- Propietarios de la organización: gestionan membresía, visibilidad, configuración y acceso de emergencia. Este rol se mantiene reducido.
- Responsables de proyecto: asumen dirección técnica, revisión, lanzamientos y soporte continuado de un proyecto.
- Moderadores de comunidad: cuidan Discussions y aplican el código de conducta.
- Responsables de seguridad: coordinan la recepción privada de vulnerabilidades y su divulgación.
- Contribuidores: proponen y entregan cambios acotados mediante el flujo documentado.
HellCode Collective es la entidad publicadora. Los commits, revisiones y
lanzamientos humanos identifican la cuenta responsable; las publicaciones
automatizadas identifican al actor de automatización. La política canónica de
atribución se documenta en MAINTAINERS.md.
Los equipos community-moderators y security se crearán cuando se incorpore
una segunda persona. Los equipos de mantenimiento de proyectos se crearán solo
cuando un proyecto necesite acceso compartido.
GitHub Free obliga a conservar para los miembros la capacidad técnica de crear
repositorios públicos. HellCode Collective aplica por tanto una política de
creación pública reservada a propietarios aunque la interfaz no pueda imponerla:
los miembros crean repositorios de incubación privados y una persona propietaria
aprueba cada repositorio público o cambio de visibilidad. El permiso base es
none; el acceso se concede de forma explícita por proyecto.
- Las decisiones reversibles pertenecen a los responsables del proyecto y se registran en su registro de decisiones.
- Los cambios de políticas transversales requieren una persona propietaria y una justificación pública.
- Los incidentes de seguridad pueden gestionarse en privado hasta que su divulgación sea segura.
- Los desacuerdos técnicos sin resolver pasan de recopilar pruebas, a una propuesta escrita y, como último recurso, a una decisión de propietario.
Un prototipo privado solo podrá ser público cuando tenga propósito claro, haya sustituido todos los placeholders, elegido licencia, documentado instalación y soporte, definido responsables, superado sus comprobaciones, activado los controles de seguridad adecuados y completado un escaneo final de secretos.