Aclaracións sobre o uso dos labels

[xabiercid]

Eu non vexo moi claras as diferenzas entre layout e frontend. E faltan todas as que teñen que ver con contidos, que non sei cal debe ser relación coas demais. É dicir, non sei se deben ser categorías que se sumen (layout+contents) ou se deben ser categorías á parte. Por exemplo, a produción de imaxes ou iconas, sería contents+design? ou sería unha categoría de visual content?

Que me corrixa @AndreaLopezLozano, pero eu poría:

• texts
• translation
• icons
• pictures

[bertez]

Layout -> html + css Frontend -> javascript

Non quixen poñer nomes de tecnoloxías por se nun futuro (DIOS NOS LIBRE) decidimos mudar algunha

Pero penso que deben estar divididas, ao mellor con Interaction/Layout?

[xabiercid]

eu véxoo ben.

On 26 Nov 2014, at 16:11, Berto Yáñez notifications@github.com wrote:

Layout -> html + css Frontend -> javascript

Non quixen poñer nomes de tecnoloxías por se nun futuro (DIOS NOS LIBRE) decidimos mudar algunha

Pero penso que deben estar divididas, ao mellor con Interaction/Layout?

— Reply to this email directly or view it on GitHub https://github.com/anavallasuiza/github-labels/issues/1#issuecomment-64669062.

[bertez]

Sobre o de text, translations, icons, pictures eu limitaría a: contents

[xabiercid]

diferenciar entre contents e translations foi útil nun proxecto como Abanca…

é algo só propio de Abanca… teño as miñas dúbidas...

On 26 Nov 2014, at 16:18, Berto Yáñez notifications@github.com wrote:

Sobre o de text, translations, icons, pictures eu limitaría a: contents

— Reply to this email directly or view it on GitHub https://github.com/anavallasuiza/github-labels/issues/1#issuecomment-64670320.

[eusonlito]

En desenvolvemento de software/web, frontend indica a parte de usuario corriente (web pública) e backend indica a parte de administrador (panel de xestión). Neste caso creo que non é correcto indicar Frontend para as tarefas de interactividade.

P.D.: Corrección, en desenvolvemento de software indica cliente/servidor, en desenvolvemento web indica iso que explico.

[eusonlito]

Pero váleme igual.

[xabiercid]

Non podo opinar no que di Lito, pero creo que deberiamos pensar non só en nós, senón tamén no mundo hai fóra. Refírome ao uso de estándares para denominar as cousas / postos. Tamén por iso facemos os termos en inglés.

On 26 Nov 2014, at 17:18, eusonlito notifications@github.com wrote:

Pero váleme igual.

— Reply to this email directly or view it on GitHub https://github.com/anavallasuiza/github-labels/issues/1#issuecomment-64679876.

[bertez]

Eu penso que debería quedar:

• interaction para javascript
• layout para html+css

parécevos?

[xabiercid]

e outra categoría que fose frontend, para o que dicía Lito, ou non?

On 26 Nov 2014, at 18:15, Berto Yáñez notifications@github.com wrote:

Eu penso que debería quedar:

interaction para javascript layout para html+css parécevos?

— Reply to this email directly or view it on GitHub https://github.com/anavallasuiza/github-labels/issues/1#issuecomment-64688299.

[eusonlito]

@xabiercid non é tan sinxelo. Nós facemos todos os proxectos con un xestor, básicamente creamos un CMS para os nosos clientes.

Este é o punto disruptivo no noso desenvolvemento, pero non o é en todos, cando existe un CMS as referencias cambian a front-end parte pública e back-end parte privada, pero sen CMS entenderíase como front-end cliente e back-end servidor.

En calquera caso, eu non engadiría esas etiquetas como base, paréceme ben interaction e layout, o que non teño tan claro é a nivel de servidor.

[eusonlito]

E algo como client-side e server-side http://programmers.stackexchange.com/questions/171203/what-are-the-difference-between-server-side-and-client-side-programming

[eusonlito]

Obviade o comentario anterior.

[bertez]

Sempre se pode volver a: php, html+css e javascript

@oscarotero que opina?

[ablunier]

Se se me permite entrar neste debate, eu opino que frontend e backend están ben pero con matices. Backend para min é o que se executa no servidor e que non interactua co usuario, e frontend toda a parte do cliente (incluindo html, css e javascript), a que ten a interacción directa co usuario. http://whatis.techtarget.com/definition/front-end

Disgregando en layout o html e o css, non vexo mal que ao javascript se lle designe como frontend.

Para referirme ao CMS empregaría xa unha etiqueta concreta de cms, que considero sería específica para cada proxecto, xa que case todos os proxectos da navalla o teñen, pero hai casos nos que non. Ademáis, dentro dun CMS tamén hai frontend e backend. En calquera caso, opino que o guai sería que o propio CMS fose un proxecto independente e único, pero é algo que non entra nesta conversa.

Interaction non é un termo que vexa nestes casos, normalmente dise javascript frontend developer por exemplo. Interaction é o que se fai na maioría de casos co javascript no frontend, pero non o vexo estrictamente reducido a iso.

É o meu punto de vista :)

[xabiercid]

Ou sexa:

backend: todos OK.

frontend: OK Berto e Adrián. Lito di que non. interaction: OK Berto, Adrián di que non. javascript: Máis ou menos OK todos, pero Berto cre que non deberiamos usar tecnoloxías.

layout: todos OK

CMS: psé. Sería unha boa etiqueta, pero pouco produtiva. Depende dos proxectos, como ‘Translation / location’.

Correcto ata aquí? Fáltame algo? As bancadas corean o nome de @oscarotero para que salte ao campo.

On 27 Nov 2014, at 00:19, Adrian P. Blunier notifications@github.com wrote:

Se se me permite entrar neste debate, eu opino que frontend e backend están ben pero con matices. Backend para min é o que se executa no servidor e que non interactua co usuario, e frontend toda a parte do cliente (incluindo html, css e javascript), a que ten a interacción directa co usuario. http://whatis.techtarget.com/definition/front-end http://whatis.techtarget.com/definition/front-end Disgregando en layout o html e o css, non vexo mal que ao javascript se lle designe como frontend.

Para referirme ao CMS empregaría xa unha etiqueta concreta de cms, que consideraro sería específica para cada proxecto, xa que case todos os proxectos da navalla o teñen, pero hai casos nos que non. Ademáis, dentro dun CMS tamén hai frontend e backend. En calquera caso, opino que o guai sería que o propio CMS fose un proxecto independente e único, pero é algo que non entra nesta conversa.

Interaction non é un termo que vexa nestes casos, normalmente dise javascript frontend developer por exemplo. Interaction é o que se fai na maioría de casos co javascript no frontend, pero non o vexo estrictamente reducido a iso.

É o meu punto de vista :)

— Reply to this email directly or view it on GitHub https://github.com/anavallasuiza/github-labels/issues/1#issuecomment-64729512.

[eusonlito]

A min váleme.

[AndreaLopezLozano]

Hi! Para a parte de contidos eu penso que poderiamos reducir a text (que englobaría gettext + crear contidos + traducir textos) e images (incluindo icons e pictures). Mesturalos non o vexo moi ben porque hai casos (a maioría) nos que as imaxes non dependen de min ou de Xabi porque teñen que ser retocadas, recortadas, etc. :)

[oscarotero]

Ola. O sistema pareceme moi guai. Eu faría varias configuracións de labels adaptadas a cada proxecto para lanzar comandos en plan python manager.py --laravel-proyect, etc.

En canto ás etiquetas en sí, intentaría ser máis práctico. Nos usamos os issues para asignarnos tarefas uns a outros, polo que etiquetas como "frontend" son quizáis demasiado xenéricas. Aínda que berto di que non se quería centrar en tecnoloxías, realmente nos traballamos con tecnoloxías. Berto, por exemplo traballa con javascript, e ese javascript pode estar no frontend pero tamén no backend (se algun día facemos algo baseado en node), e ao mesmo tempo, o frontend ten html/css/imaxes/deseño/etc que son tecnoloxías que berto non usa. Polo tanto, non sei se dividir as tarefas en frontend/backend pode axudar algo na organización do proxecto. Eu persoalmente sentíame relativamente cómodo coa división que había ata o momento en screenly/abanca onde saían as tecnoloxías (html+css, javascript, etc) xunto con outras áreas que non son tecnolóxicas (contidos, imaxes, etc). Se algun dia cambiamos de tecnoloxía, creanse novas etiquetas, non lle vexo problema.

Outra cousa importante a ter en conta son as tarefas que non teñen repercusión no repositorio. En abanca, por exemplo, todas as tarefas que hai se aplican ao repositorio (contidos e imaxes tamén), pero nos proxectos que facemos nos, os contidos da web non estan no repositorio, polo tanto, os issues relativos a eles perden un pouco a súa razón de ser. Por exemplo, eu podo ter un issue que diga "Cambiar o boton vermello para azul", fago o cambio no css, fago o commit relacionándoo con ese issue e pecho issue. De xeito que queda rexistrado que fixen ese cambio e pódese ver o cacho de codigo que modifiquei. Nun issue de contidos, como o contido vai nunha base de datos, pérdese esa información. Podería ser útil en gettext (se lito quixera incluir os arquivos de traducción no proxecto) e en xeral en contidos que se garden en arquivos, pero non en contidos de base de datos (a non ser que usemos sqlite).

Outra cousa que penso é que o github debería ser un espazo máis de traballo que de discusión. Se hai unha suxestión, idea, etc, debería tratarse no basecamp, incluso coa participación do cliente, se é necesario e unha vez decidido, no github simplemente aparecerían os issues coas tarefas necesarias. Esta división creo que é importante para evitar ter demasiadas frontes abertas.

Por último, faltaría algunha etiqueta para marcar issues que estean parados por algunha razón. Por exemplo, porque necesitamos que o cliente nos pase algo, ou porque depende de outro issue que esta sen rematar, etc.

[oscarotero]

Ah, e outra cousa: tampouco me gusta que se faga todo en inglés (tamén vai polo timetracker). Xa estamos colonizados dabondo e non sei moi ben que beneficios ten. Pero isto xa é unha opinión persoal asi que dígoo simplemente para que quede constancia :)

[bertez]

Vale, Paréceme ben.

Estou dacordo en volver ás etiquetas de tecnoloxías, se vos parece quedaría así:

https://github.com/anavallasuiza/github-labels/wiki

Tamén incluín o label de waiting e as aportacións de Andrea

Se dades o ok todos quedámonos con estas, conestade plis.

@xabiercid @eusonlito @ablunier @AndreaLopezLozano @AymaraGhiglione @cmoralesweb @barreiro61 @myanllo

[barreiro61]

A min pareceme que está ben.

M

2014-11-27 12:11 GMT+01:00 Berto Yáñez notifications@github.com:

Vale, Paréceme ben.

Estou dacordo en volver ás etiquetas de tecnoloxías, se vos parece quedaría así:

https://github.com/anavallasuiza/github-labels/wiki

Tamén incluín o label de waiting e as aportacións de Andrea

Se dades o ok todos quedámonos con estas, conestade plis.

@xabiercid https://github.com/xabiercid @eusonlito https://github.com/eusonlito @ablunier https://github.com/ablunier @AndreaLopezLozano https://github.com/AndreaLopezLozano @AymaraGhiglione https://github.com/AymaraGhiglione @cmoralesweb https://github.com/cmoralesweb @barreiro61 https://github.com/barreiro61 @myanllo https://github.com/myanllo

— Reply to this email directly or view it on GitHub https://github.com/anavallasuiza/github-labels/issues/1#issuecomment-64777186 .

[AndreaLopezLozano]

Para min perfectísimo!!

2014-11-27 12:15 GMT+01:00 barreiro61 notifications@github.com:

A min pareceme que está ben.

M

2014-11-27 12:11 GMT+01:00 Berto Yáñez notifications@github.com:

Vale, Paréceme ben.

Estou dacordo en volver ás etiquetas de tecnoloxías, se vos parece quedaría así:

https://github.com/anavallasuiza/github-labels/wiki

Tamén incluín o label de waiting e as aportacións de Andrea

Se dades o ok todos quedámonos con estas, conestade plis.

@xabiercid https://github.com/xabiercid @eusonlito https://github.com/eusonlito @ablunier https://github.com/ablunier @AndreaLopezLozano https://github.com/AndreaLopezLozano @AymaraGhiglione https://github.com/AymaraGhiglione @cmoralesweb https://github.com/cmoralesweb @barreiro61 https://github.com/barreiro61 @myanllo https://github.com/myanllo

— Reply to this email directly or view it on GitHub < https://github.com/anavallasuiza/github-labels/issues/1#issuecomment-64777186>

.

— Reply to this email directly or view it on GitHub https://github.com/anavallasuiza/github-labels/issues/1#issuecomment-64777581 .

Este correo mándoo como parte da relación comercial que estableceu coa Navalla suíza SL (B70184130). Se non quere recibir máis correos, só ten que comunicárnolo (conforme as leis españolas 15/1999 e 34/2002).

Andrea López Lozano andrea@anavallasuiza.com A navalla suíza - http://www.anavallasuiza.com Tel. 981 939 324

[ablunier]

Dacordo coas etiquetas por tecnoloxías, e incluindo o da adaptación a cada proxecto que comenta Óscar para permitir diferentes configuracións segundo as tecnoloxías empregadas :)

[AymaraGhiglione]

Por min guai, aínda que estou de acordo co apunte de Óscar sobre o idioma.

[cmoralesweb]

A min mólanme máis as tecnoloxías, si. No tocante ó que comenta Óscar de discutir en basecamp ou en github, de se algunha tarefa está en proceso ou non... Algunha vez vos plantexachedes usar Jira ou algún sistema similar de tarefas? O problema que eu lle vexo a usar os issues de github é que non se pode priorizar: saen todos "a lo loco", mentras que nun sistema tipo Jira (ou calquera similar, tipo Scrum) pódense ordenar as tarefas por prioridade. Ademáis, pódese poñer a cada tarefa unha estimación de horas, polo que se pode saber moito máis facilmente canto falta para rematar un milestone: remátase antes un milestone con 60 issues pendientes de 5 minutos ca un con 10 de 2 horas. Tamén teñen contadores de traballo, para poder ver a desviación entre a estimación e o traballo real.

Pola integración con Github non hai problema, pódense enlazar as tarefas de Jira co Github.

Pode ser moito cambio ou moi burocrático para o voso gusto, pero eu deixo a idea :P

[eusonlito]

A min gústame o inglés, o galego xa o sei, e teño moita necesidade de mellorar o meu inglés, por iso o uso, para forzarme a entendelo de maneira fluida e a usalo de xeito correcto, non creo que sexa algo colonizador, o que busco é melloralo. Podería facelo na intimidade, pero prefiro facelo sempre que podo.

[xabiercid]

Con respecto aos labels, OK

Con respecto aos comentarios de Óscar… (e en parte Aymará) — a min gustaríame que o traballo que facemos cara adentro se puidese reaproveitar o máis e o mellor posible fóra. Iso é realmente unha das poucas cousas que “keep me going”: poder facer cousas que revirtan nos demais. Por iso facer unhas categorías que só valian para nós é… bueno, ok, pero nós imos sobrevivir, chamándolle como lle chamemos. Xa sei que os demais que collan isto (porque temos que pensar que alguén vai reaproveitar o noso traballo) poden iniciar un proceso de debate coma este para adaptar as categorías ás súas características particulares. Pero… e se llo evitamos? Por iso creo que hai que facer as cousas (tamén) en inglés. — A experiencia de traballar con código para min é e foi moi excitante. Entendo que os CMS están wai, pero así tamén aprendemos.

Con respecto ao que di Carlos — non coñezo (aínda) iso que propós. O do timetracker ten só uns meses, e o github tampouco é moito máis vello… Comparto o que dis das prioridades de Git, pero deixaríalle uns meses máis ao sistema actual, para que se consolide. De todos os xeitos, hai aí unha corrente para movernos a modelos de desenvolvemento áxiles que, sen ter nin p**a idea, hai que apoiar e promover. Así que thumbs up!

On 27 Nov 2014, at 11:11, Berto Yáñez notifications@github.com wrote:

Vale, Paréceme ben.

Estou dacordo en volver ás etiquetas de tecnoloxías, se vos parece quedaría así:

https://github.com/anavallasuiza/github-labels/wiki https://github.com/anavallasuiza/github-labels/wiki Tamén incluín o label de waiting e as aportacións de Andrea

Se dades o ok todos quedámonos con estas, conestade plis.

@xabiercid https://github.com/xabiercid @eusonlito https://github.com/eusonlito @ablunier https://github.com/ablunier @AndreaLopezLozano https://github.com/AndreaLopezLozano @AymaraGhiglione https://github.com/AymaraGhiglione @cmoralesweb https://github.com/cmoralesweb @barreiro61 https://github.com/barreiro61 @myanllo https://github.com/myanllo — Reply to this email directly or view it on GitHub https://github.com/anavallasuiza/github-labels/issues/1#issuecomment-64777186.

[bertez]

Pecho issue porque chegamos a uns labels finais.