El estilo ｫcl疽icoｻ de los manuales no es el adecuado para el dictado de un curso, donde el docente quiere decidir el temario y proponer un rumbo en su dictado. Esta clase de documentaci? no provee la flexibilidad necesaria, porque aunque se dispone en muchos casos de su ｫc?igo fuenteｻ, el trabajo de compaginaci? es bastante y poco reutilizable.

Ejemplo: como docente, yo poseo un manual de sendmail el cual en su primer cap?ulo habla de reglas m4. Ese cap?ulo es excelente si quiero dictar una clase de sendmail exclusivamente pero muchas veces La recompaginaci? no era parte del proyecto, sino que era una actividad paralela de los docentes que la necesitaban. La generaci? de infinta cantidad de cuadernillos con las distintas combinaciones de temas para abarcar todos los posibles cursos, es algo obviamente imposible de hacer.

Cuando un mismo tema era inclu?o en varios cursos, pasaban a haber dos copias (o mas) de un mismo texto, haciendo el mantenimiento de 駸tos imposible, y quedando estos nuevos cuadernillos obsoletos para posteriores cursos por el simple hecho que no eran actualizados. Esto provocaba mas trabajo extra a?, ya que deb?mos realizar el mismo trabajo de recompaginaci? a la hora de generar el material para una nueva versi?.

El duro trabajo de refinamiento que se realiza a los cursos derivados se perd?. La acci? de actualizar y corregir el material en estos cuadernillos provocaba un desperdicio de esfuerzo ya que no se ve?n reflejados los cambios en las versiones principales en el proyecto, dicho de otra manera: el trabajo de redacci? que no se hac? en respositorio el proyecto, no se pod? reutilizar.

Ejemplo: Debemos dar cuatro cursos, uno destinado a programadores, otro a administradores de sistemas, otro a usuarios de escritorio y otro oficinistas. Los programadores y los administradores tienen varios temas en com? como ser los comandos b疽icos y la programaci? en shell. Al mismo tiempo los usuarios de escritorio y los oficinistas necesitan aprender el uso de un paquete ofim疸ico (a diferentes niveles). Por otro lado, un programador necesita conocer el funcionamiento de un entorno de escritorio al igual que un oficinista. Preparamos los cuatro cuadernillos duplicando los contenidos en com? y damos los desactualizado y por ejemplo el KDE versi? 1.x ya fue reemplazado por la versi? 2.x o 3.x. Por otro lado, al dictar el curso nos damos cuenta de un error en la documentaci?, para corregirlo tenemos dos opciones: corregimos nuestra copia del cuadernillo o todas las copias, present疣dose en ambos casos obvios problemas.

documento actualizado se obtiene en minutos. Adem疽, si en nuestro curso un tema espec?ico como por ejemplo Apache toma relevancia, f當ilmente se puede ascender a la categor? de cap?ulo si anteriormente estaba como una simple secci?.

Otra ventaja de este modo de trabajo es que el intercambio y expansi? de temarios entre docentes se realiza de manera simple permitiendo la personalizaci? de cada curso.

Ejemplo: en la forma original de trabajo, sin entrar en la recompaginaci? del temario, se deb?n incluir todos los temas de los manuales, pudiendo no ajustarse a las necesidades del grupo al cual se le dictaba la clase. Hoy con las porciones en poco tiempo se puede generar un temario personalizado.

El sistema de documentaci? por componentes acarrea sus propios problemas que debemos enfrentar y solucionar:

Las soluciones que vemos viables:

Luego de vagabundear con nuestro proyecto fuimos cordialmente invitados por los coordinadores de LuCAS, a ser parte de este gran equipo.

           http://www.lunix.com.ar/cursos-temario.php
Aunque existan distintos tipos de trabajo dentro del proyecto, no
existe una jerarqu? en todo el esquema. El rol de coordinador
simplemente sirve para organizar un poco las tareas a realizarse, y
canalizar esfuerzos. El contenido de los manuales se decide en
conjunto y cualquiera dispuesto a ayudar tiene todo el derecho de
opinar, tratando de llegar a un concenso entre todos.

Roles: