Understrukna ord finns i lektionsordlistan. Tryck på ett ord för att se alla översättningar. Lägg till eller redigera ord i messages/glossary.json (alla språknycklar du lägger till visas i rutan).
Infrastructure, DevOps, and support
Documentation and knowledge sharing
Har du tid att läsa igenom och uppdatera dokumentationen i vår gemensamma wiki?
Jag letar efter guiden för hur man sätter upp miljön lokalt, vet du var den ligger?
Det är extremt viktigt att vi alltid dokumenterar våra komplexa tekniska beslut någonstans.
Vi har tyvärr ganska dålig och föråldrad teknisk dokumentation för just det här legacy-systemet.
Jag skrev precis ihop en steg-för-steg-guide i Confluence för hur man startar om databasen.
Kan vi lägga till mer kontext i README-filen så att nyanställda förstår syftet med applikationen?
Låt oss boka ett möte för kunskapsöverföring (knowledge transfer) innan konsulten slutar hos oss.
Vi måste bli mycket bättre på att skriva incidentrapporter och publicera dem i vår kunskapsdatabas.
Vår runbook saknade instruktioner för exakt det här felet, så jag lade till ett nytt kapitel.
Dokumentationen är tyvärr inaktuell och stämmer inte alls överens med hur koden faktiskt fungerar idag.
Jag brukar skriva mycket kommentarer i koden istället för att ha tjocka, externa manualer.
Kan du skicka mig en direktlänk till sidan där alla API-endpoints finns väldokumenterade?
Vi håller ett 'Brown Bag'-seminarium på lunchen för att dela med oss av våra lärdomar från projektet.
Vem är det egentligen som är huvudansvarig för att uppdatera driftmanualen inför den här releasen?
Jag spelade in en kort video där jag demonstrerar hur hela det nya automatiseringsflödet fungerar.
Bra dokumentation sparar otroligt mycket tid för alla kollegor i supporten.
Det finns en jättebra artikel på intranätet som förklarar företagets övergripande arkitektur och vision.
Vi borde ha som formellt krav att ingen kod får rullas ut i produktion utan tillhörande dokumentation.
Låt oss strukturera om vår wiki så att den blir mycket lättare att söka i och navigera.
Jag upplever att mycket kritisk kunskap idag tyvärr sitter fast i huvudet på enskilda utvecklare (silos).
Vi använder Swagger för att automatiskt generera en alltid levande och uppdaterad API-dokumentation.
Innan vi påbörjar projektet måste vi skriva ett ordentligt och detaljerat designdokument (RFC / Design Doc).
Kan du ta en titt på utkastet till manualen och ge mig lite konstruktiv feedback på språket?
Det enklaste sättet att onboarda nya medarbetare är att ha en extremt tydlig checklista redo.
Vi måste samla in alla FAQ (vanliga frågor och svar) från kundtjänst och lägga dem i en portal.
Jag dokumenterar alla manuella steg i ett skript istället, det blir 'Executable Documentation'.
Om du löser ett svårt tekniskt problem, se till att alltid dokumentera lösningen för framtiden.
Jag ska se till att on-call-dokumentationen är kristallklar så att man inte behöver tänka mitt i natten.
Har teamet enades om en gemensam mall eller standard för hur vi ska skriva våra versionsanteckningar?
Projektet saknar tyvärr helt och hållet ett diagram över hur alla externa databaser hänger ihop.
Vi flyttar bort från Word-dokument och lägger numera all text i Markdown i versionshanteringssystemet (Git).
Kunskapsdelning (Knowledge Sharing) är en fundamental del av en sund och framgångsrik ingenjörskultur.
Vi måste sluta svara på tekniska frågor direkt i chattar och istället hänvisa till de officiella guiderna.
Jag har samlat ihop en ordlista med alla märkliga förkortningar och tekniska termer som vi använder här.
Guiden var tyvärr extremt svår att förstå för mig som är junior, vi måste skriva den enklare.
Låt oss hålla en kort och informell presentation på fredag för att visa upp vad vi har byggt i veckan.
Jag läser just nu igenom den tekniska specifikationen för att försöka förstå vad kunden faktiskt har beställt.
Jag har upprättat ett arkitekturregister för att spåra varför vissa vägval (Architecture Decision Records, ADR) gjordes.
Var noga med att inkludera kodexempel (code snippets) i manualen, det underlättar oerhört mycket för utvecklarna.
Vi måste se till att sökmotorn i vår interna kunskapsdatabas indexerar sidorna på rätt sätt.
Vi arrangerar regelbundet hackathons just för att sprida nya spännande idéer mellan de olika teamen.
Den här gamla guiden om att bygga appen lokalt är från tvåtusensjutton, vi borde radera den.
All vår infrastruktur dokumenteras bäst genom koden i Terraform snarare än i långa, handskrivna dokument.
Jag hjälper gärna till med att korrekturläsa den nya användarmanualen innan den skickas ut till våra slutkunder.
Vi har skapat ett dedikerat chattrum enbart för tekniska frågor och allmän kunskapsspridning.
Dokumentationen är i grunden väldigt bra, men den saknar några viktiga detaljer om hur man ställer in säkerhetsnycklarna.
Låt oss uppdatera onboarding-materialet för utvecklare, det är ett jättebra sätt att testa om det är aktuellt.
Det var tack vare din utmärkta guide som jag lyckades lösa hela problemet på under fem minuter idag!
Att skriva dokumentation känns ofta ganska tråkigt just där och då, men det lönar sig alltid oerhört mycket på sikt.
Jag är väldigt stolt över den transparenta och öppna kultur av kunskapsdelning som vi har byggt upp här i teamet.
