respuesta a platonides

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

respuesta a platonides

Agustin Benito
Hola a todos,

en primer lugar, gracias por la objetividad.

>Message: 6
>Date: Tue, 16 May 2006 19:49:23 +0200
>From: Platonides <[hidden email]>
>Subject: Re: [Wikies-l] proyecto mEDUXa y wikipedia
>To: Lista de correo de Wikipedia en español     <[hidden email]>
>Message-ID: <004e01c67911$131b29b0$0501a8c0@Mula>
>Content-Type: text/plain; format=flowed; charset="iso-8859-1";
>        reply-type=original

>Dos consultas muy similares en un día :D
No es casualidad. Iba a realizar la consulta más adelante, pero al ver la
anterior...me he tirado a la piscina.


>Sobre el punto 1:
>"Durante el próximo curso escolar abrir una línea de trabajo (o potenciar
>una ya existente) encaminada a compatibilizar la documentación elaborada por
>este proyecto (Mediawiki) con la realizada por el equipo de documentación de
>KDE (Docbook)."
>Actualmente hay un 'programa' para convertir automáticamente código wiki a
>texto/DocBook/PDF/OpenDocument/XHTML en
>http://tools.wikimedia.de/~magnus/wiki2xml/w2x.php
Miraremos el programa. Gracias.

>¿Fomentamos un sistema a dos niveles, esto es, generar contenidos en
>nuestro Mediawiki "interno" y trasladarlos a la Wikipedia de una manera
>automatizada (habrá que ver cómo), o por el contrario promocionamos la
>inserción directa en Wikipedia de esos contenidos por parte de docentes y
>alumnos?
>El modo de trasladar los artículos sería fácil, mediante un bot. El problema
>es la sincronización. Un alumno puede hace runa pequeña mejora. Mientras
>tanto en wikipedia se ahce una gran mejora. Viene el bot y cambia por la
>versión poco mejorada. O a la inversa si tuviese preferencia el artículo de
>la wikipedia.
Existe algún documento sobre este bot?

>Se corre además el riesgo de provocar otra división (fork) de la wikipedia.
Habría que ser estricto en este punto para no convertirlo en un fork. Eso no
lo deseamos.

>El doble sistema que mencionáis tendría además otro inconveniente, que es la
>pérdida de los datos de los autores de las modificaciones, dando problemas
>con la GFDL.
Para muchos docentes y alumnos el hecho de que sus contribuciones lleven su
nombre, no cabe duda que es importante. La motivación es el principal
combustible de la colaboración. El reconocimiento para muchos es una gran
motivación. Sería un problema.

>Por esas razones sería mejor realizar una inserción directa en la wikipedia.
>Los alumnos deseosos de participar crearían sus cuentas y se identificarían
>como alumnos en sus páginas de usuario mediante alguna plantilla.

>Debido a la cuantía del proyecto supongo que contará con una serie de proxys
>web antes del acceso a internet. Debe configurarse de tal forma que el
>imapcto sea mínimo en caso de bloqueo por parte de la wikipedia (podría
>bloquearse el acceso antes de que nos avisaseies y lo levantásemos). Para
>ello dichos proxys deben tener correctamente configurada la cabecrea
>X-Forwarded-For.
Esto será una cuestión interesante. Hablamos de modificar las políticas de los
proxys del Gobierno de Canarias. Habrá que armarse de razones y convencer a
mucha gente, será una dura batalla.

>Posteriormente se configurarían desde aquí como proxys ''de  
>confianza''. Idealmente cada ordenador que se conectase a la wikipedia
>tendría una ip pública de internet de forma que el bloqueo afectaría
>solamente al terminal. Como esto lo veo bastante improbable, debería
>limitarse -al menos- de forma que el bloqueo sólo afectase a un centro. No a
>toda la comunidad autónoma.

No es posible realizar esa distinción. Tendríamos que establecer una
comunicación muy fluida y procedimientos engrasados para solventar este
problema.

>Desde el punto de vista opuesto, dicho acceso no valoraría los rangos
>profesor/alumno, siendo todos wikipedistas por igual.
Esto, en principio, para nosotros no es malo.
>Sin embargo, cualquier  
>wikipedista puede detectar y corregir la mayoría de vandalismos. El que los
>contenidos provenientes de dicha red no sean revisados antes de pasar a la
>wikipedia no es tampoco problema puesto que no es revisado ningún otro.
Siempre podemos distinguir a docentes y alumnos (de manera voluntaria), a
través del nombre de usuario (esto es una idea que se me ocurre mientras
escribo).

>Básicamente, no veo ningún inconveniente en un acceso directo a la
>wikipedia.

Trasladaré al resto del equipo estas consideraciones. Reitero mi
agradecimiento.

>Un saludo
>Platonides
--
Agustín Benito Bethencourt
[hidden email]
[hidden email]
www.grupocpd.com
www.agustinbenito.blogspot.com
_______________________________________________
Wikies-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikies-l
Reply | Threaded
Open this post in threaded view
|

Re: respuesta a platonides

Platonides

From: "eslic"
Sent: Wednesday, May 17, 2006 12:09 AM
Subject: [Wikies-l] respuesta a platonides


(...)

>>El modo de trasladar los artículos sería fácil, mediante un bot. El
>>problema
>>es la sincronización. Un alumno puede hace runa pequeña mejora. Mientras
>>tanto en wikipedia se ahce una gran mejora. Viene el bot y cambia por la
>>versión poco mejorada. O a la inversa si tuviese preferencia el artículo
>>de
>>la wikipedia.
>Existe algún documento sobre este bot?
No sé si actualmente hay algún bot que haga eso, pero sería sencillo de
hacer. El problema, como ya comenté, es la integración de los contenidos.
Porque tener a una persona revisando los conflictos tampoco es mucho plan...

>>Se corre además el riesgo de provocar otra división (fork) de la
>>wikipedia.
>Habría que ser estricto en este punto para no convertirlo en un fork. Eso
>no lo deseamos.

>>El doble sistema que mencionáis tendría además otro inconveniente, que es
>>la
>>pérdida de los datos de los autores de las modificaciones, dando problemas
>>con la GFDL.
>Para muchos docentes y alumnos el hecho de que sus contribuciones lleven su
>nombre, no cabe duda que es importante. La motivación es el principal
>combustible de la colaboración. El reconocimiento para muchos es una gran
>motivación. Sería un problema.

(...)

>>Debido a la cuantía del proyecto supongo que contará con una serie de
>>proxys
>>web antes del acceso a internet. Debe configurarse de tal forma que el
>>imapcto sea mínimo en caso de bloqueo por parte de la wikipedia (podría
>>bloquearse el acceso antes de que nos avisaseis y lo levantásemos). Para
>>ello dichos proxys deben tener correctamente configurada la cabecrea
>>X-Forwarded-For.
>Esto será una cuestión interesante. Hablamos de modificar las políticas de
>los
>proxys del Gobierno de Canarias. Habrá que armarse de razones y convencer a
>mucha gente, será una dura batalla.
Dicha cabecera es _bastante estándar_, no debería haber problemas con que
estuviese presente. De hecho, es posible que ya estén configurados con ella.

>>Posteriormente se configurarían desde aquí como proxys ''de
>>confianza''. Idealmente cada ordenador que se conectase a la wikipedia
>>tendría una ip pública de internet de forma que el bloqueo afectaría
>>solamente al terminal. Como esto lo veo bastante improbable, debería
>>limitarse -al menos- de forma que el bloqueo sólo afectase a un centro. No
>>a
>>toda la comunidad autónoma.

>No es posible realizar esa distinción. Tendríamos que establecer una
>comunicación muy fluida y procedimientos engrasados para solventar este
>problema.
Si, es algo dificil de lograr. Sin embargo el problema de bloquear a gran
cantidad de la red educativa debido a un vándalo que puede no ser siquiera
del centro, está ahí.

(...)

>Trasladaré al resto del equipo estas consideraciones. Reitero mi
>agradecimiento.
De nada

_______________________________________________
Wikies-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikies-l
Reply | Threaded
Open this post in threaded view
|

Proyectos verimas y mEDUXa y

eierkopf celan
Creo que ambos proyectos son estupendos y ayudarán
tanto a la la wikipedia como a los alumnos.

Sin embargo creo que, en ambos proyectos, se debería
hacer una diferenciación entre el acceso de docentes,
padres, etc. y el de alumnos. De momento tenemos
problemas en la wikipedia para controlar el vandalismo
y si de repente entra la población escolar de Canarias
y parte del de la Península, vamos a vernos
desbordados.

Tener a niños/adolescentes aislados en la wiki no es
problema, tener un colegio entero creo que sí.
Veríamos como la sociología del patio de recreo se
traslada a la wikipedia con el agravante del
anonimato. Ni siquiera ayudaría cerrar un terminal: no
hay más que sentarse en el próximo. Además, si los
niños no pueden acceder desde la escuela, si tienen
interés y quieren editar, siempre podrán hacerlo desde
casa o desde la biblioteca.

Es una opinión. Saludos, Ecelan


               
______________________________________________
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com
_______________________________________________
Wikies-l mailing list
[hidden email]
http://mail.wikipedia.org/mailman/listinfo/wikies-l