[hm] [Core] [Organizaci�n] Teor�a estructural para el hackmeeting - 2015

[psy]

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>