[hm] [Core] [Organización] Teoría estructural para el hackmeeting - 2015
psy
epsylon en riseup.net
Mar Sep 22 17:44:49 CEST 2015
Aupa,
Con el mismo fin de seguir aportando y bajo el pragmatismo basado en la
teoría acumulada y la experiencia, aquí va una serie de analisis y
propuestas practicas para el hackmeeting 2015, partiendo del acta de la
última asamblea realizada por el colectivo:
http://sindominio.net/hackmeeting/wiki/2014/Acta_asamblea_final_Hackaleda
Aunque el texto pueda resultar largo, en el mismo además de reflexiones
existen preguntas que deben ser contestadas, así que pido algo de tiempo
de lectura, en compensación misma por el tiempo y reflexión aportadas
para la creación de la misma.
Gracias :-)
-----------------------------------------------------
- Compromiso:
Aunque no aparece el término de manera directa, lo que he visto es que
subyace en todos y cada uno de los puntos siguientes. Por eso vamos a
mencionarlo y analizarlo en primer lugar.
Si bien, existe una demanda por parte de antiguos miembros activos del
colectivo, de la necesidad de crear un relevo histórico, ésta sucede de
manera muy sutil y en comentarios fuera de acta. No sucede lo mismo con
las personas que han llegado en los últimos años, que expresan
públicamente la falta de compromiso de los miembros más activos en el
pasado.
Correcto. Se trata de un proceso bastante claro, que apela a la empatía
y que tiene que ver con la necesidad de materializar un relevo o
adaptación a nuevos tiempos.
Sin embargo, bajo mi punto de vista la solución no reside en demandar a
terceros, sino en incorporar iniciativas al proyecto, por ambas partes.
En el ejemplo simplificador, es necesario que exista compromiso mutuo.
De quienes buscan relevo, en encontrar los relevos y explicarles la
mecánica o al menos, colaborar en la documentación y automatización de
la comprensión (wiki, lista de correo..) de la misma. Como de quienes
llevan pocos años o al menos han acudido en una ocasión (si os fijáis,
trataremos más adelante a quienes nunca han estado de otra forma), que
deben de una forma y otra, adquirir un rol con mucha mayor iniciativa y
que trate, sino de transgredir las metodologías anteriores, al menos
tratar de ceñirse a ellas, en la mayor medida posible.
Quizás éste primer párrafo nos pueda sonar algo críptico, pero la
función de compromiso parte de una premisa totalmente individual y si
ésta no se da, lo colectivo pierde su estructuración y sentido. Es
decir, si una célula decide no participar, en función de la dependencia
que tenga el sistema de la misma, éste puede llegar al colapso.
Concretando mucho más, existe un "bloque de personas" del movimiento muy
concreto e identificado, que aunque parece no estar presente, sigue la
lista de correo, las acciones de lo colectivo, sino directamente, a
través de terceros. Es decir los vínculos de aparente (ojo!) dependencia
se encuentran forjados y aún existen, aunque su no presencia
desconcierta al resto del sistema. Por tanto, quizás una presencia,
meramente articular, como puede ser enviar un correo o participar en
alguna acción de comunicación del hackmeeting, será más que suficiente
para re-generar los niveles de compromiso globales a espensas del
resultado de la propuesta de compromiso individual latente.
Incluso, es posible que todo el sistema de compromiso se retroalimente.
Debemos diferenciar el compromiso para mejorar la metodología entre;
aquel que se adquiere de forma pública (hackmeeting como servicio) y
aquel que se destina a la interrelación de la asamblea con sus propios
actos (hackmeeting como entidad/fluído). El primero tiene que ver con
los nodos, los espacios, la comida y los servicios directos e indirectos
que hasta la fecha se han cumplido en mayor o menor medida. Ni que decir
tiene que revisarlos es un acto importante de sostenibilidad, para
ahorrar esfuerzos y dirigir mejor las energías. Proceso imprescindible
en casos como "Despedida del Hackmeeting".
Vuelvo a lo practico. La asamblea dice en Marinaleda: "Ha sido un
formato diferente de HM, pasamos de espacios autogestionados a en este
caso a utilizar las instalaciones dentro de un pueblo, que nos a dado
facilidad de gestión, ha sido un HM más familiar y menos estresante."
De lo que se perciben varios focos. El primero puede referirse al
"acomodamiento" del colectivo. El segundo puede ser el nivel de foco en
lo practico y el ahorro de energía estructural. El tercero la necesidad
de menos stress. Etc... Cualquiera nos sirve para llegar a construcción
de abstracción organizativa.
Siguiendo con el ejemplo de analisis y opinión, también útil como
formato herramienta para otras intervenciones similares, pienso de
manera personal que el colectivo ha olvidado la importancia de desplegar
una infraestructura desde 0. Hecho practico similar a un entrenamiento
militar, que se repite con noción de extensión, ejemplo y recordatorio y
muy útil en situaciones de excepción o extrema agitación social. Por
otro lado, ante la falta de energía motriz, se produce la necesidad de
facilitar los recursos básicos para llegar a conquistar espacios
similares a los creados por el pasado, en circunstancias practicas y en
los 3 o hasta 4 años anteriores, sin llegar a las espectativas creadas.
Por tanto, concluyo éste ejemplo diciendo que: "El hackmeeting es
dificil y no es cómodo, porque así debe ser. Su estructura organizativa
representa a la Asamblea, o gobierno del Pueblo (que no democracia) como
base de compromiso y acuerdo para la generación de una infraestructura
completa de computación, electrónica, comunicación y vínculo humano, en
un tiempo record y con recursos basados en aportaciones altruístas y
auto-organizativas." Es decir, está en el ADN del hackmeeting ser
"duro", para que la gente vea la perspectiva del "hazlo tu misma" más
practica y extrema posible (obtener agua, luz, calor, comida, techo....).
Si bien se puede teorizar y pasar a que el hackmeeting sea un mero
"consumidor" de otros espacios, bajo mi punto de vista ésto no debe
suceder. Lo que tampoco quiera decir que haya que quedarse sin luz o
agua sino se consigue. Siempre se puede apelar al parche efectivista,
siempre y cuando éste quede bien explicado. Ejemplo: "No conseguimos
tener luz del poste (cosa que nunca ha pasado, por cierto), así que para
éste paso vamos a usar un generador, que funciona así y así y que
contiene petróleo que viene de aquí y de aquí, en el caso de una
autoestructura, es preferible no crear depedencias de continuidad, como
la que supone que sin generador, todo se apaga, por tanto, aunque se va
a usar..bla bla bla..."
Dicho lo cual, mostrado el nivel de síntesis y sin objeto de alargarme
demasiado en cada tema, puesto que hay bastantes, paso a enumerar y
opinar sobre cada punto de la última asamblea, siempre con la finalidad
de sumar y no restar...
En primer lugar contestaré de manera personal a las demandas escritas de
la asamblea con mi opinión. Después realizaré una revisión, también
subjetiva de la revisión de protocolos, en éste caso, por grupo de
trabajo y finalizaré con una propuesta completa de estructuración de
colectivo... (de bilbo, hostias!) >)
-------------
1) Dinámicas de trabajo previa:
sindominio.net/hackmeeting/wiki/2014/Tareas/Crear_dinam%C3%A1micas_de_trabajo_previo
"Crear dinámicas de trabajo previo y conseguir la permanencia de los
proyectos, hacer realidad la incidencia local y dejar en funcionamiento
las propuestas hechas."
La creación de dinámicas de trabajo previo deben equilibrarse entre los
recursos disponibles, el nivel de compromiso y la capacitación. Y digo
equilibrio porque ahí radica la naturaleza correcta de funcionamiento de
cualquier sistema conocido. Son necesarios recursos (routers, cables,
mesas, sillas, etc...), así como compromiso multilateral. Eso parece
claro. Quizás la capacitación se obvia en el discurso inclusista y de
igualdad, pero debemos distanciarlo en la practica organizativa, "pues
no todo el mundo, sabe de todo."
Una manera de generar una dinámica es hacer un llamamiento específico
hacia la misma, demandando una serie de recursos mínimos, compromisio y
especialización. Una propuesta puede ser la creación de un "How to
deploy a hackmeeting", o como se quiera decir, que muestre los
requisitos mínimos, tanto materiales como humanos, para un evento de
éstas circunstancias pueda o no darse. Así es más sencillo ver, si un
año no se llega, que ese año no procede. (Ya en otro momento, hablaremos
de porque usamos el año romano como fuente de temporalidad y porque no
nos beneficia).
Si bien el infopoint puede servir, la Hoja de Ruta necesita ser
desarrollado en cada sub-sección:
http://sindominio.net/hackmeeting/wiki/Infopoint
Por otro lado se habla de "dejar funcionando lo que se ha comprometido a
hacer". También parece básico, pero requiere exactamente de los mismos 3
puntos que hemos descrito anteriormente. La solución es que la Asamblea
decida si nivel de compromiso para con el colectivo local que genera la
infraestructura de despliegue mientras ésta llega al lugar.
La soluciones propuestas (con nombres chungos) serían las siguientes:
- Formación: o llamada interna a los miembros de la lista a
participar y posicionarse para el año concreto. Ejemplo; "Oie fulanito,
quedan 2 meses para el hm...¿que vas a hacer éste año?". Es decir, crear
un registro de participantes de ediciones anteriores, para re-establecer
conexiones permanentes y eventuales.
- Energía Social: establecer en la wiki, no únicamente una entrada
para el tema del alojamiento y comidas, sino para la generación del
hackmeeting en su conjunto, donde se incluye alojamiento y comidas, pero
como servicio secundario, propio del feedback recibido por la
realización de tareas. Que quiero decir con ésto, que en vez de pagar 3
euros por un plato y andar manejando dinero, cosa bastante fea a
sabiendas de lo que el Capitalismo euro supone, debería ser un pago por
esfuerzo. En síntesis: "Ganarse el pan". Y aquí juega un papel
importante la re-estructuración de la tesoría que mencionaré más
adelante. Pero básicamente, dejar de "comprar en el hackmeeting"
camisetas, comida, etc y comenzar a "ganarlo por mérito propio"
- Servicios externos HM: la Asamblea, con miembros representativos
del grupo local (pero sin la participación decisoria de los mismos) que
se hace cargo del despliegue previo, debe dejar bien claro que va a
hacer. Y ojo, no se permite al grupo local participar para evitar que la
gente se lleve el Hackmeeting a su barrio, a su hacklab o por un interés
meramente personal. Por ejemplo: "El hackmeeting se compromete a dejar
una Radio, con un punto de montaje streaming y algo de material
electrónico, a consecuencia de la demanda del colectivo local de obtener
un espacio en Internet donde poder expresar sus luchas, bla bla bla...
Creo que se entiende bien con los ejemplos. Aún así puedo extenderme
mucho más si se desea en cada uno.
-------------
2) Gestión de la wiki:
sindominio.net/hackmeeting/wiki/2014/Tareas/Propuesta_de_equipo_para_desarrollar_y_gestionar_la_wiki
"Es una tarea del grupo Wiki, con prioridad Máxima, en la que se está
trabajando pero que necesita voluntarias.
Nadie se apuntó como dinamizadora de esta tarea."
Bien. Me es complicado entender que se quiere decir con ésta frase. Lo
digo porque tiene lo suyo. Mirad, voy a desengranar éste primero para
mostrar un ejemplo de lo que quiero decir. El párrafo incluye un "grupo
Wiki" sin mostrar que o quienes son ese grupo (un enlace), habla de
prioridades (es decir obligaciones), la etiqueta como "Máxima", se
comenta que se trabaja en ese momento (¿ahora, cuando se redactó,
durante el año, de siempre?), se hace un llamamiento a la voluntariedad
y de paso, se informa de que no existe un responsable o coordinador de
la misma. No se vosotras, pero yo aquí veo errores desde el mismo
momento en que no se está diciendo lo concreto o se está diciendo
demasiado sin poco. Ojo, no critico para nada a quien buenamente a
editado la wiki para ponerlo, ni mucho menos. Pero quiero que se me
entienda, que la responsabilidad de la Gestión de la Wiki es muy
importante y compleja. Es nuestra cara pública, nuestro legado, nuestro
futuro... Por tanto, hay que prestar antención a como estamos
comunicando. Más que nada, porque con frases como esa, conseguir
voluntarios no se cumplirá.
Al ser algo concreto, podemos darle sencilla solución, siempre y cuando
hayamos comprendido porque debemos cambiar esa "actitud" de
comunicación, en la propia Gestión de la Wiki.
Por ejemplo. Yo misma me apunto como dinamizadora de la tarea, aunque
agradecería que fuera cualquiera otra por temas de tiempo. De todas
maneras, propongo lo siguiente:
- Creación de una entrada en la wiki, a enlazar cuando se
requiera el Grupo de Wiki, con los siguientes puntos:
+ Grupo: Wiki
+ Dinamización: X
+ Objetivos:
- Gestionar el legado escrito y visual del
Hackmeeting, así como negociar y coordinar el alojamiento.
- Mantener la wiki (jardinería, control de spam,
comentarios, plugins).
- Actualizar el contenido (o proveer de fórmulas para
su actualización. X ej: usuario anónimo)
+ Participantes: YYYYYYYY
+ Contacto: (aquí me da lo mismo, lista de correo, una
nueva creada, correos personales...)
De ésta manera queda constancia del compromiso y los recursos, en línea
con lo que se argumentaba más arriba y permite visualizar a los
coordinadores y participantes, dando una mayor visibilidad al hecho de
la necesidad de voluntarixs. Siempre, mucho más útil para que éstos
sientan cierta empatía con respecto a sus capacidades y su tiempo y se
decidan a dar el paso y colaborar. Sin bien la lista puede quedar
des-actualizada, porque la wiki es un formato estático, al menos queda
constancia de estructura organizativa. Ya llegará la web semántica... :-P
-------------
3) Vender camisetas:
sindominio.net/hackmeeting/wiki/2014/Tareas/Vender_las_camisetas
"Se terminarán cuando se compre la tinta, luego se mandaran a Madrid
para su distribución. Se mandara la info a la lista cuando ya esten
alli. Se tienen que comprar algunas tallas más, las tintas y hacer el
envio, se enviará el presupuesto a la lista.
Es una tarea del grupo Autofinanciación, con prioridad Máxima, en la que
se está trabajando.
Nadie se apuntó como dinamizadora de esta tarea."
Como decía antes, no voy a desengranar todas las frases. Aquí la
pregunta es clara. ¿Llegaron las camisetas?. ¿Quien o quienes son los
responsables de la tarea?. ¿Cual es el protocolo de comunicación para
éste tipo de tareas?. ¿Se compraron las tallas?.¿Se envió el
presupuesto?....
Y sobre todo, ¿quien se apunta a dinamizar?.
Bien, también podemos resolver ésto de manera muy sencilla. Invoco desde
aquí al grupo Tesorería que nos comente las cuentas actuales y si es
posible, aclaren éste punto de la asamblea. Con el dato, la podemos
cerrar. Sino llega, como también debería estructurarse la tesorería,
quizás podamos cerrarla con otra metodología. Quizás no, seguro, que ya
está todo pensado. A por otra. ;-)
-------------
4) Revisar los protocolos:
sindominio.net/hackmeeting/wiki/2014/Tareas/Revisar_los_protocolos
"Revisar los protocolos usados hasta ahora y mejorar la organización,
reestructurar la gestión y distribucíon de responsabilidades."
Bueno, podemos decir que ésta intervención y la anterior por mi parte,
precisamente inciden en ésta tarea, así que si os parece, vamos a
cerrarla también.
Ojo, porque casi parece una petición al mundo hetéreo de que "todo se
solucione, bien y pronto", más que una tarea, pero como es la expresión
de la Asamblea, así será tomada en cuenta y por tanto, solventada.
Para mis los protocolos de la auto-organización pasan por varios
factores. Sin bien se hablaba en teorías pasadas de que eramos una
estructura caótica, o incluso, la "organización desorganizada", en la
practica ésto no es así. La estructura del hackmeeting es perfectamente
identificable y sus protocolos, aunque difusos porque se tratan de
experiencias de activistas en su faceta individual, pero puestas en
marcha de manera colectiva con variables diferentes, existes.
Tenemos muchos y muy buenos protocolos. Tenemos desde la lista de
correo, que aunque ahora nos parece algo normal, en su día ya era un
lugar de reunión que destacaba y que por cierto, aún sigue funcionando
(¿13 años después?), como la wiki, etc. Tenemos protocolos de decisión.
Protocolos de seguridad. Yo que se, un montón. Casi que enumerar unos
pocos ya sirve para darnos cuenta de que hay muchas más cosas ya
funcionando de las que creemos. Aunque sea en la memoria colectiva y en
los hechos descritos en nodos y charlas, estar, están y sirven.
De todas maneras, aunque la demanda parece difusa, lo que se busca es
seguro la concrección. Se me ha ocurrido que una manera de revisar esos
protocolos es a través de los grupos de trabajo encargados de que se
establezcan y se cumplan.
De hecho, paso a analizarlos tal y como está el hackmeeting estructurado
por grupos, ahora mismo y para éste año:
+ Grupo Local: Parece ser que ya hay un grupo local, un lugar y falta
una fecha. Además el grupo local está compuesto por gente que conoce el
hackmeeting, ha participado y sabe perfectamente como funciona. Por
tanto, éste año la parte parece bien organizada. ¿Me equivoco?.
http://sindominio.net/hackmeeting/wiki/Ka_La_Vila
+ Redacción: Bueno, pues poco a poco con éste grupo. Ya se va
redactando. No tengo claro quienes son las personas encargadas, pero no
hay mucha queja, salvo la falta de participación en la wiki. Quizás haya
que recordar que se puede editar de forma anónima. NOTA: poner
credenciales en algún sitio visible.
+ Diseño Gráfico: Éste grupo suele funcionar bien. De momento, ya hay
logo: http://sindominio.net/hackmeeting/wiki/2015
+ Difusión: Aquí he visto que hay quejas sobre el "tiempo" del año
pasado. Que no "daba tiempo" a difundir. Bueno, ahora que andamos con la
re-estructura es normal. De todas maneras, también se puede explicar.
"El hackmeeting de 2015 comienza su re-estructuración desde dentro".
Vamos, que hacerse eco de un evento que lleva muchos años no es
complicado. Así que se puede difundir todo cuanto se quiera, desde el
momento que se quiera. Salvo para cosas clave, como el llamamiento a las
charlas o al comienzo del pre-evento, el resto es cosa individual,
aunque deba ser etiquetada en lo colectivo.
+ Presupuestos: Sencillo. ¿Quién tiene la pasta, donde está la pasta y
cuanta pasta queda?. Con eso ya podemos presupuestar los gastos de ésta
edición.
+ Infraestructura: De momento, podemos dejar éste grupo en "stand-by"
hasta que debamos realizar la materialización del evento. Ahora bien,
obtener un inventario actualizado y plasmarlo en la wiki, parece lo
siguiente a realizar en éste tramo concreto.
+ Nodos: http://sindominio.net/hackmeeting/wiki/2015/Nodos
Por favor, demos un repaso a los nodos y seamos más serias y
consecuentes con la importancia de tener una receta atractiva. Sobre
todo, para las mismas culturas punk, cyborg, cypher, under, etc a las
que se desea llamar. Por ejemplo:
=============
HackNova 2015 - "HackActivistMeeting"
*hack*
[Evasion] [Malware] [Reversing] [HoneyPots] [Nvagadores] [DataLeak]
[DataMining] [Hardware Hacking] [Logging] [SLDC] [BCP/SGSI] [Exploting]
[0days] [SCADA/ICS] [Telefonía] [Radio] [Hacktivism] [Router hacking]
[Hardering] [Forense] [Vii]...
*activism*
[violación_de_Derechos_Fundamentales] [consumo_irracional]
[explotación_infantil] [inmobilismo_inculcado]
[destrucción_del_ecosistema] [falso_reciclaje] [no-privacidad]
[propiedad_intelectual] [patentes_del_conocimiento] [escasez_artifical]
[especulación] [leyes_no_éticas] [represión]
[intrusión_de_tecnologías_privativas] [guerra] [brecha_digital]
[fronteras] [centralización_de_canales] [manipulación_mediática]
[clasismo] [hambre] [censura] [precariedad] [esclavitud]
[autoritarismo_encubierto] [sexismo] [ignorancia_publicitada]
[fundamentalismo] [enseñanza_mal-versada] ...
*meeting*
[creando herramientas físicas y lógicas] [autogestionando servidores]
[modificando códigos sociales] [charlas y talleres] [conciertos, música
y entretenimiento] [pasión por el cambio] [revolución]...
----------------
Como podéis observar, es más sencillo hablar que contar ésto por correo.
Varios puntos importantes y mis opiniones, para terminar:
1 - ¿Permanencia en SinDominio?. SI, pues ambos proyectos son partes
de lo mismo.
2 - ¿Redes sociales?. NO (pero SI). Al menos con una cuenta de
@hackmeeting o similares que requiera mantenimiento. El hackmeeting debe
hacerse ver con los sentimientos y las etiquetas, no como entidad
propia. La gente hablará del #hackmeeting a través de sus simbologías y
no lo hará éste como unidad. Al menos, no veo que sea necesario aún, ni
creo que se solucione el tema de las redes sociales, comprometiendo a
gente que es probable se acabe cansando. Ahora bien. Si veo bien que se
creen grupos, categorías, etc, en las redes sociales libres, de manera
que se de visibilidad a las personas que lo componene, desmitificando
falsas esperanzas y cumpliendo con el ejemplo, de no usar redes contra
las cuales se tiene un esquema de contrapoder. Etiquetas:
#Hackmeeting2015 #HackNova15 #HMRevolutions
También puede ser interesante que el Hackmeeting tenga su propio nodo de
GNUSOcial. Éste además se puede conectar mediante "bridging" a otras
redes sociales en varias direcciones. Con la federación y la
distribución, también estarían siendo incluídas los perfiles de Lorea,
n-1, cabgrass, etc...
==================
Y algunos consejos de lobero:
1 - Respetad la netiqueta: RFC1855 (tools.ietf.org/html/rfc1855)
Aquí un ejemplo de como estructurar el "subject" de cualquier correo
antes de enviarlo:
-> [HM] [Grupo de trabajo] [Categoría de tema] Título
- [HM] automática de la propia lista
- [Grupo de trabajo] Ej: Comunicación, Tesorería, Sin grupo...
- [Categoría del tema] Ej: Pancartas, Presupuestos, Offtopic...
- Título Ej: Ya están terminadas la pancartas, los presupuestos
de las camisetas son, traidor también es quien cobija a traidores...
2 - No pensar que en que nos ofrece éste año el hackmeeting, sino en
que podemos ofrecer éste año al hackmeeting.
3 - Siempre críticas constructivas!
===================
Vamos peña, ánimo (nuestro único motor), inteligencia (nuestra única
arma), perserverancia (nuestra única verdad)... Ahora nos toca a
nosotras: https://www.youtube.com/watch?v=rMbATaj7Il8
Seguimos!!
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: 0xB8AC3776.asc
Type: application/pgp-keys
Size: 3287 bytes
Desc: no disponible
URL: </pipermail/hackmeeting/attachments/20150922/87c72ac8/attachment-0001.key>
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: </pipermail/hackmeeting/attachments/20150922/87c72ac8/attachment-0001.pgp>
Más información sobre la lista de distribución HackMeeting