Comenzando el proyecto de la comunidad hispana de Symfony

[Javier Eguiluz]

Hola a todos/as,

Como muchos ya habéis comentado, antes de poder comenzar a desarrollar
el proyecto tenemos que ponernos de acuerdo en al menos 3 cosas:
nombre de la aplicación, herramienta que vamos a utilizar para
coordinarnos (es decir, un gestor de proyectos) y si necesitamos o no
un coordinador.

Como esta será una de las últimas discusiones sobre este tema en este
grupo y pronto podremos seguir las conversaciones en otra herramienta/
aplicación, propongo que todas las propuestas se hagan como respuesta
a este mensaje.

Para abrir fuego, añado aquí mis propias propuestas:

1) Nombre: como soy malísimo escogiendo el nombre de las cosas, sólo
tengo "sfbasecamp" (que realmente se le ocurrió a un usuario de este
grupo, pero ahora mismo no recuerdo quién) y "CampoBase" (puestos a
clonar, clonamos hasta el nombre!!).

2) Herramienta para coordinarnos: un usuario de este grupo ha
proporcionado el enlace a una tabla comparativa de este tipo de
herramientas http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities

De todas ellas me quedaría con Assembla (http://www.assembla.com) que
la han recomendado varios usuarios y en su versión gratuita ofrece 500
MB de almacenamiento, posibilidad de adjuntar archivos, wiki, listas
de tareas, hitos, repositorios Subversion y Git, alertas por email,
chat, informes, "time tracking", número ilimitado de usuarios y
también dispone de Trac.

3) Por último, creo que si sería conveniente una persona que
coordinara el trabajo cuando hiciera falta. Sin embargo, para que el
desarrollo sea fluido y podamos conseguir nuestro objetivo, creo que
las condiciones que tiene que cumplir esa persona son al menos las
siguientes:
a) Que no sea un dictador y no diga a nadie lo que tiene que hacer.
b) Que se limite a coordinar cuando haga falta y a no hacerlo cuando
no sea necesario.
c) Que su voto valga lo mismo que el de cualquier otro, incluso en
caso de empate.
d) Que su nombre no aparezca destacado de ninguna forma ni tenga más
relevancia que cualquier otro usuario activo del proyecto.
e) Todo se puede resumir en "que sea uno más".

Respecto a la persona que podría ser el coordinador, he visto que en
otro hilo proponían mi nombre. Agradezco la propuesta porque es algo
que realmente me gustaría, pero debemos elegir con más cuidado. Me
explico: tengo experiencia coordinando grupos de trabajo, pero NO
tengo MUCHA experiencia haciéndolo.

Así que por favor, cualquier persona que tenga experiencia en tareas
similares y tenga ganas/tiempo de hacerlo, que proponga su nombre para
que podamos elegir entre todos los candidatos. Por supuesto también
puede autoproponerse cualquier persona aunque no tenga experiencia.

Un saludo,
Javier Eguiluz
www.symfony.es

[KNO]

Estoy de acuerdo en todos los puntos. Y como no tenemos una
herramienta mejor para votar (de momento, espero que asamblada la
tenga y si no, la implementaremos en sfCampoBase) voto aquí:
1.- Nombre: sfCampoBase (Si, castellanizado y todo)
2.- Asamblada (no conozco otros, asi que me fío del:
3.- Coordinador: Javier Eguiluz. Lo propongo como coordinador inicial
sobre todo por la iniciativa que ha demostrado. Si durante la andadura
alguien quiere asumir la coordinación del grupo estaré encantado de
que se haga una votación.

Añado una cosa que Javier ha dado por supuesta:
4.- Funcionamiento democrático: Esto es un poco controvertido: ¿va a
participar en la decisiones gente que no va a participar en el
proyecto? ¿Solo la gente que esté dada de alta en asamblada (o en la
herramienta que finalmente utilicemos)? ¿Y si me doy de alta solo para
votar y no para participar, o doy de alta varias cuentas para tener
varios votos?¿Se tomarán decisiones por grupo de trabajo (me imagino
que se harán grupos de trabajo entorno a tareas o módulos, pero es
mucho imaginar)?
Creo que no es una decisión trivial, que las cosas comienzan muy bien
pero sin unas bases firmes para el grupo de trabajo podrían surgir
incomodidades después. Yo voto por tomar esta decisión dentro de los
participantes de la lista, tal como se hizo para elegir el proyecto y
las demás características, dando un plazo para que todo el que lo
desee pueda expresar su opinión.

Espero que todas estas decisiones se tomen cuanto antes, para poder
empezar a trabajar enseguida y ver resultados pronto que es lo que a
todos nos gusta.

Un Saludo,

kNo

El día 2 de julio de 2008 12:25, Javier Eguiluz
<javier....@gmail.com> escribió:

[meigallo]

El 02/07/2008, a las 12:54, KNO escribió:

Estoy de acuerdo en todos los puntos. Y como no tenemos una
herramienta mejor para votar (de momento, espero que asamblada la
tenga y si no, la implementaremos en sfCampoBase) voto aquí:
1.- Nombre: sfCampoBase (Si, castellanizado y todo)
2.- Asamblada (no conozco otros, asi que me fío del:
3.- Coordinador: Javier Eguiluz. Lo propongo como coordinador inicial
sobre todo por la iniciativa que ha demostrado. Si durante la andadura
alguien quiere asumir la coordinación del grupo estaré encantado de
que se haga una votación.

Coincido en los tres puntos.

Añado una cosa que Javier ha dado por supuesta:
4.- Funcionamiento democrático: Esto es un poco controvertido: ¿va a
participar en la decisiones gente que no va a participar en el
proyecto? ¿Solo la gente que esté dada de alta en asamblada (o en la
herramienta que finalmente utilicemos)? ¿Y si me doy de alta solo para
votar y no para participar, o doy de alta varias cuentas para tener
varios votos?¿Se tomarán decisiones por grupo de trabajo (me imagino
que se harán grupos de trabajo entorno a tareas o módulos, pero es
mucho imaginar)?
Creo que no es una decisión trivial, que las cosas comienzan muy bien
pero sin unas bases firmes para el grupo de trabajo podrían surgir
incomodidades después. Yo voto por tomar esta decisión dentro de los
participantes de la lista, tal como se hizo para elegir el proyecto y
las demás características, dando un plazo para que todo el que lo
desee pueda expresar su opinión.

Si es software libre, y se plantea así, realmente cualquiera debería poder dar su opinión, y si se crea varias cuentas ... ya sabemos que hay gente para todo. Por otro lado que sea soft libre no implica que no hay un core que tome decisiones basándose en las propuestas de la comunidad, véase freebsd por poner un ejemplo. Lo que está claro que yo puedo tener una opinión pero con dos semanas de uso de symfony puede ser equivocada, y la experiencia que tenéis algunos debiera pesar, por muy democrático que sea el tema.

[Pedro]

Estoy de acuerdo con todo, excepto con el nombre, creo que deberiamos
tener un nombre mas propio y no algo que se asemeje a BaseCamp, para
evitar cualquier tipo de problemas que pueda representar para algunos
o no. Puede ser algo tan sencillo como sfProyecto si lo queremos en
español.

Salu2,
Pedro

> > <javier.egui...@gmail.com> escribió:

>
> >> Hola a todos/as,
>
> >> Como muchos ya habéis comentado, antes de poder comenzar a  
> >> desarrollar
> >> el proyecto tenemos que ponernos de acuerdo en al menos 3 cosas:
> >> nombre de la aplicación, herramienta que vamos a utilizar para
> >> coordinarnos (es decir, un gestor de proyectos) y si necesitamos o no
> >> un coordinador.
>
> >> Como esta será una de las últimas discusiones sobre este tema en este
> >> grupo y pronto podremos seguir las conversaciones en otra  
> >> herramienta/
> >> aplicación, propongo que todas las propuestas se hagan como respuesta
> >> a este mensaje.
>
> >> Para abrir fuego, añado aquí mis propias propuestas:
>
> >> 1) Nombre: como soy malísimo escogiendo el nombre de las cosas, sólo
> >> tengo "sfbasecamp" (que realmente se le ocurrió a un usuario de este
> >> grupo, pero ahora mismo no recuerdo quién) y "CampoBase" (puestos a
> >> clonar, clonamos hasta el nombre!!).
>
> >> 2) Herramienta para coordinarnos: un usuario de este grupo ha
> >> proporcionado el enlace a una tabla comparativa de este tipo de

> >> herramientashttp://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosti...

[Ricardo Pulgarín Gómez]

Hola

1) sfBootCamp (campo de entrenamiento SF)
2) http://www.assembla.com
3) Yo creo que esto es tan grande que para un solo coordinador es complicado manejar todo, porque tocaría sacar mucho tiempo para estar pendiente, para la muestra seguirle el hilo a las discusiones solo del este foro es bastante.

Creo que deberíamos armar los departamentos, y coordinadores de áreas, así, el trabajo también se vuelve distribuido un poco y aliviamos cargas.

éxitos.

--
Ricardo Pulgarín Gómez
Ing. de Sistemas y Telecomunicaciones
www.darsoftware.net
GNU/Linux user #348190

[josx]

El Wednesday 02 July 2008 07:25:10 Javier Eguiluz escribió:
> Hola a todos/as,
>
> Como muchos ya habéis comentado, antes de poder comenzar a desarrollar
> el proyecto tenemos que ponernos de acuerdo en al menos 3 cosas:
> nombre de la aplicación, herramienta que vamos a utilizar para
> coordinarnos (es decir, un gestor de proyectos) y si necesitamos o no
> un coordinador.

Si lo necesitariamos.
Como también necesitamos saber exactamente como va a ser el sistema antes de
empezar a trabajar.

> Como esta será una de las últimas discusiones sobre este tema en este
> grupo y pronto podremos seguir las conversaciones en otra herramienta/
> aplicación, propongo que todas las propuestas se hagan como respuesta
> a este mensaje.
>
> Para abrir fuego, añado aquí mis propias propuestas:
>
> 1) Nombre: como soy malísimo escogiendo el nombre de las cosas, sólo
> tengo "sfbasecamp" (que realmente se le ocurrió a un usuario de este
> grupo, pero ahora mismo no recuerdo quién) y "CampoBase" (puestos a
> clonar, clonamos hasta el nombre!!).

Es mejor idea no clonar nombres sino crear uno propio.

> 2) Herramienta para coordinarnos: un usuario de este grupo ha
> proporcionado el enlace a una tabla comparativa de este tipo de
> herramientas
> http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_fac
>ilities
>
> De todas ellas me quedaría con Assembla (http://www.assembla.com) que
> la han recomendado varios usuarios y en su versión gratuita ofrece 500
> MB de almacenamiento, posibilidad de adjuntar archivos, wiki, listas
> de tareas, hitos, repositorios Subversion y Git, alertas por email,
> chat, informes, "time tracking", número ilimitado de usuarios y
> también dispone de Trac.

Estos usando assembla para otros proyectos y es realmente genial.
Tiene todo lo necesario para poder desarrollar.
Eso si todos se tienen que acostumbrar a utilizar TRAC, SVN, etc.

Algo importante además es decidir que licencia le pondremos al sotfware y a la
documentación. Lo digo por que me parece un tema determinante para el aporte.
Por ejemplo si ambas no son libres yo no participo.
Propongo para el software tener una licencia GPL y para la documentación
CC-BY-SA

--
Di Biase José Luis
Blog --> [http://www.joseluisdibiase.com.ar]
"viaja hasta tu ideal, sembra tu flor, labra tu libertad, rega tu voz
cerra tus ojos que sobra lugar en idilia para los dos"

[Damian Suarez]

1) sfCampoBase
2) ni idea
3) Un coordinar general, y un coordinar de aŕea; se puede separa siguiendo el patron MVC (uno para el trabajo sobre el modelo, otro el control y otro la vista).

2008/7/2 josx <jo...@interorganic.com.ar>:

--
www.XiFOX.net

[pablodip]

Creo que no tenemos que ceñirnos a hacer un clon de... sino a hacer
algo basándonos en las mejores ideas que existen sobre ello, pero por
supuesto intentar mejorarlo, que es al fin y al cabo lo que hace
symfony.

Añado unas ideas para el nombre con los dominios que tienen libres y
podrían interesarnos, que no estaría de mal registrar el que elijamos,
para poder poner el proyecto.

plaanes .com .org
proojects .org
projectes .com .org
orpros .com .org (organizar proyectos)
eurochoes .com .org (eurocopa 2008 :P)
pr.oject.us
whitoues .com .org (casa blanca, que es donde más se organiza del
mundo)
symplan .org
planfony .com .org

A mi personalmente el que más me gusta es plaanes, ya que es fácil de
recordar y le da un toque español y el tema de la doble a le puede dar
mucho juego como en google.
Aún así si no convencen podemos intentar sacar más :D

Para el hosting me parece bien también que se use assembla, alguno hay
que usar para empezar y ese es gratis y tiene muy buena pinta.

Sobre el funcionamiento democrático discrepo algo también,
principalmente por los motivos que comenta KNO. No he participado
activamente en proyectos de software libre (aún :P), pero he estado
buscando algo sobre el sistema de organización y se suele usar más la
meritocracia.
Cada proyecto tiene sus normas sobre la meritocracia, y al empezar
esta claro que serán mucho más abiertas para que avance el proyecto,
asi que una vez tengamos hosting... habría que poner unos requisitos
para participar? habría que elaborar una lista de participantes
iniciales y a partir de ahí funcionar más con meritocracia?

Asi que para organizador voto también por Javier Eguiluz, basándome en
la meritocrácia :D

Para la licencia voto también por GPL.

Saludos!

On 2 jul, 16:26, josx <j...@interorganic.com.ar> wrote:
> El Wednesday 02 July 2008 07:25:10 Javier Eguiluz escribió:
>
> > Hola a todos/as,
>
> > Como muchos ya habéis comentado, antes de poder comenzar a desarrollar
> > el proyecto tenemos que ponernos de acuerdo en al menos 3 cosas:
> > nombre de la aplicación, herramienta que vamos a utilizar para
> > coordinarnos (es decir, un gestor de proyectos) y si necesitamos o no
> > un coordinador.
>
> Si lo necesitariamos.
> Como también necesitamos saber exactamente como va a ser el sistema antes de
> empezar a trabajar.
>
> > Como esta será una de las últimas discusiones sobre este tema en este
> > grupo y pronto podremos seguir las conversaciones en otra herramienta/
> > aplicación, propongo que todas las propuestas se hagan como respuesta
> > a este mensaje.
>
> > Para abrir fuego, añado aquí mis propias propuestas:
>
> > 1) Nombre: como soy malísimo escogiendo el nombre de las cosas, sólo
> > tengo "sfbasecamp" (que realmente se le ocurrió a un usuario de este
> > grupo, pero ahora mismo no recuerdo quién) y "CampoBase" (puestos a
> > clonar, clonamos hasta el nombre!!).
>
> Es mejor idea no clonar nombres sino crear uno propio.
>
> > 2) Herramienta para coordinarnos: un usuario de este grupo ha
> > proporcionado el enlace a una tabla comparativa de este tipo de
> > herramientas

> >http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosti...

[meigallo]

por dios gpl no, la licencia libre menos libre, ya que obliga ... una
bsd like please ...

[Julio Rene Herrera Vega]

On 7/2/08, KNO <lin...@gmail.com> wrote:
>
> Estoy de acuerdo en todos los puntos. Y como no tenemos una
> herramienta mejor para votar (de momento, espero que asamblada la
> tenga y si no, la implementaremos en sfCampoBase) voto aquí:
> 1.- Nombre: sfCampoBase (Si, castellanizado y todo)

Lo de castellano o ingles me importa poco ya que estamos tan
acostumbrados a ambos lenguajes y los usamos tanto que ser tan
patriota en este momento no ayuda a popularizar el desarrollo,
queramos o no el ingles es mas universal o por lo menos hay mas
personas interesadas en apreender y lo mas probable que si esto nos
sale bien el nombre debe ser pegajozo o facil, voto por sfbasecamp o
algo parecido.

> 2.- Asamblada (no conozco otros, asi que me fío del:

No lo conozco pero si lo recomiendan voto por el.

> 3.- Coordinador: Javier Eguiluz. Lo propongo como coordinador inicial
> sobre todo por la iniciativa que ha demostrado. Si durante la andadura
> alguien quiere asumir la coordinación del grupo estaré encantado de
> que se haga una votación.

Si Javier es el que reune mas simpatia tambien Voto por el , pero
como comentaron ampliaria un poco el espectro a unos cuantos mas para
que no sea pesado para el:

Divide y venceras
El que mucho abarca poco aprieta

>
> Añado una cosa que Javier ha dado por supuesta:
> 4.- Funcionamiento democrático: Esto es un poco controvertido: ¿va a
> participar en la decisiones gente que no va a participar en el
> proyecto? ¿Solo la gente que esté dada de alta en asamblada (o en la
> herramienta que finalmente utilicemos)? ¿Y si me doy de alta solo para
> votar y no para participar, o doy de alta varias cuentas para tener
> varios votos?¿Se tomarán decisiones por grupo de trabajo (me imagino
> que se harán grupos de trabajo entorno a tareas o módulos, pero es
> mucho imaginar)?
> Creo que no es una decisión trivial, que las cosas comienzan muy bien
> pero sin unas bases firmes para el grupo de trabajo podrían surgir
> incomodidades después. Yo voto por tomar esta decisión dentro de los
> participantes de la lista, tal como se hizo para elegir el proyecto y
> las demás características, dando un plazo para que todo el que lo
> desee pueda expresar su opinión.

Voto por el que sea mas popular como forma de decision.

>
> Espero que todas estas decisiones se tomen cuanto antes, para poder
> empezar a trabajar enseguida y ver resultados pronto que es lo que a
> todos nos gusta.
>
> Un Saludo,
>
> kNo
>

Saludos

-------------
Julio Herrera
Santiago
Chile

[Javier Eguiluz]

Para aclarar algunas cosas:

1) Uno o varios coordinadores:
Efectivamente el proyecto no va a tener 1 solo coordinador porque sería contraproducente y justo lo contrario que queríamos todos. El coordinador simplemente serviría por ejemplo para dar de alta el proyecto en assembla.com o donde se decida, para animar el desarrollo de la aplicación, etc.

Sin embargo, el proyecto se dividirá en decenas de tareas y cada uno trabajará en lo que le guste y le apetezca. El proyecto se autogestionará solo en la medida de lo posible y el coordinador intentará que su trabajo sea prácticamente nulo.

2) Meritocracia:
Estoy totalmente en contra de montar algo parecido a una meritocracia y crear "castas" o "clases". No me gusta la idea de "usuarios superiores". Aunque a veces es injusto, yo votaría por una democracia en la que cualquiera con ganas de participar de forma activa tenga el mismo peso que cualquier otra persona.

Por eso comentaba antes que también el voto del coordinador debería valer lo mismo que el de los demás, incluso en caso de empate.

3) Licencias y demás:
Ese tipo de cosas es lo que tenemos que aclarar cuanto antes...pero para eso necesitamos la herramienta para coordinarnos...y para eso necesitamos el nombre del proyecto. Precisamente por eso hemos creado este nuevo hilo de discusión.

Ya que muchos habéis comentado vuestras preferencias sobre licencias, yo elegiría las mismas licencias que Symfony: MIT para el software y GFDL para la documentación.

Un saludo,
Javier Eguiluz
www.symfony.es

2008/7/2 Julio Rene Herrera Vega <jul...@gmail.com>:

[satrapa]

Hola,

Me ha costado ponerme al día ;) pero tambien me apunto al proyecto.

1) Nombre: Deberia empezar con sf, ¿no?

2) Herramienta: De assembla nadie habla mal :-D

3) Coordinador: De acuerdo en que tiene que haber democracia, pero hay
decisiones que debe tomar un equipo principal o "core" como alguien
comentaba anteriormente. Si ponemos a una persona como coordinador a
escuchar a todo el mundo opinar sobre todo sólo vamos a quemarlo (por
todo el trabajo que conlleva). Creo que tendríamos que hacer grupos
con un delegado por grupo y todos los delegados serian el "core".
Despues cada grupo usaría los métodos democráticos para organizarse
internamente pero en cosas mucho más concretas y relacionadas con el
trabajo asignado. El problema es la elección de ese "core" pero yo
creo que se va a ver fácilmente en los próximos días según esto vaya
avanzando quien quiere/puede ser del equipo titular.

4) Sobre el desarrollo propiamente dicho, aconsejo leer:
http://gettingreal.37signals.com/toc.php Creo que además de clonar las
funcionalidades de BaseCamp (que está bien y realmente es lo que
queremos hacer) tendríamos sobretodo que clonar la filosofía. Es
decir, menos es más. Centrarnos en una cosa sencilla y hacerla pronto.
Y luego añadirle más extras. Tenemos que pensar en qué es lo más
importante del gestor de proyectos. Propongo empezar a desarrollar
sólo el gestor de usuarios, el gestor de proyectos (alta, baja,
modificación de proyectos) y el gestor de tareas. Todo lo demás
(calendario, timetracking, etc...) lo tendremos en cuenta pero ya
llegará. A la vista de esto, tendríamos podríamos tenter 4 grupos, y
ya tendríamos 4 delegados. El cuarto grupo es el de documentación.

5) Por supuesto, voto por licencia lo más libre posible, sino no tiene
sentido hacer nada (ya existe basecamp) ;-)

Un saludo de
Minaya

[pablodip]

> 2) Meritocracia:
> Estoy totalmente en contra de montar algo parecido a una meritocracia y
> crear "castas" o "clases". No me gusta la idea de "usuarios superiores".
> Aunque a veces es injusto, yo votaría por una democracia en la que
> cualquiera con ganas de participar de forma activa tenga el mismo peso que
> cualquier otra persona.
>

> Por eso comentaba antes que también el voto del coordinador debería valer lo
> mismo que el de los demás, incluso en caso de empate.

Todos queremos montar el proyecto lo más abierto y libre posible, pero
en esto creo que también tiene que haber unas limitaciones, sino por
ejemplo cosas como las que comenta KNO no funcionarían bien:
- ¿va a participar en la decisiones gente que no va a participar en el
proyecto?
- ¿Solo la gente que esté dada de alta en asamblada (o en
laherramienta que finalmente utilicemos)?
- ¿Y si me doy de alta solo para votar y no para participar, o doy de

alta varias cuentas para tener varios votos?

- ¿Se tomarán decisiones por grupo de trabajo (me imagino que se harán

grupos de trabajo entorno a tareas o módulos, pero es mucho imaginar)?

> 1) Nombre: Deberia empezar con sf, ¿no?

A mi no me parece necesario, me gusta más la originalidad, pero como
se decida en... demo-meritocracia :D

> 3) Coordinador: De acuerdo en que tiene que haber democracia, pero hay
> decisiones que debe tomar un equipo principal o "core" como alguien
> comentaba anteriormente. Si ponemos a una persona como coordinador a
> escuchar a todo el mundo opinar sobre todo sólo vamos a quemarlo (por
> todo el trabajo que conlleva). Creo que tendríamos que hacer grupos
> con un delegado por grupo y todos los delegados serian el "core".
> Despues cada grupo usaría los métodos democráticos para organizarse
> internamente pero en cosas mucho más concretas y relacionadas con el
> trabajo asignado. El problema es la elección de ese "core" pero yo
> creo que se va a ver fácilmente en los próximos días según esto vaya
> avanzando quien quiere/puede ser del equipo titular.

Exacto, tampoco hay que tomar a rajatabla la democracia o
meritocracia, sino en democracia cualquiera podría participar y por
consiguiente boicotear el proyecto, y en meritocracia aislarse tanto
que no avance, sólo hay que buscar el término medio :)

Saludos!

On 2 jul, 17:42, satrapa <satr...@gmail.com> wrote:
> Hola,
>
> Me ha costado ponerme al día ;) pero tambien me apunto al proyecto.
>
> 1) Nombre: Deberia empezar con sf, ¿no?
>
> 2) Herramienta: De assembla nadie habla mal :-D
>
> 3) Coordinador: De acuerdo en que tiene que haber democracia, pero hay
> decisiones que debe tomar un equipo principal o "core" como alguien
> comentaba anteriormente. Si ponemos a una persona como coordinador a
> escuchar a todo el mundo opinar sobre todo sólo vamos a quemarlo (por
> todo el trabajo que conlleva). Creo que tendríamos que hacer grupos
> con un delegado por grupo y todos los delegados serian el "core".
> Despues cada grupo usaría los métodos democráticos para organizarse
> internamente pero en cosas mucho más concretas y relacionadas con el
> trabajo asignado. El problema es la elección de ese "core" pero yo
> creo que se va a ver fácilmente en los próximos días según esto vaya
> avanzando quien quiere/puede ser del equipo titular.
>

> 4) Sobre el desarrollo propiamente dicho, aconsejo leer:http://gettingreal.37signals.com/toc.phpCreo que además de clonar las

[rDeeb]

Pienso, y por ser mi area de experiencia que si queremos dara a
conocer Symfony, y la comunidad hispana de SF, debemos empezar por
donde se comienza un proyecto. Por el mercadeo, definir los
requerimientos, definir nombre (el cual para nada debe ser una copia),
definir funcionalidades... etc. Como experiencia muchos proyectos
Open Source pueden ser muy buenos y muy apreciados por la comunidad,
pero no muy bien visto por el publico fuera de la comunidad. Pero yo
creo que un proyecto como este, tiene como principal funcion,
permitirles a los encargados de IT/Desarrollo convencer a sus jefes
que aman frameworks comerciales lentos (y por esto me refiero a .Net),
de que Symfony es una buena opcion. Esto puede como progamadores que
somos no parecerles correcto o algo secundario. Pero se los digo, yo
trabajo en una empresa transnacional tan amarrada a .Net que el solo
hecho de mencionar Firefox es motivo de pelea (Si existen personas que
defienden el IE6). A estas personas es a las que tenmos que llegarles,
pero no con jerga tecnica, si no con un buen proyecto, en un lenguaje
que ellos entiendan, con metricas... cuantas lineas de codigo y tiempo
hubiera llevado en .Net, y cuanto tiempo y lineas de codigo nos tomo,
cuanto gastamos en licencias para q todos desarrollaramos (ya tenemos
la respuesta, si desarrollan en linux como yo... NADA), y cuanto nos
hubiera costado a cada uno tener el Visual Studio, mas la licencia
comercial y el SQL server en cada maquina. Estas son las cosas con las
cuales convencemos a la gente que eta alla afuera de que nuestra
solucion compite con las grandes alternativas (Acordarle que tenemos
el respaldo de Yahoo!).

Adicional debemos incluir a expertos en IA/UX (Information
Architects / User Experience) para que juntos desarrollemos en base a
una sola premisa la experiencia del usuario, ya que el usuario no
aprecia la belleza del codigo del lado del servidor, si no que valora
una aplicacion por como se ve y que tan facil de utilizar es.

Tengo un compañero que puede apoyar en el ultimo punto y por mi
trabajo y estudios puedo apoyar en el primero y en la programacion.
Amo este framework tanto que me gustaria llevarlo a todos lados, por
eso creo en este tipo de proyecto y creo que debemos hacerlo bien
desde el inicio.

[Neonard0]

Bueno debo decir, que estoy muy alegre de ver el compromiso que todos
estamos teniendo con el proyecto. mis "votos"

1) symplan (Hice un pequeño sondeo y pego mucho, y lo que primero se
viene a la mente es , simple, plan, y para los que usan symfony, pues
symfony. Me agrada mucho, pero mucho este nombre, que buena
imaginacion Pablo.)
2) http://www.assembla.com (Ni idea pero confio en los demas)
3) Coordinador Javier Eguiluz (de hecho ya lo esta haciendo desde
hace mucho, y no lo hace nada mal)
4) licencia. MIT... las mismas que usa symfony.

@satrapa
"# 1) Nombre: Deberia empezar con sf, ¿no?"

no necesariamente, si revisas los plugins de yahoo, no empiezan con
sf, sino ysf, hay otro con ck.
Bueno despues durante la implementacion y se desarrollara como plugins
podria ser sfSymplan.

PD: Yo propuse el nombre sfBaseCamp, pero creo que no deberia llamarse
asi , por que lo que vamos a desarrollar va a ser mucho mejor que
basecamp, eso seria rebajarnos. jaja XD

On 2 jul, 11:15, rDeeb <blackang...@gmail.com> wrote:

[Pedro]

De acuerdo con Neonard0

1) symplan (bien por Pablo)
2) http://www.assembla.com
3) Coordinador Javier Eguiluz
4) licencia. MIT... (Symfony)

[Banyú]

De acuerdo con Pedro y Neonard0. Tras leer el hilo entero las respuestas 2, 3 y 4 me parecen las opciones más razonables. Respecto al punto número 1, me gusta symplan, pero no especialmente más que cualquier de los otros que se han mencionado. Realmente pienso que el nombre es lo de menos, y que sólo la calidad del producto hará que el mismo parezca adecuado a la vista de los usuarios.

Saludos.

2008/7/2 Pedro <plma...@gmail.com>:

--
____________________

Banyú

bany...@gmail.com
http://banyuken.es
616 20 50 62
____________________

[satrapa]

2008/7/2 Neonard0 <patoj...@gmail.com>:

>
> @satrapa
> "# 1) Nombre: Deberia empezar con sf, ¿no?"
>
> no necesariamente, si revisas los plugins de yahoo, no empiezan con
> sf, sino ysf, hay otro con ck.
> Bueno despues durante la implementacion y se desarrollara como plugins
> podria ser sfSymplan.

Aclarar que no creo que sea necesario. Sólo era una sugerencia porque
me parece que es interesante. No deja de ser un proyecto de apoyo a
symfony, y el "sf" me parece bastante identificativo. Cualquiera que
use la aplicación podría preguntarse de dónde viene ese "sf". Pero
está claro que no es necesario. El mismo BaseCamp sirvió para
popularizar rubyonrails y en su nombre no tienen referencias a RoR.

Un Saludo de
Minaya

[Fonsi82]

Hola ! mi primer mensaje al respecto. He estado leyendo los hilos
relacionados.
Quiero decir que no tengo experiencia en desarrollo OpenSource. Y me
gustaría participar en la medida que pueda. Os comento mi opinión
sobre los puntos que se están trando.

1)Sobre el nombre:
¿qué empieze por Sf ?¿por qué? askeet no empieza por Sf .
Creo que alguien lo dijo con la intención de que se convierta en un
plugín.
¿Realmente tiene utilidad, meter un gestor de proyectos como plugin en
cada proyecto symfony? Corregirme si me equivoco.
Yo primero desarrollaría un proyecto con vida propia con su inicio y
fin que pueda ser desarrollado en 30 días de tutorial (29 si se quiere
hacer la competencia ;P ) .
Similar a Askeet en cuanto a autonomía y le llamaría SimpleManager
(por ejemplo)
El resultado sería un demo-site como askeet.com, podría ser www.SimpleManager.es

Después una vez cubierto el pimer objetivo se podría hacer un plugin
SfSimpleManager.
El plugin lo meterías en cualquier proyecto symfony para que se
comunicara con el SimpleManager.
De esa manera tendría utilidad de administrar y mantener varios
proyectos que tengas en tu localhost.
Ejemplo :
Supongamos que tienes en tu localhost los siguientes proyectos symfony
/SimpleManager
/VideoClupPepe.com

De alguna manera SimpleManager pudiera leer los modulos que tiene
VideoClupPepe , de modo que si dentro de VideoClubPepe creas un nuevo
modulo 'peliculas' al entrar al SimpleManager proyecto VideoClubPepe
pudieras ver que existe ese modulo y ya asignarle tiempo
horas ,recursos, notas ..etc..

El plugin se me ocurre que podría actuar de la siguiente manera,
ejemplo:
Instalamos el plugin SfSimpleManager en el proyecto VideoClubPepe.
Entonces en la vista de Debug VideoClubPepe.com/frontend_dev.php
pudieramos acceder a la lista de tareas pendientes definidas en
SimpleManger en función de en que modulo/acción estemos.

Alomejor estoy mezclando la velocidad con el tocino.. corregirme
porfavor.


2) sobre la licencia, lo más lógico sería usar la misma que simfony o
la misma que usen otros plugins.. o el mismo proyecto askeet.

3) Sobre la organización, no tengo nada de experiencia en organizar
equipos online.
Pero creo que la mayoria quiere igualdad de voz y voto.
Y parece que casi nadie quiere clases o status.

Yo creo que bastaría con que..
1) Javier Eguiluz hiciera el kickoff del proyecto en assembla.com una
vez decidido el nombre.
2) Invita a todos que nos ofrezcamos en este hilo ( mi usuario
assembla es fons81)
3) Javi Eg. Empieza a escribir la wiki ?
Simplemente Proposito general , Objectivo o algo similar. y que quede
reflejado ,Para no perder el norte.
Los demás podriamos editar poniendo... ¿ Sugerencias con algún tag ? o
abrir debate sobre ello en algún otro lugar.
4) Entre todos escribir las especificaciones..
poniendo con la algún tag o marca si alguien tiene alguna objeción
a algún punto...
5) Una vez con las especificaciones definidas la gente que esté en el
proyecto assembla se puede ofrecer a escribir el código de las partes
que crea que puede hacer.
Quizá poniendo su nombre en la wiki al lado del requisito.
Sí hay más de una persona que se ofrece a hacer lo mismo , pues ..¿qué
hagan un equipo? o que ellos mismos se pongan en contacto. Si hay un
conflicto entre ellos ,por criterios dispares que se saque a Debate al
resto de programadores.
Quizá sea bueno poner fecha limite para resolver esos debates.
No se si assamble tine foro con encuestas. o algún sistema de votación
para decisiones.
Sino podriamos abrir un foro con un apartado por cada apartado de la
wiki.Más otro de conflictos. No sé.

Disculpar si me he entusiasmado demasiado escribiendo :) jejej

Saludos.

[Angel Roldan]

1) symplan
2) http://www.assembla.com
3) Coordinador Javier Eguiluz o Luciano Andrade aunque éste último me
parece que no se ha involucrado en el proyecto
4) licencia. MIT para código, GFDL para documentación, como Symfony

[Raul]

1. Me parece muy bien que el proyecto se llame sfCampoBase, aunque no
sea nada comercial ni atractivo.
2. Igual que meigallo y KNO, no conozco Asamblada, pero me fio de la
decisión de Javier Eguiluz.
3. Coordinador: particularmente, creo que no me sometería a otro
coordinador en este ámbito que no fuera Javier Eguiluz. Sin embargo
creo que es importante lo siguiente: el coordinador debe ser
democrático pero, forzosamente, se le debe reconocer mayor valor a sus
decisiones, consideraciones y resoluciones. Esto significa que
forzosamente no puede ser "uno más", sencillamente porque:

3.1. se va a echar una responsabilidad y un trabajo extra que los
demás no vamos a asumir, sobre todo en lo concerniente a la
supervisión y conciliación de enfoques durante el desarrollo.
3.2. va a ser la persona más criticada cada vez que algo no funcione.
3.3. posee experiencia y conocimientos técnicos que por sí mismos le
confieren una autoridad natural.

Es todo por mi parte. Salud!

On 2 jul, 13:07, meigallo <meiga...@meigallodixital.com> wrote:

> > <javier.egui...@gmail.com> escribió:

>
> >> Hola a todos/as,
>
> >> Como muchos ya habéis comentado, antes de poder comenzar a
> >> desarrollar
> >> el proyecto tenemos que ponernos de acuerdo en al menos 3 cosas:
> >> nombre de la aplicación, herramienta que vamos a utilizar para
> >> coordinarnos (es decir, un gestor de proyectos) y si necesitamos o no
> >> un coordinador.
>
> >> Como esta será una de las últimas discusiones sobre este tema en este
> >> grupo y pronto podremos seguir las conversaciones en otra
> >> herramienta/
> >> aplicación, propongo que todas las propuestas se hagan como respuesta
> >> a este mensaje.
>
> >> Para abrir fuego, añado aquí mis propias propuestas:
>
> >> 1) Nombre: como soy malísimo escogiendo el nombre de las cosas, sólo
> >> tengo "sfbasecamp" (que realmente se le ocurrió a un usuario de este
> >> grupo, pero ahora mismo no recuerdo quién) y "CampoBase" (puestos a
> >> clonar, clonamos hasta el nombre!!).
>
> >> 2) Herramienta para coordinarnos: un usuario de este grupo ha
> >> proporcionado el enlace a una tabla comparativa de este tipo de

> >> herramientashttp://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosti...

[pizzakiller]

El Miércoles, 2 de Julio de 2008 07:11, Raul escribió:
> 3.1. se va a echar una responsabilidad y un trabajo extra que los
> demás no vamos a asumir, sobre todo en lo concerniente a la
> supervisión y conciliación de enfoques durante el desarrollo.

precisamente por eso _todos_ lo s que se apunten al proyecto deben asumir
individualmente su erores si los hay .. y todos asumir los exitos

por que si hay éxitos quien los asume una sola persona?????????????????????

> 3.2. va a ser la persona más criticada cada vez que algo no funcione.

por eso solo debe ser uno mas .. debe ser una organización horizontal como en
los condominios ... si eres presidente de un condominio representas a
_todos_ pero tu propiedad no vale mas que la de los demas ni tu voto

> 3.3. posee experiencia y conocimientos técnicos que por sí mismos le
> confieren una autoridad natural.

esto si seria un buen valor agregado al proyecto

--
Juliocésar Prieto Lem -
Programmers never dies.. Only GOSUB without RETURN
user linux 218820. running Linux 2.6.18-3-686 i686 GNU/Linux
mié jul 2 22:16:59 VET 2008
Fingerprint = 04CC 8521 D3BF EB25 7F95 7E77 BB0A 5235 8C1B EF4B

[David Castelló]

1) symplan (ojo el dominio .com esta utilizado, el resto estan libres,
por ahora)
No soy partidario de nombres del estilo: sf* , *BaseCamp* , pero
acatamos la mayoria
2) http://www.assembla.com
3) Coordinador Javier Eguiluzt (conveniente tener coordinadores por
areas/tareas como (usabilidad, maquetacion, documentacion,
traducciones, ...)

[meigallo]

El 03/07/2008, a las 9:51, David Castelló escribió:

>
> 1) symplan (ojo el dominio .com esta utilizado, el resto estan libres,
> por ahora)
> No soy partidario de nombres del estilo: sf* , *BaseCamp* , pero
> acatamos la mayoria
> 2) http://www.assembla.com
> 3) Coordinador Javier Eguiluzt (conveniente tener coordinadores por
> areas/tareas como (usabilidad, maquetacion, documentacion,
> traducciones, ...)
>

El punto 3 es interesantísimo ...

[Alberto]

bueno estoy de acuerdo con varias ideas

El nombre en lo personal podria llevar algo como free u open mas
project, ya existe un openproject pero un freeproject suena bien.
de acuerdo con meigallo, no me gusta el sf al comienzo :P
queria agregar algo; me gustaria que estubiera en español el nombre,
pero un nombre en ingles y documentacion tambien alentara a mas
desarrolladores de otras regiones a unirsenos

assembla es bien

coordinador claro que es necesario para asignar tareas y coordinar que
el desarrollo va a estar como lo deseamos

On 3 jul, 02:58, meigallo <meiga...@meigallodixital.com> wrote:
> El 03/07/2008, a las 9:51, David Castelló escribió:
>
>
>
> > 1) symplan (ojo el dominio .com esta utilizado, el resto estan libres,
> > por ahora)
> >   No soy partidario de nombres del estilo: sf* , *BaseCamp* , pero
> > acatamos la mayoria

> > 2)http://www.assembla.com

[paolovas]

1.- Nombre: sfOpenProject ( Se escucha bonito )
2.- Asamblada ( Por pupularidad en la lista ya que no conozco estos)
3.- Coordinador: Javier Eguiluz. Porque tiene entrega hacia el
proyecto

> <javier.egui...@gmail.com> escribió:

>
>
>
> > Hola a todos/as,
>
> > Como muchos ya habéis comentado, antes de poder comenzar a desarrollar
> > el proyecto tenemos que ponernos de acuerdo en al menos 3 cosas:
> > nombre de la aplicación, herramienta que vamos a utilizar para
> > coordinarnos (es decir, un gestor de proyectos) y si necesitamos o no
> > un coordinador.
>
> > Como esta será una de las últimas discusiones sobre este tema en este
> > grupo y pronto podremos seguir las conversaciones en otra herramienta/
> > aplicación, propongo que todas las propuestas se hagan como respuesta
> > a este mensaje.
>
> > Para abrir fuego, añado aquí mis propias propuestas:
>
> > 1) Nombre: como soy malísimo escogiendo el nombre de las cosas, sólo
> > tengo "sfbasecamp" (que realmente se le ocurrió a un usuario de este
> > grupo, pero ahora mismo no recuerdo quién) y "CampoBase" (puestos a
> > clonar, clonamos hasta el nombre!!).
>
> > 2) Herramienta para coordinarnos: un usuario de este grupo ha
> > proporcionado el enlace a una tabla comparativa de este tipo de

> > herramientashttp://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosti...

[rafix]

me parece bien freeproject!!!

[Diego Rueda]

1) sfProyect -> me parece ideal
2) http://www.assembla.com
3) Coordinador Javier Eguiluz, pero deberia a ver por lo menos dos mas
ya que sera un proyecto grande

4) licencia. MIT para código, GFDL para documentación, como Symfony

On 3 jul, 09:55, Alberto <Spin....@gmail.com> wrote:

[Luciano A. Andrade]

No queria quedarme afuera, asi que anotenme para este proyecto, no se
en que pueda ayudar, pues estoy un poco ajustado con mis tiempos (por
lo cual no participe en estos hilos)

[Rodrigo Miranda]

> 1) Uno o varios coordinadores:
> Efectivamente el proyecto no va a tener 1 solo coordinador

Es necesario que juntos decidamos si hay coodinador principal y, si es
así, qué labores se les va a entregar. No obstante, en la práctica,
cuando ha existido un coordinador principal, es cuando la base o el
inicio del proyecto fue desarrollada o trabajada por él, mucho antes
de que el resto de la comunidad comenzara a sumarse.
En un grupo de Desarrollo, ese coordinador gestiona y está al tanto de
todo, en algunos también cumple un rol de certificador de
funcionalidades y de ingreso de personas al equipo de Desarrollos o
mesa de coordinadores. En este caso particular, colocar sólo a una
persona a la cabeza es arriesgado cuando no hay nada aún hecho, sobre
todo cuando en el comienzo se requiere del mayor compromiso y, por
ende, tiempo. Es por ello que considero que las responsabilidades las
podemos repartir en un equipo de coordinadores.

>
> Sin embargo, el proyecto se dividirá en decenas de tareas y cada uno
> trabajará en lo que le guste y le apetezca.

Es lo que se estila en los proyectos Open Source.

> El proyecto se autogestionará
> solo en la medida de lo posible y el coordinador intentará que su trabajo
> sea prácticamente nulo.

El proyecto no se puede autogestionar, suena bonito pero en la
práctica esto no ha funcionado en los grupos de desarrollos que
pululan en sourceforge, tiene que haber un grupo de coordinadores,
que justamente tienen que comprometerse con el peso de esta
iniciativa.

>
> 2) Meritocracia:
> Estoy totalmente en contra de montar algo parecido a una meritocracia y
> crear "castas" o "clases". No me gusta la idea de "usuarios superiores".
> Aunque a veces es injusto, yo votaría por una democracia en la que
> cualquiera con ganas de participar de forma activa tenga el mismo peso que
> cualquier otra persona.

De acuerdo Javier, considero que podríamos intentar hacer esto lo más
abierto posible. Sin embargo, necesitamos un grupo de coordinadores
que tome las decisiones, que tomen la responsabilidad de encaminar
este proyecto por los objetivos que se planteen. Considerando, eso
sí, las opiniones de la comunidad. Para ello debemos crear las
instancias para que todos, independiente del tiempo que lleve en
Symfony, o incluso no siendo desarrollador pero con conocimientos en
lo que nos convoca realice sus aportes. Los proyectos de esa manera se
nutren, comienzan a formar comunidades sólidas, y se suman a este
proyectos más personas, responsabilizándose de todas las labores que
seguramente serán necesarias a futuro como: Documentación en varios
idiomas, comunidades del proyecto en varios idiomas, la coordinación
de empresas, organizaciones o personas que deseen ser partners o
busquén alguna certificación del proyecto, etc, etc.

>
> Por eso comentaba antes que también el voto del coordinador debería valer lo
> mismo que el de los demás, incluso en caso de empate.

Considero que el voto de los coordinadores deberían valer lo mismo,
también incluso en el caso de empate. Pero ese debe ser un grupo de
personas que se están responsabilizando del proyecto, eso sí, que
deben estar mirando a la cara a la comunidad y no dando la espalda. El
caso omiso a las opiniones de la comunidad no puede existir, son ellos
que con su esfuerzo, trabajo, y aportes nos van a nutrir, pero deben
haber personas que se hagan responsable y que tomen las decisiones del
camino que tomará el proyecto (insisto tomando en cuenta las opiniones
de la comunidad tal como los proyectos que conocemos, no tratemos de
reinventar la rueda).

>
> 3) Licencias y demás:
> Ese tipo de cosas es lo que tenemos que aclarar cuanto antes...pero para eso
> necesitamos la herramienta para coordinarnos...y para eso necesitamos el
> nombre del proyecto. Precisamente por eso hemos creado este nuevo hilo de
> discusión.
>

Totalmente de acuerdo.

> Ya que muchos habéis comentado vuestras preferencias sobre licencias, yo
> elegiría las mismas licencias que Symfony: MIT para el software y GFDL para
> la documentación.

Bueno, eso lo conversamos y lo decidimos en la herramienta.


>
> Un saludo,
> Javier Eguiluzwww.symfony.es

Saludos.

Rodrigo Miranda.

[phpleo]

Hola, de verdad que me he quedado un poco fuera del hilo de esta
discución y es que se ha puesto muy interesante.

He visto opiniones y elecciones muy interesantes sobre el proyecto,
las cuales me gustaria comentar:

1. con respesto al nombre agregaria que este se esta notando por si
solo en la encuesta que se ha dado:
http://groups.google.com/group/symfony-es/browse_thread/thread/c7b536b0d3ca62df

2. asembla.com, me parece una buena elección, pero hay compañeros (si
no me quivoco) cubanos y habria que saber si ellos puede acceder a
este servicio ya que hay muchas ganas de parte de ellos ;)

3. Javier Eguiluz me parece una persona ideal como organizador, pero
depende mucho mas de su tiempo y sobre todo como mensionaron no solo
debe de haber uno!. Me parece mas acertada la propuesta de algunos en
ver organizadores por cada parte del proyecto, ya que de momento en la
encuesta de perfiles <http://groups.google.com/group/symfony-es/web/
encuestra-perfil-de-los-usuarios-de-symfony-es> todos hemos colocado
en que nos destacamos y la experiencia con symfony, pero aun no hemos
dado a conocer en que podriamos colaborar con el proyecto, como:
maquedado, base de datos, análisis, programación backend, etc.

4. Cuando se realizó las propuestas de proyectos, yo fuí uno de los
que propuso usar el ORM Doctrine y como mensioné en aquel entonces
"para dar a conocer las posibilidades de este framework". Una
posibilidad sería el de mostrar los capitulos que necesiten
interaccion con la base de datos con los codigos de ambos ORM o hacer
que dependiendo de la elecion del usuario se muestre el codigo del orm
correspondiente. Podria resultar el organizar 2 grupos o uno solo para
ver la realización de código sobre estos ORM's.

En este punto estoy seguro que hay muchas mas ideas que se pueden
expresar sobre esto :)

Salu2.