[Py-ES] [pycones web ] Resumen reunión conceptualización web pycones

[Jesus Cea]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/01/13 16:46, Yamila Moreno Suárez wrote:
> - hemos definido un plan de acción sobre la web para el corto y
> medio plazo 1. Necesitamos una *lista de correos* en la que estén
> solo los interesados en la web, para no sobrecargar esta lista. Si
> no me equivoco, en esto nos puede ayudar Jesús Cea.

Decidme bajo qué dominio se montaría. Supongo que bajo
"lists.es.pycon.org". Ojo, Pycon y no Python.

Necesito saber si es una lista pública, quien la va a llevar, el
nombre de la lista, etc.

> 2. Andrey va a montar un *symposion básico. *Podemos sacar una
> versión muy básica que sólo pida email para suscribirse a la
> newsletter (donde avisaríamos de las actualizaciones de web por
> ejemplo), así empezamos a mover ya el tema de suscripciones.

Algo para mí absolutamente CRÍTICO es que una vez que se cierre la
PyConES, se pueda archivar de forma estática, para referencia futura.
Idealmente, webs como "2013.es.pycon.org" o
"historico.es.pycon.org/2013/" deberían quedar para la historia,
archivadas y funcionando "para siempre".

Lo que se haga "debe" ser volcable a estático con un simple "wget" o
similar. ¡Y todos los enlaces RELATIVOS!. Nada de base de datos o
software que no sea un simple servidor web sirviendo archivos estáticos.

Esto implica nada de chorradillas tipo 1996, como contadores de
visitas, la fecha y hora actual, etc (aunque la fecha y hora del
último cambio sí puede ser útil). Ojo si la web se sirve diferente
según el dispositivo (típica versión para móviles, etc).

Otra cosa muy deseable es que todo lo que se haga esté archivado bajo
control de versiones, como auditoría y "log" de lo que se hace, y para
aprendizaje de quien quiera verlo. No sé si es posible con la solución
elegida.

Algo deseable pero no imprescindible es que la web pudiese estar
funcionando de forma independiente en más de un server, para repartir
el curro, la responsabilidad y para poder continuar "si algo va mal"
(técnicamente tenerlo en dos sitios incrementa también el riesgo de
incidentes, pero es algo que debería valorarse técnicamente). De hecho
hay que definir un tema de backups y redundancia, aunque sea backups
diarios y redundancia "manual" (tirando del backup, levantar un nuevo
servidor en horas, a mano).

Yo documentaría TODO lo que se va haciendo y TODAS las
configuraciones. Ese trabajo es útil para otra gente, como aprendizaje
y para futuras ediciones. Y se puede colgar en la sección de
documentos de la asociación, en sphinx, como todo lo demás.

Andrey, pídeme un nombre bajo "es.pycon.org" para apuntar a tu
máquina. Si quieres ponerlo como web oficial ya, hablamos.

- -- 
Jesús Cea Avión                         _/_/      _/_/_/        _/_/_/
jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
.                              _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQCVAwUBUPGdmZlgi5GaxT1NAQJWfwP7Baii7tSeqHTo5vBAKFL6mC3tgqp/5RCS
1fk11ha4uvzYixmUikE9I9L7ni3oSeiscGg3Zs0Ly1/4aPHK+ErW8cEScZK0AmHw
+m3GcR7uMGwJCkK8A3p/9brk/clgEAkIkQfofxOahLvr3UsP3rRpRWgCAOnZgGq7
QiaZFdUYe9k=
=gQQu
-----END PGP SIGNATURE-----