En cierto momento, el número de acuerdos y arreglos que circulan por el proyecto pueden llegar a ser tan grandes que se necesita registrarlos en algún lugar. Y para dar legitimidad a esos documentos, hay que tener bien claro que están basados el las discusiones de las listas de correo y en acuerdos que ya estaban en vigencia. Cuando se los escribe, se hace referencia a las líneas de los archivos de la lista de correo y cada vez que no se está seguro sobre un punto, se pregunta de nuevo. El documento no debe contener sorpresas: Éste no es fuente de los acuerdos, sino solamente la descripción de ellos. Por supuesto, si es aceptado, la gente comenzará a citarlo como si fuera una fuente de autoridad, pero eso sólo significa que refleja con exactitud la voluntad de todos los del grupo.
Este es el documento aludido “Pautas de Desarrollo” en Capítulo 2, Primeros Pasos. Naturalmente, cuando el proyecto recién comienza, se tendrá que esbozar una guía, sin que por esto se excluya la confección de una posterior historia del proyecto. Pero, a medida que la comunidad madura, se pueden hacer ajustes del lenguaje para reflejar la manera final a la que se ha llegado.
No se debe pretender que uno lo ha dicho todo. Ningún documento puede captar todo lo que la gente necesita saber para participar en un proyecto. Muchos de los acuerdos del proyecto permanecen tácitos, nunca explicitados, sin embargo aceptados por todos. Algunas cosas son muy obvias para incluirlas, y resultarían distractivas al lado del material que no es obvio y es importante. Por ejemplo, no tiene sentido escribir en la guía una instrucción como "Sea educado y respetuoso con los otros miembros de la lista de correos, y no incite a las discusiones acaloradas" o "Escriba código sin errores, claros y limpios." Por supuesto que son cosas deseables, pero no existe un universo concebible donde estas cosas no sean deseables, por lo que no vale la pena mencionarlas. Si alguien es grosero en la lista de correos, o escribe el código con errores, no van a dejar de hacerlo sólo porque la guía del proyecto lo dice. Estas situaciones requieren atención en el momento que aparecen, y no bastan las normas generales que dicen que hay que ser buenos. Además, si el proyecto tiene líneas específicas sobre cómo escribir un código bueno, entonces esas líneas de la guía deber escribirse con todo el detalle que sea posible.
.Una buena manera de determinar qué debe incluirse en el documento es referirse a las preguntas que los recién llegados hacen, y a las quejas de los desarrolladores con experiencia. Esto no quiere decir que necesariamente tienen que convertirse en un informe FAQ—posiblemente el documento necesita una estructura narrativa más coherente que la que puede ofrecer el FAQ. Tiene entonces que seguir el mismo principio basado en la práctica, que hay que incluir asuntos que realmente se producen, y no tanto tratar de anticiparse a los asuntos que pueden producirse.
.Si el proyecto tiene un dictador benévolo, o si tiene miembros con poderes especiales (presidente, secretario general, o lo que sea), entonces el documento es una buena oportunidad de escribir los procedimientos de la sucesión de poderes. A veces eso puede ser tan simple como nombrar cierta gente como reemplazantes en el caso en que el DB abandone el proyecto por alguna razón. Generalmente, si hay un DB, es sólo él quien puede decidir el nombre de un sucesor. Si se elige una comisión, entonces el procedimiento de la elección y el nombramiento de los integrantes de la comisión tiene que estar descrito en el documento. Si al comienzo no existe un procedimiento, entonces hay que conseguir un consenso en la lista de correos antes de escribir sobre el procedimiento. Hay gente que puede ser sensible con las estructuras jerárquicas, por lo que el asunto tiene que ser tratado con delicadeza.
Quizás lo mas importante es dejar en claro que las reglas pueden ser reconsideradas. Si los acuerdos descritos en el documento comienzan a frenar el proyecto, recordar a todos que fue pensado como una reflexión viviente de las intenciones del grupo, no para provocar frustración y bloqueo. Si alguien toma por hábito pedir que las reglas se reconsideren cada vez que una regla se considera, no siempre conviene debatir el tema con ella—a veces el silencio es la mejor táctica. Si hay mas de uno que se une a las quejas, la campana ha sonado, y será lógico suponer que algo necesita ser cambiado. Si nadie se une a la queja, entonces esa persona no representa a nadie, y las reglas quedarán como están.
Dos buenos ejemplos de una guía para un proyecto es Subversion
hacking.html en http://subversion.apache.org/docs/community-guide/, y los documentos de gobierno de la Fundación de Software Apache, en http://www.apache.org/foundation/how-it-works.html y http://www.apache.org/foundation/voting.html. La Fundación de Software Apache es de hecho una colección de proyectos de software, organizada legalmente como una corporación sin fines de lucro, de modo que sus documentos tienden a describir los procedimientos de gobierno más que las convenciones de desarrollo. Vale la pena leerlas, porque representan una experiencia acumulada en muchos proyectos de fuente abierta.