Write the Docs Europe 2016 - relacja
W tym roku mieliśmy zaszczyt być patronem medialnym europejskiej edycji konferencji Write the Docs, która odbyła się w Pradze w dniach 18-20 września. Zapraszamy na naszą relację z tego wydarzenia.
Zwiedzanie i pisanie (niedziela)
Klimat konferencji to nie tylko prelekcje, networking i przyjęcia. To także samo miasto, w którym konferencja się odbywa, dlatego nasz pobyt w Pradze rozpoczęliśmy od zapoznania się z jej urokami. Na miejsce przybyliśmy wcześnie rano w niedzielę, ale pomimo zmęczenia podróżą wyruszyliśmy na poszukiwanie najważniejszych atrakcji turystycznych.
Podczas gdy my odhaczaliśymy kolejne punkty wycieczki, takie jak Most Karola czy Pražský Hrad, oraz kolejne kufle dobrego czeskiego piwa, w Autoklubie ok. 100 uczestników konferencji dzielnie pracowało nad projektami w ramach Writing Day.
https://twitter.com/adriennefriend/status/777434765850972160
Nie jesteśmy w stanie zweryfikować ile tak naprawdę treści powstało podczas tych warsztatów, ale wiemy na pewno, że uczestnicy dobrze się bawili wymieniając się doświadczeniami.
https://twitter.com/kmdk/status/777489740853641217
Warsztaty zakończyły się przyjęciem powitalnym, podczas którego wszyscy mieli okazję lepiej się poznać.
https://twitter.com/writethedocs/status/777528737462153216
Pierwszy dzień prezentacji (poniedziałek)
Pierwszy dzień konferencji otworzyła przewodnicząca społeczności Write Docs, Mikey Ariel przybliżając nam w swojej powitalnej prezentacji profile zawodowe uczestników tegorocznej edycji konferencji, wśród których byli m.in. dokumentaliści, programiści i pracownicy wsparcia technicznego. Okazało się, że dla większości z nich był to pierwszy udział w konferencji Write the Docs. Dowiedzieliśmy się, że w tym roku była to trzecia odsłona europejskiej edycji konferencji, w której wzięło udział 230 osób. Jest to spory postęp w stosunku do poprzednich lat, w których ta liczba kształtowała się na poziomie 100 osób w 2014 i 150 osób w 2015. Mikey przedstawiła również hasło przewodnie konferencji, które brzmiało: "Docs or it didn't happen!". Nie ukrywamy, że bardzo przypadło nam do gustu 😊
https://twitter.com/skarpediem/status/777785372432535553
Po przedstawieniu organizatorów i sponsorów przyszedł czas na prelegentów. W trakcie pierwszego dnia uczestnicy mieli okazję wysłuchać 9 prezentacji. Przedstawiamy skrót wybranych przez nas pozycji.
Rugby i dokumentacja
Paul Adams w trakcie swojej prezentacji Postulating The Backlog Laxative pokazał jak może działać współpraca między inżynierami i Tech Writerami. Kiedy zwiększa się skala działania firmy pojawia się pytanie jak dopasować do tego dokumentację. Firmy próbują odpowiedzieć na nie na różne sposoby. Część z nich nie robi w ogóle dokumentacji. Inne próbują dołączyć Tech Writerów do zespołów inżynierskich. To daje dokumentalistom możliwość bycia na bieżąco z tym co się dzieje, jednak rzadko kiedy są oni na tyle wszechstronni, by wpisać się w agilowe założenie, które mówi, że każdy członek zespołu może wykonać dowolne zadanie - Tech Writer ma swoje zadania, reszta zespołu swoje. Dodatkowo może okazać się, że Tech Writer nie nadąża za resztą zespołu i pracuje nad czymś, co jego koledzy programiści skończyli dwa tygodnie wcześniej. W takim razie jakie jest dobre rozwiązanie? Paul zaproponował, żeby zapomnieć o scrumie znanym z Agile i pomyśleć o scrumie takim jak w rugby, w którym istnieje podział na podzespoły. Tech Writer nie jest inżynierem i to jest jak najbardziej w porządku. Trzeba stworzyć osobny zespół Tech Writerów i oddzielić zadania dokumentacyjne od zadań inżynierskich. Taki właśnie styl pracy przyjęto w firmie, w której pracuje Paul. Inżynierowie tworzą pierwszy szkic dokumentacji i potem przekazują go Tech Writerom do obróbki, dzięki czemu można zamknąć proces inżynierski bez czekania na dokumentację. Jest to ciekawe podejście do tematu, nad którym można się zastanowić. Jednak należy pamiętać, że każda firma rządzi się swoimi prawami i nie zawsze to co zadziałało w jednej, sprawdzi się w innej.
https://twitter.com/MChabowski/status/777789648303251456
Potrzeba ciągłego doskonalenia
István Zoltán Szabó, znany również jako Steve, w swojej prezentacji Writing as a non-native speaker opowiadał o wyzwaniach jakim stawia czoło pracując w języku angielskim, który nie jest jego językiem ojczystym. Prowadzący stwierdził, że język jest najpotężniejszym narzędziem jakie stworzyła natura, dlatego ważne jest, żeby poszerzać swój zasób słownictwa. Jedną z najbardziej dla niego frustrujących rzeczy jest to, że nie umie czasami po angielsku wytłumaczyć jakiejś koncepcji, którą jest w stanie bez problemu wyjaśnić po węgiersku. Oprócz wzbogacania słownictwa, musimy pracować nad tym, żeby informacje, które przekazujemy były prostsze i nie zawierały zbędnych elementów. Najlepiej oddaje to myśl Blaise'a Pascala - "Gdybym miał więcej czasu, napisałbym krótszy list". Poza poziomem złożoności informacji istnieje także problem błędów tłumaczeniowych wynikających z różnic pomiędzy językiem angielskim i innymi językami. Steve przytoczył kilka przykładów, które pokazywały popularne błędy w tłumaczeniu zdań węgierskich, czeskich i chińskich na angielski. Kolejnym punktem prezentacji były porady w jaki sposób przezwyciężać swoje ograniczenia. Najbardziej w głowie utkwiło nam: "Write drunk, edit sober" 😊 A tak poważnie, to na przykład proces pisania można rozbić na kilka etapów. Na początku tworzymy strukturę, nie zwracamy uwagi na gramatykę, tylko skupiamy się na samym pisaniu. Następnie zostawiamy tekst na jakiś czas. Kiedy do niego wrócimy, poprawiamy wszelkie błędy i niedociągnięcia. Dobrą praktyką jest też przeczytanie tekstu na głos. Po skończonej edycji, wysyłamy tekst do edytora. Oprócz tego Steve rekomendował oglądanie seriali, ponieważ dzięki temu można nauczyć się aktualnego, żywego języka oraz zapoznać się z popkulturą, która wdziera się w różne dziedziny życia. Poznanie jej pomaga zrozumieć rzeczywistość. Dobrym pomysłem jest również znalezienie sobie mentora, który ma większe doświadczenie i będzie nas chciał poprowadzić, prowadzenie pamiętnika czy czytanie blogów. Była to bardzo solidnie przygotowana prezentacja. Widać było, że prowadzący włożył w nią sporo wysiłku i serca, dzięki czemu jego wystąpienie stało na wysokim poziomie.
https://twitter.com/DaveDri/status/777801845733548032
Dokumentacja tylko dla twardzieli
Kolejnym ciekawym wystąpieniem pierwszego dnia była prezentacja Operations Technical Writing for Data Centers poprowadzona przez Joan Wendt, która tworzy dokumentację do sprzętu używanego w centrach danych Google. Jej zadaniem jest dostarczanie informacji o tym jak instalować i konfigurować routery, serwery, jak odpowiednio poprowadzić wiązki kablowe oraz jak działają systemy zasilania i chłodzenia wspomagające główny sprzęt. W tym celu musi współpracować z inżynierami w centrach danych i robić sporo zdjęć sprzętu. Proces tworzenia dokumentacji obejmuje takie kroki jak: spotkania projektowe z inżynierami, praca w laboratorium w celu zrobienia zdjęć prototypu, odwiedzenie pierwszej wersji centrum danych, stworzenie szkicu, a następnie powrót do centrum w celu przetestowania dokumentacji. Po testach publikowana jest wersja produkcyjna dokumentacji.
Prowadząca pokazała nam kilka próbek dokumentacji jaką tworzy. Czasami z pozoru proste rzeczy, jak wiązka kabli, wymagają rozbudowanego opisu, bo np. ich instalacja wymaga wykonania 19 kroków w trzech osobnych procedurach. W większości przypadków dokumenty zawierają procedury z krokami oraz dużo dobrych praktyk i porad. Język stosowany w nich jest tak zwięzły, że Tech Writerzy pomijają nawet przedimki określone i nieokreślone. Nie skupiają się zbytnio na formatowaniu, a zamiast zrzutów ekranu robią zdjęcia - duże ilości zdjęć z różnych perspektyw, przez co inżynierowie muszą powtarzać procesy montażu, żeby każdy krok został uwieczniony. Praca z takim rodzajem dokumentacji niesie ze sobą sporo wyzwań. Zamiast wygodnej sukienki i szpilek trzeba nosić buty robotnicze, kask, odblaskową kamizelkę, okulary, uprząż, a nawet zatyczki do uszu. Ponadto trzeba przywiązywać dużą wagę do szczegółów, ponieważ projekty kosztują miliony i źle napisana instrukcja może mieć duże konsekwencje finansowe albo może spowodować, że ktoś ulegnie wypadkowi. Taki rodzaj pracy jest wymagający fizycznie i wiąże się też z częstymi wyjazdami służbowymi. Jednak można mieć satysfakcję z tego, że tajemna wiedza inżynierów zostaje przez nas przelana na papier, przez co pewne procedury zostają ustandaryzowane. Dla osób, które na co dzień opisują oprogramowanie w komfortowym, klimatyzowanym pomieszczeniu, taki tryb pracy może zakrawać na science fiction. Jak widać, pisanie dokumentacji to nie zawsze kawka i laptop w zaciszu własnego biurka 😉
Jeden zrzut ekranu jest wart więcej niż tysiąc słów
Pod warunkiem, że jest dobrze zrobiony. Ten temat w swojej krótkiej prezentacji When bad screenshots happen to good writers poruszył Swapnil Ogale. Prowadzący porównał naszą chęć posiadania zrzutów ekranu w dokumentacji do kokainy - nie potrzebujemy jej, może nas zabić, ale niesamowicie jej pragniemy. Z badań jakie przeprowadził Swapnil wynika, że 86% z przebadanych Tech Writerów sama robi zrzuty ekranu do dokumentacji. To dobra wiadomość, ponieważ w większości przypadków to właśnie dokumentaliści mają wpływ na to jak one wyglądają. Zła wiadomość jednak jest taka, że 60% respondentów na pytanie czy podręcznik stylu w ich firmie obejmuje dobre praktyki dotyczące robienia zrzutów ekranu, odpowiedziało przecząco. Często powodem był po prostu brak istnienia jakiekolwiek podręcznika. Prowadzący pokazał nam jako przestrogę przykłady źle wykonanych zrzutów ekranu. Były one odzwierciedleniem najczęściej popełnianych błędów, takich jak za duża ilość kontekstu, brak wskazania sekcji, o których mówi tekst czy zamazany obraz. Takie niedociągnięcia wynikają z braku zrozumienia, że dobry zrzut ekranu nie powstaje w kilka sekund, że musi być przemyślany i dostosowany do treści. Poza tym częstym problemem jest goniący termin wypuszczenia nowej wersji produktu, przez co zrzuty ekranu robi się niedbale. Co możemy zrobić, żeby było lepiej? Przede wszystkim trzeba stworzyć dobre praktyki dotyczące robienia "screenów" i je udostępnić innym. Można też zmienić narzędzia na lepsze, oferujące więcej możliwości. Warto też zastanowić się dłużej nad tym jaki cel ma nasz zrzut ekranu. Na koniec prowadzący pokazał kilka przykładów porządnie wykonanych "screenów". Były one dobrze docięte, zastosowane były elementy takie jak dymki z opisami i powiększenia ważnych fragmentów. Być może prezentacja nie była bardzo odkrywcza, ale znalazło się w niej sporo praktycznych przykładów. Takie "mięsiste" prezentacje lubimy najbardziej, bo można z nich wynieść najwięcej wskazówek.
https://twitter.com/kmdk/status/777870861634248704
Wieczorne rozmowy niekontrolowane
Jak wiadomo nie samą treścią Tech Writer żyje, dlatego organizatorzy po skończonych prezentacjach zaprosili uczestników do klubu Lávka, w którym odbywała się zeszłoroczna edycja konferencji. Miejsce bardzo klimatyczne, zlokalizowane w sąsiedztwie Mostu Karola. Niestety, pogoda nie dopisała, więc nie za bardzo można było korzystać z uroków dostępnego tarasu. Jednak pomimo chłodu i opadów, atmosfera w środku nastrajała pozytywnie i zachęcała do nawiązywania nowych znajomości oraz wymiany doświadczeń i wizytówek przy niejednym kuflu dobrego, czeskiego piwa.
Drugi dzień prezentacji (wtorek)
Drugiego dnia na scenie pojawiło się 10 prelegentów. Poniżej przedstawiamy wybrane prezentacje.
Jakość jakości nierówna
Temat jakości dokumentacji został poruszony przez Rionę MacNamara podczas prezentacji As Good As It Gets: Why Better Trumps Best. Ulubionym pytaniem prowadzącej, które zadaje podczas rozmowy kwalifikacyjnej jest: "Skąd wiesz, że Twoja dokumentacja jest dobra?". Odpowiedzi są tak różne jak sami kandydaci. To wskazuje na brak ugruntowanych standardów świadczących o jakości dokumentacji. Dlatego istnieje potrzeba stworzenia wytycznych, którymi będzie można się kierować oceniając jakość. Riona przedstawiła dwa aspekty jakości dokumentacji - strukturalny i funkcjonalny. Pierwszy z nich jest łatwy do sprawdzenia, ponieważ odnosi się do tego w jaki sposób jest napisany dokument - czy nie zawiera błędów, czy jest zgodny z podręcznikiem stylu oraz czy łatwo się po nim poruszać. Drugi z nich odnosi się do efektywności dokumentu, czyli tego czy spełnia on swoje zadanie i czy pozwala użytkownikom osiągnąć ich cele. Żebyśmy lepiej mogli poczuć różnicę między tymi dwoma typami jakości, prowadząca pokazała nam krótki filmik, który był dobrze zmontowany, ciekawy, ale nie spełniał swojego celu. Ogólna zasada jest taka, że jakość funkcjonalna może opierać się na jakości strukturalnej, ale jakość funkcjonalna jest ważniejsza. Przez to dokument, który ma wysoką jakość strukturalną, ale niską jakość funkcjonalną jest ogólnie słabej jakości. Dlatego przede wszystkim powinniśmy się skupić na zapewnieniu jakości funkcjonalnej naszej dokumentacji, dzięki czemu będzie ona przydatna dla użytkowników. Zapewne idee przedstawione w tej prezentacji nie są Wam obce, ale teraz przynajmniej nasza wiedza jest bardziej uporządkowana i wiemy jak nazywać rzeczy po imieniu.
https://twitter.com/PeterRylands/status/778142098566553600
W pogoni za releasem
Rachel Whitton podczas wystąpienia Delivering High-Velocity Docs that Keep Pace with Rapid Release Cycles opowiedziała w jaki sposób można sprawić, by dokumentacja nadążała za rozwojem produktu, używając przykładu ze swojej firmy. Na początku dokumentacja nie była dostarczana regularnie. Zespół miał dobre chęci, ale proces jej tworzenia nie był zgrany z procesem tworzenia oprogramowania, przez co dokumentacja powstawała zawsze za późno. Żeby zmienić ten stan rzeczy, firma zdecydowała się na pewne zmiany. Jedną z nich było publiczne dokumentowanie przyszłych funkcji oraz dopuszczenie osób spoza firmy do procesu tworzenia dokumentacji. Dzięki temu uzyskano bazę testerów, dzielących się swoimi opiniami. Kolejnym krokiem było uproszczenie procesu recenzowania treści poprzez takie ustawienie priorytetów, by skupić się tylko na najpopularniejszych scenariuszach użycia produktu. Następnie zintegrowano GitHuba ze Slackiem, co pozwoliło usprawnić komunikowanie zmian. Obecnie eksperci dostają powiadomienie z linkiem, który klikają, żeby wyświetlić odpowiedni kod. Następnie przyszła pora by zautomatyzować pewne procesy, dzięki czemu dokumentacja jest sprawdzana, np. pod kątem niedziałających linków, po czym publikowana w odpowiednim miejscu. Tutaj warto wspomnieć o jednej rzeczy. Przed rozpoczęciem prac nad automatyzacją, warto przyjrzeć się narzędziom, które już są wykorzystywane w firmie. Jest szansa, że istnieje jakieś gotowe rozwiązanie, które będzie można przenieść na grunt dokumentacyjny. Wszystkie opisane powyżej działania pozwoliły na usprawnienie procesu dostarczania dokumentacji. Może będzie to dla Was inspiracja.
https://twitter.com/amybeukenex/status/778176865316040705
Dokumentacja i wsparcie klienta dwa bratanki
Sarah Chambers w swojej prezentacji Documentarians and Support: Work Better Together mówiła o mocy płynącej z połączenia sił działu dokumentacji i wsparcia klienta. Tech Writerzy mogą się wiele dowiedzieć od swoich kolegów z działu supportu, ponieważ to oni rozmawiają codziennie z klientami i znają ich potrzeby. W trakcie swojej pracy zbierają sporą ilość danych, które pozwalają na stwierdzenie w jaki sposób klienci korzystają z produktu oraz pomagają ustalić "wskaźnik samoobsługi" (self-service ratio), czyli jak często użytkownicy sami rozwiązują problemy korzystając z dostępnej dokumentacji. Wskaźnik ten można obliczyć na podstawie liczby wyświetleń dokumentu podzielonej przez liczbę zgłoszonych problemów. Jeśli dokument jest przydatny, liczba problemów powinna maleć. Za punkt odniesienia powinniśmy przyjąć 12 wyświetleń na 1 zgłoszony problem. Sarah pokazała również w jaki sposób w jej firmie zbierane są dane. Zgłaszane problemy są przypisywane do jednej z trzech kategorii: porada (howto), problem (bug), opinia (feedback). Dzięki temu są w stanie określić na co pracownicy wsparcia klienta przeznaczają najwięcej czasu. Oprócz tego prowadzą statystyki, które dokumenty mają najwyższy "wskaźnik samoobsługi". Głównym przekazem prezentacji była zachęta do działania osób odpowiedzialnych za dokumentację i wsparcie klienta we wspólnym celu. Niby wszyscy o tym wiemy, ale w praktyce rzadko tak się dzieje. Może czas to zmienić?
https://twitter.com/amybeukenex/status/778212229091102720
Czego pragną programiści
O tym właśnie opowiadał Michael Meng w swoim wystąpieniu zatytułowanym API documentation: Exploring the information needs of software developers. Wielu uczestników uznało je za jedno z najlepszych jakie miały miejsce podczas konferencji. Michael podzielił się z nami wynikami badań, które zostały przeprowadzone na programistach korzystających z dokumentacji do API. Ich celem było dowiedzieć się jakich informacji programiści szukają kiedy uczą się nowego API i próbują wykonać zadania programistyczne. W pierwszej fazie testów, zespół Michaela przeprowadził rozmowy z dwudziestoma programistami, a następnie stworzył ankietę, w której wzięło udział kolejnych 110 programistów. W drugiej fazie testów została przyjęta inna strategia. Zamiast zadawać uczestnikom pytania, poproszono ich o wykonanie kliku prostych zadań przy użyciu API, którego nie znali. Następnie zespół badawczy obserwował w jaki sposób programiści podeszli do swoich zadań, i które fragmenty dokumentacji dostarczonej wraz API wykorzystali. Okazało się, że główną rzeczą jakiej programiści w niej szukali były próbki kodu. Pozostałe informacje były przez nich pomijane. W tym miejscu można by się pokusić o dobrze wszystkim znane stwierdzenie "i tak tego nikt nie czyta" 😉 Świetna prezentacja wypełniona dużą ilością przydatnych informacji z dziedziny testowania użyteczności.
https://twitter.com/baitman/status/778222644349075456
Szybcy jak błyskawica i niekonferencyjni
W poniedziałek i we wtorek po lunchu, scena zamieniała się na 30 minut w swego rodzaju Speakers' Corner. Każdy mógł mieć swoje 5 minut, dosłownie. Zasada była prosta - kto pierwszy ten lepszy. Wystarczyło wpisać się odpowiednio wcześnie na listę wywieszoną w holu, żeby poprowadzić szybką prezentację (lightning talk) na wybrany przez siebie temat. Chętnych nie brakowało - wolne miejsca rozeszły się bardzo szybko, a ci którzy za długo się zastanawiali, z nadzieją wpisywali się na listę rezerwowych. W trakcie dwóch sesji przez scenę przewinęło się naprawdę sporo osób, które poruszały przeróżne tematy, takie jak darmowy mechanizm wyszukiwania stworzony przez firmę Algolia, rola sztucznej inteligencji w dokumentacji i przepowiednie powrotu nowego, mądrzejszego Clippy'ego, inicjatywa związana z testowaniem dokumentacji oraz w jaki sposób powinniśmy opowiadać o tym co robi osoba tworząca dokumentację, żeby nasi rozmówcy nie pomyśleli, że to najnudniejszy zawód świata. Ponadto mogliśmy się dowiedzieć o inicjatywie zbudowania społeczności dokumentacyjnej na Ukrainie, która rozpoczęła się od utworzenia branżowego bloga oraz o organizacjach związanych z komunikacją techniczną działających w Europie. Nieskromnie wspomnimy, że nasz portal również został ujęty w tym zestawieniu 😊 Sesje z szybkimi wystąpienami okazały się bardzo trafionym pomysłem. Zdecydowanie zwiększyły dynamikę konferencji.
Organizatorzy zadbali również o uczestników, którzy nie byli w stanie cały dzień słuchać prezentacji. W poniedziałek i wtorek, w godzinach od 13:00 do 17:00, w osobnej sali odbywały się sesje w formule niekonferencji (unconference). Były to luźne spotkania, w których uczestnicy podejmowali dyskusję na temat ustalony przez organizatora sesji bez wyznaczania konkretnego mówcy, którego słucha reszta uczestników. Sesje cieszyły się zróżnicowanym powodzeniem, mocno uzależnionym od prezentacji, które były prowadzone w tym czasie w sali obok. Była to ciekawa propozycja odskoczni od głównych wydarzeń, jednak czasami przegrywała z przyciągającym tematem wystąpienia.
Garść ogólnych spostrzeżeń
W tym roku organizatorzy postanowili umiejscowić konferencję w sali balowej Autoklub České republiky. Według nas był to bardzo dobry wybór, zarówno pod względem lokalizacji (w pobliżu centrum i dworca autobusowego) jak i panującego we wnętrzu klimatu. Dodatkowym plusem była także dbałość o to, żeby uczestnicy mieli nie tylko odpowiednią ilość miejsca, ale także siły podczas zaplanowanych atrakcji. Rano można było zjeść śniadanie, a w okolicach południa solidny lunch. Oprócz tego były również przerwy kawowe, podczas których serwowano przekąski. Wszystko było smaczne i, co najważniejsze, wliczone w cenę wejściówki.
Proces rejestracji przebiegł bardzo sprawnie. Oprócz identyfikatora, uczestnicy dostawali w pakiecie koszulkę konferencyjną. Ciekawostką był zorganizowany na Twitterze konkurs na najlepiej ozdobiony identyfikator. Zgłoszeń możecie szukać za pomocą hashtaga #wtdbadge.
Warto wspomnieć o tym, że podczas prezentacji organizatorzy dbali o to, żeby wszystko przebiegało według planu. Ciekawym rozwiązaniem było użycie gongu, który sygnalizował koniec przerw. Dzięki temu uczestnicy byli bardziej zdyscyplinowani. Przywodzi to na myśl efekt dzwonka w szkole 😉
Niestandardowym rozwiązaniem był całkowity brak stoisk firmowych. Prawdopodobnie formuła konferencji nie przewiduje takiego elementu. Kolejną rzeczą jaką zauważyliśmy, był brak czasu na pytania po prezentacjach. Być może organizatorzy stwierdzili, że lepszy efekt można osiągnąć zadając pytania prowadzącemu w cztery oczy.
Jedynym uciążliwym niedociągnięciem było połączenie Wi-Fi, które często się rozłączało. Wiadomo, że głownym celem udziału w konferencji jest słuchanie wystąpień, jednak porządne łącze podczas takiego wydarzenia to podstawa.
Podsumowanie
Poziom prezentacji był, jak często w przypadku takich imprez, zróżnicowany. Organizatorzy udostępnili już nagrania wystąpień, dzięki czemu możecie sami ocenić na ile są dla Was przydatne. Pod względem organizacji nie ma się za bardzo do czego przyczepić, no może poza wspomnianym wyżej problemem z Wi-Fi 😉 Atmosfera była pozytywna, a networking bardzo udany. Umiejscowienie konferencji w mieście takim jak Praga było kolejnym powodem, dla którego warto było wziąć w niej udział. Dla nas ważne było również to, że mogliśmy spotkać specjalistów z krajów takich jak Węgry czy Rumunia, które, podobnie jak Polska, są "rynkami wschodzącymi" dla komunikacji technicznej. Biorąc pod uwagę wszelkie aspekty konferencji, zdecydowanie polecamy to wydarzenie, zwłaszcza, że stosunek jakości do ceny jest bardzo dobry.
Na koniec odsyłamy Was do galerii zdjęć. Być może będzie to dodatkowa zachęta do wzięcia udziału w przyszłorocznej edycji Write the Docs. Na tę chwilę nie wiadomo jeszcze gdzie się odbędzie. Różne miasta są brane pod uwagę, a wśród, jak się dowiedzieliśmy, także Kraków. Jeśli chcecie trzymać rękę na pulsie to możecie śledzić profil Write the Docs na Twitterze i dołączyć do ich kanału Slack.
P.S. Nie tylko my pokusiliśmy się o podsumowanie Write the Docs Europe 2016. Relacje innych uczestników w języku angielskim dostępne są tu, tu i jeszcze tu. A jeśli nadal Wam mało, to możecie dodatkowo zajrzeć do notatek z prezentacji (też w języku angielskim), które znajdziecie pod tym i tym linkiem.