Sarebbe fantastico se rendessimo questo repository pubblico, e potrebbe essere un buon modo per attirare persone che vogliono lavorare in un certo modo. In generale non dovrebbero esserci problemi, a parte qualche dettaglio come le password delle reti wi-fi che potremmo semplicemente rimuovere (se uno sta in ufficio e gli serve la password del wi-fi può chiederla a qualcuno).

@mtylty @matteogalliani @davidedistefano vedete potenziali problemi?

A fondo di questa pagina

Come usare l'upstream etc.

1:1s are not on the first Friday of the month anymore, they're just every four weeks and not necessarily on Friday.

In Tool per i meeting viene ancora indicato Google Hangouts. Utilizziamo appear.in, quindi va creato un paragrafo ad hoc.

Non usiamo più da tempo /deploy per i deploy.

Questa pagina è da aggiornare.

We are using Geekbot to automate the Friday standup. We can talk about this in the Fridays section.

qui

This should be documented somewhere, as a new section either under How we work or Processes.

We don't have much in the playbook about our current workflow for project management. It would be useful both to onboard new team members and clients.

We should also include some tips on managing priorities, resources and deadlines in a software project, for those developers who also act as the client's point of reference.

Finally, information on how to properly communicate with clients would also be of great benefit to everyone in the team.

Qui

Aggiungere dettagli sulla possibilità di fare lavoro OSS nei venerdì.

As agreed with @kennyadsl, I'm starting researching about playbook publication. This issue is meant to keep progress about that. /cc @mtylty

"Problem owning" was a really unfortunate choice of words on my end. 😩 "Ownership" sounds much better and is widespread.

Da aggiornare in Tool.

• Perché i commit vanno scritti in un certo modo?
• Come scrivere e usare i commit in modo che siano utili per tracciare la storia di feature e bug

In Tool va aggiunto Float, tool essenziale e coerente con la sezione Lavorare insieme.

Altra posizione in cui si parla di Float:

• Ferie Permessi e Malattia

https://github.com/nebulab/playbook/blob/master/working-on-nebulab/internal-projects.md

Problem: Bridge project link returns 404 to non-Nebulab visitors

Proposal: We could change the project label from "Bridge" to "Bridge (private project)"

The Tracking time explains the concepts of "Hours in the office" and "Hours on a project". The names are a bit confusing here, better names would probably be "Hours of presence" (because we have remote workers) and "Hours of work" (because not all of our work is done on client projects).

We should also add a short section at the end explaining how to handle differences between these two numbers:

• Hours of presence > hours of work: personal leave
• Hours of presence < hours of work: overtime

In Crescita personale si legge:

Il venerdì

Il venerdì in Nebulab è un momento di crescita personale e collettiva. Il venerdì non lavoriamo sui
clienti, ma su noi stessi e di conseguenza su Nebulab.

Manca la policy in caso di assenza per ferie o giorno festivo durante i 4 giorni in cui lavoriamo per i clienti.

The "Mentoring and 1:1s" section is mainly targeted towards mentees, not mentors.

However, being a good mentor is very difficult and it requires a lot of studying. We could add some useful material to this section or a new one that can be used to more quickly bring new mentors or aspiring mentors up to speed on the responsibilities and day-to-day work of a mentor.

This should also be inspiring for our existing team members so that they're encouraged to find out whether mentorship is for them.

Here's some of the stuff we could cover:

• How to run good 1:1s
• How to listen to people
• How to handle conflict
• How to manage projects

Also, this repository has a ton of useful resources.

In dove-e-quando.md si legge

Le giornate lavorative sono di 8 ore piuttosto flessibili. Per legge non si possono comunque superare le 11 ore giornaliere.

Su diverse risorse ho trovato che l'orario lavorativo in eccesso segue due regole:

• Massimo 13 ore giornaliere.
• Massimo 48 ore settimanali.

A mio avviso avere dei link di navigazione, anche solo uno, come torna alla pagina iniziale renderebbe la fruizione del playbook più piacevole.

L'idea è quella di creare una guida sul Playbook per tutto il team Front-End da usare come standard.

Si potrebbe partire da questo articolo:
https://www.smashingmagazine.com/2018/06/bem-for-beginners/

Comunicare proattivamente, come strutturare i meeting, perché evitare i meeting ricorrenti, e tutte le altre informazioni e i valori che guidano la comunicazione in Nebulab

Mettere un placeholder per Nome Cognome e Numero di telefono in Firma email 😄

Bisognerebbe allineare il contenuto di Benefit a ciò che si legge nelle posizioni aperte e sul sito.

In "Strumenti per la raccolta e gestione dei dati personali" c'è Trello per la gestione e archiviazione dei candidati a posizioni lavorative. Da sotituire con Workable.

Dovremmo aggiungere informazioni su che tipo di contenuti condividere, perché è importante condividere, su quali canali condividiamo, come è strutturato lo schedule etc. Qualunque cosa che aiuti le persone a chiarire i dubbi in anticipo senza dover chiedere, in modo che ci siano meno barriere possibili all'invio e alla creazione di nuovi contenuti.

Si deve lavorare il giorno del Santo Patrono della città dove si abita?

Creare una sezione, probabilmente da includere nella sezione Ferie, per rispondere a questa domanda.

In Dove e quando si legge:

Riguardo al luogo la flessibilità è ancora maggiore. Nebulab al momento ha due sedi operative, una a Pescara e una a Latina, ma si è liberi di lavorare ovunque si voglia (volendo anche da casa propria).

Aggiungerei un paragrafo dal titolo Lo spazio di lavoro a casa dove chiarire come creare un ambiente di lavoro ideale anche a casa propria.

Sarebbe utile una sezione sul corretto utilizzo di Dipendenti in Cloud.

We need to add a section with guidelines for blogposts.

I was thinking initially we can just specify that 2 people each month need to produce a blogpost as their monthly project, then we can just take it from there.

What do you guys think? @matteogalliani @mtylty @kennyadsl

qui

A Latina abbiamo Sonos ora e quelle playlist spotify non sono mai state usate praticamente.

In molte sezioni del playbook ancora usiamo l'impersonale "si dovrebbe" e altre circonlocuzioni che aggiungono troppo peso a quello che viene detto. Secondo me dovremmo cercare di semplificare il più possibile il linguaggio, anche nell'ottica di una traduzione verso l'inglese, per rendere più semplice la comprensione e per riflettere la trasparenza con cui lavoriamo.

Also mention:

• https://github.com/ankane/strong_migrations
• https://github.com/uohzxela/clean-code-ruby

We should add Tadum to the Meetings and Tools sections.

In Meetings, we should make sure to mention that Tadum is best used for recurring meetings, although it's also useful for one-offs.

Mi sono reso conto che è molto difficile capire se del nuovo contenuto debba essere messo in una o nell'altra sezione, e il motivo è che lavorare per i clienti vuol dire lavorare insieme. Propongo di unificare la due sezioni.

In the first sentence of the last paragraph of Professional coaches, delete at least and add with where needed.

We recommend holding at least a 1-hour session [?] your coach every Friday.

-> We recommend holding a 1-hour session with your coach every Friday.

also...

-> We usually recommend holding a 1-hour session with your coach every Friday.

I think the second version creates a better connection to what said in the following sentence.

Dobbiamo aggiornare Tool e Consuntivazione delle ore e probabilmente anche qualche altra sezione che ancora fa riferimento a Float. Inoltre, bisogna aggiungere delle guideline sul corretto utilizzo del tracker, che è un po' diverso rispetto al nostro precedente metodo di consuntivazione.

Io sostituirei pure "consuntivazione" con "tracking" già che ci siamo. 😄

We used to have a daily stand-up meeting on each project with its micro-team and with the project's mentor.

We should ask ourselves if we have to keep alive this meeting and, if the answer is yes, add the description in the lavorare insieme section.

Maybe the rule Work on client's project even on Friday if some holidays occurred during the week should be reported also in Client's guide?

This is missing!

• Collezione dei log: ?
• Exception monitoring: Honeybadger/New Relic
• Email delivery: ?
• ...

Mindset

I tratti caratteriali delle persone che vogliamo facciano parte del nostro team sono principalmente:

• Sentirsi parte del progetto su cui si lavora, agendo da founder, come se i problemi del progetto su cui si lavora fossero anche i loro.
• Mentalità orientata alla crescita

Carattere

• sfide (evitate vs affrontate)
• problemi (abbandono vs ci prova fino alla fine)
• fare uno sforzo extra (percepito come negativo vs step per crescita personale)
• critiche (ignorate/prese sul personale vs occasione per crescita personale)
• successo di altri (si buttano giù vs prendono ispirazione)
• l’immagine di se stessi (migliore possibile focalizzandosi su quello che si è al momento vs quello che si può riuscire a fare in futuro coltivando le proprio caratteristiche)
• propri difetti auto-riconosciuti (nascosti vs obiettivi da migliorare)

Aspetti tecnici

• Migliorano il codice che toccano, opportunistic refactoring: https://martinfowler.com/bliki/OpportunisticRefactoring.html
• aiutano il resto del team
• mette gli altri nella posizione di aiutare il resto del team
• scrive codice in primis per essere letto da esseri umani
• quick debug, pragmaticità e alta connessione ai dettagli piuttosto che all’architettura ad alto livello
• agiscono in modo che i problemi che si affrontano non si verifichino più

Team growth

• aiutano gli altri a crescere
• capiscono che la capacità produttiva dell’intero team è formata dal talento delle persone moltiplicato per la capacità di lavorare in team e provano ad elevare entrambe le cose
• non risolvono tutti i problemi da soli, nonostante siano in grado di farlo
• sono pazienti nell’insegnare agli altri, cercando di adattarsi agli stili di apprendimento delle persone invece che cercare di adattare le persone al proprio stile di insegnamento
• rispettano alti standard e ci fanno arrivare tutti con gentilezza

Problem solving

• riescono ad assegnare ai problemi il giusto valore, un compromesso tra l’aspetto tecnologico della questione e il valore che l’azione porta al cliente e al suo business
• nei confronti del cliente agisce come se stesse spendendo i propri soldi

qui

In Tool, paragrafo Float:

Per farti un'idea su come segnare le ore su Float dai un'occhiata a [Consuntivazione]([Standard](https://github.com/nebulab/playbook/blob/master/lavorare-per-i-clienti/consuntivazione.md))

il link su consuntivazione non funziona poichè c'è [Standard] di troppo oppure ad essere di troppo sono le quadre di Consuntivazione. Secondo me va eliminato [Standard]

Ha più senso, adesso che introdurremo anche le linee guida per partecipare alle conferenze, e suona anche meno burocratico.