056.3 Lecke 1
Tanúsítvány: |
Open Source Essentials |
---|---|
Verzió: |
1.0 |
Témakör: |
056 Kollaboráció és kommunikáció |
Fejezet: |
056.3 Kommunikációs és kollaborációs eszközök |
Lecke: |
1/1 |
Bevezetés
Számos nyílt forráskódú projektnek vannak aktív résztvevői a világ minden tájáról. Az együttműködés többnyire a “virtuális térben” történik, és az érintettek gyakran különböző országokban, kontinenseken és időzónákban vannak, ráadásul általában különböző anyanyelvűek. Ez azt jelenti, hogy attól, hogy a világ bármely pontján is tartózkodunk, hozzájárulhatunk egy nyílt forráskódú projekthez, függetlenül az országunktól vagy az anyanyelvünktől!
Bár ez a sokszínűség rendkívül kifizetődővé teszi a nyílt forráskódú projektekhez való hozzájárulást, mivel bővítheti a tevékenységi körünket és sokat tanulhatunk, azonban nagy kihívást jelent a kommunikáció és a koordináció. A hatékony és eredményes kommunikáció kulcsfontosságú minden nyílt forráskódú projekt sikeréhez és fenntarthatóságához. A jó kommunikáció biztosítása érdekében a nyílt forráskódú projektek olyan struktúrákat hoztak létre és számos olyan eszközt használnak, amelyek megkönnyítik a hozzájárulást és hatékonyabbá teszik az együttműködést.
További kihívást jelent, hogy a nyílt forráskódú projektek, amelyeket gyakran főként önkéntesek irányítanak, a részvétel szempontjából fluktuációval néznek szembe. Az emberek élete és hobbija változik, és egyesek elveszíthetik érdeklődésüket, vagy egyszerűen kifutnak az időből. Lehet, hogy évekig hozzájárulunk egy nyílt forráskódú projekthez, de lehet, hogy már nincs elég időnk az önkéntes munkára, amikor munkahelyet váltunk, megnősülünk vagy gyereket nevelünk.
Ezért a megfelelő eszközökkel történő hatékony kommunikáció biztosítása mellett a nyílt forráskódú projekteknek biztosítaniuk kell a tudás megőrzését és megosztását, hogy elkerüljék azt, hogy “újra fel kelljen találni a kereket”. Az információ megőrzése segít a közreműködőknek abban is, hogy tanuljanak más közreműködők múltbeli hibáiból, és ők már ne kövessék el ugyanazokat a hibákat.
Ez a lecke bemutatja a nyílt forráskódú projektben való együttműködés általános eszközeit, és megismertet minket a nemzetközi közösségben való kommunikáció módjaival. Felfedezhetjük, hogy mindenki számára elérhető az a lehetőség, hogy megtegye első hozzájárulását!
A kommunikáció és az információmegosztás példájaként a LibreOffice-t fogjuk megvizsgálni. A LibreOffice egy nyílt forráskódú irodai csomag, amely több, mint száz nyelven érhető el. Végfelhasználói az alkalmi otthoni felhasználóktól a nagy kormányzatokig és vállalatokig terjednek. Hasonlóképpen, széles a közreműködők skálája is — nem csak fejlesztők, hanem honosítók, dokumentációs szerzők, marketingesek, minőségbiztosítási mérnökök, infrastruktúra-adminisztrátorok, grafikusok és UX-tervezők, és még sokan, sokan mások.
Más szóval: A LibreOffice esetén, ahogy sok más nyílt forráskódú projekt esetén is, a saját képességeinket és tehetségünket azon a területen hozhatjuk be, ahol jól érezzük magunkat. Nem kell feltétlenül technikailag képzett embernek vagy fejlesztőnek lennünk — a kreativitásunkat és művészi tehetségünket vagy nyelvtudásunkat is bevethetjük. A projekt elindított egy weboldalt is, amely bemutatja a különböző hozzájárulási területeket: https://whatcanidoforlibreoffice.org. A LibreOffice tehát szépen illusztrálja a közösségi munka számos aspektusát.
A kommunikáció formái
Mielőtt a kommunikációs eszközök részleteivel foglalkoznánk, fontos megérteni, hogyan működik a kommunikáció általában, mivel ezek a szempontok meghatározzák az eszközök kiválasztását.
A nyílt forráskódú projektek a kommunikáció két különböző fő módját élvezik. A szinkron kommunikációval az emberek egyszerre kommunikálnak. Ilyen például természetesen a közvetlen beszélgetés, de a videokonferencia vagy a telefonhívás is. Az aszinkron kommunikációval az emberek különböző időpontokban kommunikálnak. Ilyen például az e-mail és az SMS, de a postai levél vagy a telefax is.
Ezt a különbséget azonban nem mindig könnyű megérteni. Például egy mobiltelefonon lévő messenger alkalmazás, mint a WhatsApp, a Telegram, a Signal vagy az Element technikailag aszinkron kommunikációs mód. Ha azonban mindkét beszélgetőpartner egy időben online van, és azonnal válaszol, akkor közvetlen beszélgetésbe kezdenek.
Ez a példa azt mutatja be, hogy a kommunikáció egy része attól is függ, hogy az emberek hogyan használják az eszközeiket, és milyen elvárásaik vannak. Minden feladat más-más kommunikációs eszközkészletet igényelhet. A következő szakaszok részletesen kifejtik ezeket a gondolatokat.
Szinkron kommunikáció
A szinkron kommunikáció nagyon hatékony, de egyben nagyon igényes módja a kommunikációnak. Egyszerre hozza össze az embereket ugyanabban a fizikai vagy virtuális térben.
A közvetlen találkozó ideális arra, hogy interaktív módon beszéljük meg a dolgokat, ahelyett, hogy hosszú, félreértések kockázatával járó e-maileket küldenénk. Képzeljük el, hogy szeretnénk többet megtudni egy nyílt forráskódú projektről, és megismerni a közösség tagjait. Az e-mailek és a weboldalak segíthetnek a bemutatkozásban, és alacsonyabb a belépési korlát, de igazán tartalmas első benyomás akkor alakul ki, ha személyesen is beszélhetünk valakivel — általában ezek a közvetlen interakciók azok, amelyek lenyűgözik az embereket egy nyílt forráskódú projekt esetén, és arra késztetik őket, hogy ők is hozzájáruljanak.
A szinkron találkozók az ismerkedés mellett arra is kiválóak, hogy interaktív módon beszéljük meg a dolgokat, például konfliktusok vagy problémák esetén, vagy amikor egy negatív üzenetet kell megosztani.
A hátránya az, hogy a nemzetközi projektek olyan kihívással szembesülnek, amelyet a technológia nem tud leküzdeni: az időzónák. Ha a közreműködők különböző kontinenseken élnek, akkor nagyon nehéz lesz olyan időpontokat találni, amelyek mindenkinek megfelelnek. Lehet, hogy valaki Ausztráliában épp akkor ébred fel, amikor valaki Európában már közel van ahhoz, hogy befejezze a munkát. További kihívást jelent, hogy egyesek csak éjszaka vagy hétvégén tudnak dolgozni, míg mások inkább munkanapokon.
Ráadásul az angol nyelvet nem mindenki beszéli folyékonyan, és még nem állnak rendelkezésre széles körben elérhető élő fordítási eszközök, ami további akadályt jelenthet.
Ennek ellenére a videokonferencia a nyílt forráskódú projektek egyik leggyakoribb kommunikációs eszköze. A LibreOffice projekt, amely példaként szolgál ehhez a leckéhez, rendszeresen tart online megbeszéléseket a közösséggel, például a fejlesztőkkel, a marketinggel, az infrastruktúrával, a minőségbiztosítással, a felhasználói élménnyel és a tervezéssel.
Aszinkron kommunikáció
Az aszinkron kommunikáció lehetővé teszi, hogy a nekünk megfelelő időben és sebességgel vegyünk részt a beszélgetésben. A legismertebb példa erre valószínűleg az e-mail: akkor válaszolhatunk egy üzenetre, amikor csak akarunk, akár a következő percben, a következő napon vagy a következő órában.
Aszinkron kommunikáció esetén a tartalom általában írott, ami ráadásul lehetővé teszi a gépi fordítást. Ez segít elolvasni és megérteni az anyanyelvünktől eltérő nyelven írt üzeneteket, és még a válaszunkat is lefordítja.
Ezenkívül a már leírt tartalom sokkal könnyebbé teszi a tudás megőrzését és a dokumentáció elkészítését. Képzeljük el, hogy egy szoftver adott funkciójának használatáról szeretnénk támogató dokumentumot írni. Ha telefonon magyarázzuk el egy felhasználónak, sokkal nehezebb lesz a beszédből megfelelő dokumentációs oldalt készíteni, mintha írott szövegben magyaráztuk volna el az eljárást.
Belső vs külső kommunikáció
Végül, de nem utolsósorban a kommunikáció a címzettektől is függ, azaz attól, hogy belső vagy külső címzettről van-e szó. Másképp írunk meg egy belső, technikai jellegű közleményt a rendszergazdáknak, mint egy sajtóközleményt, amelyet több száz újságírónak küldünk el. Ne feledjük azonban, hogy egy nyílt forráskódú projekt jellegéből adódóan az olyan kommunikáció, amelyet esetleg nem kifejezetten nyilvános közönségnek szánnak, mégis publikusan elérhető lesz, például a levelezőlisták archívumában (a LibreOffice esetében a https://listarchives.documentfoundation.org/).
Kommunikációs eszközök
A kommunikáció ezen különbségek általános szempontjait szem előtt tartva a következő fejezetekben számos olyan kommunikációs eszközzel ismerkedhetünk meg, amelyeket általában nyílt forráskódú projektekben használnak.
E-mail, levelezőlisták és hírlevelek
Az egyik első eszköz, amellyel akkor találkozunk, amikor részt veszünk egy nyílt forráskódú projektben, a “klasszikus” e-mail. Sok projekt levelezőlistákat üzemeltet, amelyek lényegében e-mail terjesztési listák: egyetlen e-maillel több száz vagy akár több ezer feliratkozót érhetünk el, akiket érdekelnek bizonyos témák.
A levelezőlisták minden nyílt forráskódú projekt esetén a legrégebbi ismert eszközök közé tartoznak, és a projekten belüli koordinációra, valamint a felhasználókkal való kapcsolattartásra is használják őket. Ha kérdésünk van a szoftverrel kapcsolatban, vagy hibát szeretnénk jelenteni a programban, nagy az esélye annak, hogy van olyan levelezőlista, amely lehetővé teszi ezt. A LibreOffice közösség például számos nemzetközi és helyi levelezőlistát kínál különböző témákra (https://www.libreoffice.org/get-help/mailing-lists/), a felhasználói támogatástól kezdve a fejlesztői megbeszéléseken át az infrastruktúra koordinálásáig (A LibreOffice levelezőlistáinak weblapja).
A későbbi felhasználás érdekében minden elküldött üzenetet általában eltárolnak egy nyilvános levelezőlista-archívumban is. Az egyszer elküldött üzenetet már nem lehet egykönnyen törölni. Egy gyakori mondás szerint “Az internet sosem felejt”. Ezért ajánlatos óvatosan bánni azzal, amit írunk, mert valószínűleg nem tudjuk visszavonni. Vannak például, akiknek az aláírásukban szerepel a privát címük vagy telefonszámuk, vagy bizalmas dokumentumokat küldenek csatolmányként, amit gondosan kerülni kell.
A levelezőlisták egyik hátránya, hogy kezelésük a levelezőprogramban nem mindig egyszerű. Az üzenet bizonyos elemei, például a tárgy előtagja alapján úgynevezett szűrőket (filter) kell létrehozni. A nagy mennyiségű e-mail kezelésének finomságai akadályokat jelenthetnek a tapasztalatlan felhasználók számára — különösen, ha egy egyszeri üzenetről van szó. Ezért egyre több projekt tér át a fórumokra, amelyekről hamarosan lesz szó.
A levelezőlista egy speciális formája a hírlevél. Ha naprakészek akarunk maradni a projekt legújabb fejlesztéseiről és értesülni az új szoftverkiadásokról, akkor feliratkozhatsunk a hírlevélre, és ha valami fontos történik, kapunk egy e-mailt.
Fórumok
Attól eltekintve, hogy a levelezőkliensben problémás a levelezőlisták kezelése, az e-mail másik hátránya, hogy egyre több ember, különösen a fiatalabb generáció már nem annyira kedveli a kommunikáció ezen formáját. Emiatt és más okok miatt egyre több nyílt forráskódú projekt helyezi át a kommunikációját fórumokra (discussion forum). Az általános elképzelés nagyon hasonló az emailhez: minden fórumnak vannak különböző kategóriái, amelyekben meghatározott témákról lehet vitát folytatni, úgynevezett thread-ek (szálak). Az emailhez hasonlóan a fórumon is kapcsolatba léphetünk a nyílt forráskódú projekttel, és koordinálhatjuk a tevékenységeket, javaslatokat tehetsünk a projekt irányára vonatkozóan, valamint végfelhasználóként jelenthetjük a hibákat.
A fórumra feltöltött üzenetek általában a nagyközönség számára is láthatóak, akárcsak egy levelezőlistán; de a fórum konfigurációjától függően a fórum tartalma később is szerkeszthető vagy törölhető. A fórumok használhatósága, különösen a tapasztalatlan felhasználók számára, gyakran egyszerűbb, mint a levelezőlistáké. A LibreOffice projekt több levelezőlistáját kezdte fórummá alakítani (https://community.documentfoundation.org/), és azóta megnőtt a vitákban résztvevők száma.
Azonnali üzenetek és chat platformok
Egy másik módja a nyílt forráskódú közösséggel való kapcsolatfelvételnek az azonnali üzenetek és a chatplatformok. Az olyan népszerű eszközök, mint a WhatsApp, a Telegram, a Signal és a Matrix elterjedésével szinte mindenki telepítette már valamelyik népszerű alkalmazást az eszközére, ami sokkal alacsonyabbá teszi a belépési korlátot. Az azonnali üzenetek a fiatalabb generáció körében is sokkal népszerűbbek, mint az e-mail vagy a fórumok. Ezért nem meglepő, hogy manapság sok nyílt forráskódú projekt alkalmazza őket.
A csevegések résztvevői üzeneteket írnak, amelyeket az összes többi résztvevőnek elküldenek, hasonlóan az e-mailhez. A csevegőplatformtól függően az üzenetet formázással, grafikákkal és mellékletekkel lehet gazdagítani.
Szerkezetileg az üzenőalkalmazások a fórumokhoz vagy az e-mailekhez hasonlóan szerveződnek. Számos csoport vagy csatorna áll rendelkezésre, így a minket érdeklő témákról szóló beszélgetésekhez csatlakozhatunk. Az üzenetek általában szerkeszthetők vagy törölhetők, és gyakran vannak olyan, csak bejelentésre szolgáló csatornák is, amelyek az e-mail formátumú hírlevelekhez hasonló funkcióval rendelkeznek.
Az azonnali messenger (üzenetküldő) alkalmazások egyik hátránya, hogy az emberek általában a telefonjukra telepítik őket, így minden elküldött üzenetről értesítést kapnak. Ez gyorsan információ túlcsordulásba vagy “riasztási fáradtságba” (alert fatigue) torkollhat. Megfelelő konfigurációval azonban kordában tarthatók ezek az értesítések.
Egy másik hátránya, hogy sok messenger alkalmazás zárt és egy gyártó kezében van. Ez megnehezíti a tudás hosszú távú megőrzését, ha az adatok nem szabadon hozzáférhetők.
Önálló, szövetségi és központosított kommunikáció
A nyílt forráskódú projektek nyíltan, nyílt szabványok és nyílt eszközök alapján működnek. Ezért kritikus fontosságú annak megértése, hogy a különböző eszközöket hogyan tervezték meg az interoperabilitás szempontjából. A lehetőségek három fő kategóriába sorolhatók.
A stand-alone (önálló) platform egy közösség elszigetelt felülete. Ilyenek például a fórumok vagy a wikik, amelyek általában nem kapcsolódnak más projektek példányaihoz.
A decentralizált vagy federated (szövetségi) rendszerek minden közösség számára külön-külön működnek, de kapcsolódhatnak egymáshoz. Egy példa erre az e-mail, mert egy helyi e-mail szerver a világ bármelyik másik e-mail szerverére küldhet e-mailt. További példák a Nextcloud és az ownCloud, amelyek képesek “megosztani” a fájlmegosztásokat más szerverekkel; valamint az Element messenger szolgáltatás, amellyel más szerverek felhasználóival lehet kommunikálni. Ugyanezek az elvek érvényesek a Mastodon közösségi hálózatra is.
Mind az önálló, mind az elosztott platformoknak van egy hatalmas előnye: a nyílt forráskódú projekt továbbra is teljes mértékben ellenőrzi a tartalmat és a funkciókat. Az ilyen rendszerben tárolt összes tudás a nyílt forráskódú közösség tulajdona marad, és nem kerül harmadik felek kezébe.
A centralizált rendszert viszont egy szolgáltató működteti, és nem lép kapcsolatba harmadik felekkel. Klasszikus példák erre a közösségi platformok, mint a Facebook vagy az Instagram, vagy az messenger alkalmazások, mint a WhatsApp vagy a Telegram. Minden tartalom a külső szolgáltató szerverein tárolódik, és az ő feltételei vonatkoznak rá.
Ha aktívan részt veszünk egy nyílt forráskódú közösségben, valószínűleg mindhárom lehetőséggel találkozunk. A központosított rendszerek kiválóan alkalmasak az emberek elérésére, mivel gyakran népszerűek és nagy felhasználói bázissal rendelkeznek. A projektben végzett tényleges munkához azonban a közösség ellenőrzése alatt álló, szövetségi vagy önálló rendszer a legjobb.
Kollaborációs eszközök
A kommunikációs és a kollaborációs eszközök közötti különbségtétel nem mindig egyértelmű. E lecke szempontjából a kommunikációs eszközök fő célja, hogy lehetővé tegyék a különböző résztvevők közötti általános kommunikációt, míg a kollaborációs eszközök fő célja, hogy segítsék az emberek együttműködését.
A megfelelő kollaborációs eszközök lehetővé teszik a fájlok tárolását, a valós idejű együttműködést dokumentumokon, a dokumentumverziók és a szoftver releasek közötti változások nyomon követését, és még sok minden mást. Míg az e-mail vagy a fórumok általános célú tárolásra szolgálhatnak, a speciális eszközök könnyebben hozzáférhetővé teszik a tudást és sokkal hatékonyabbá az együttműködést.
Más szóval, ezek speciális eszközök speciális feladatokra. Ha hozzá szeretnénk járulni egy nyílt forráskódú projekthez, nagyon hamar találkozunk majd velük.
Wikik
Az együttműködés egyik legrégebbi és legnépszerűbb eszköze a wiki. A wiki, amelyet különösen a Wikipedia tett híressé, lehetővé teszi a felhasználók számára, hogy együtt dolgozzanak egy olyan weboldalon, amely több dokumentumból vagy “cikkből” áll össze. Ezeket különböző kategóriákba lehet csoportosítani, nyelv szerint szűrni, és tartalmazhatnak formázásokat, táblázatokat és képeket.
A wikiket gyakran használják tudásbázisként, amihez mindenki hozzájárulhat. Ha egy nyílt forráskódú projekthez szeretnénk valamilyen tartalommal hozzájárulni, a legegyszerűbb mód a wiki szerkesztésében való részvétel. Átvehetjük a meglévő tartalmat, és lefordíthatjuk azt az anyanyelvünkre, szerkeszthetjük és frissíthetjük a meglévő cikkeket, vagy létrehozhatunk új tartalmat. A LibreOffice projekt wikijében (https://wiki.documentfoundation.org) marketinganyagokat, vezetőségi ülések jegyzőkönyveit, telepítési utasításokat és konferenciák terveit találhatjuk meg, ráadásul több nyelven (LibreOffice Wiki).
Sok nyílt forráskódú projekt a dokumentációját és a programjukba integrált súgórendszert is egy wikiben tárolja. Ezen kívül egy oldal régi verzióit — az úgynevezett revíziókat — archiválják a későbbi hivatkozás céljából.
Bár a wikik is képesek projektfájlok tárolására, erre a célra léteznek jobb eszközök, amint azt ebben a leckében meg fogjuk tanulni.
Bug és issue trackerek
Egy másik gyakran használt eszköz egy nyílt forráskódú projektben a bug tracker (hibakövető), más néven issue trackers (problémakövető). Ha problémát fedezünk fel a szoftverben, vagy egy új funkciót szeretnénk javasolni, gondolhatunk arra, hogy egyszerűen küldünk róla egy e-mailt. Egy olyan dedikált eszközzel azonban, mint a bug tracker, strukturáltan megadhatjuk a probléma reprodukálásához szükséges összes információt és lépést, ami megkönnyíti a fejlesztők számára a probléma reprodukálását. Az ilyen strukturált jelentést hibajelentésnek (bug report) nevezzük.
Ráadásul az információ nem vész el, és a projekt nem feledkezik meg a problémáról; a megfelelő személyhez rendelhetik azt, és láthatjuk, hogy hány hibát dolgoznak fel vagy javítanak ki.
A LibreOffice projekt egy olyan bug trackert biztosít, amely mindenki számára nyitott (https://bugs.documentfoundation.org).
Helpdeskek és ticketing rendszerek
Nagyon hasonló eszköz a helpdesk vagy ticketing system. Ennek középpontjában kevésbé áll a szoftverproblémák bejelentése, hanem inkább a felhasználók segítése mindenféle problémával és kéréssel kapcsolatban, például a projekt weboldalával összefüggésben.
A klasszikus helpdesk egy ügyfélszolgálati forródrót. Az ügyfél telefonál és jelzi a problémáját, amelyből ticket (jegy) lesz. A helpdesk rendszer munkafolyamata általában a prioritások, az eszkalációs szintek és a válaszidő körül forog.
Nem minden nyílt forráskódú közösség biztosít ilyen rendszert, de sok kereskedelmi vállalat igen. A LibreOffice projektben például van egy jegyrendszer az infrastruktúra számára a szerverekkel és webes szolgáltatásokkal kapcsolatos problémák bejelentésére.
Tartalomkezelő rendszer (Content Management System — CMS)
Az együttműködés másik fontos eszköze a tartalomkezelő rendszer (CMS). Amint a neve is mutatja, ez segít a tartalom kezelésében, leginkább a weboldalak esetében. Ha hozzá szeretnénk járulni egy projekt weboldalának tartalmához vagy tervezéséhez, akkor érdemes megismerkednünk a CMS-sel.
A wikikhez hasonló CMS-rendszerek segítenek a tartalom kategóriák és nyelvek szerinti strukturálásában. Gyakran biztosítanak WYSIWYG (“what you see is what you get`”, “amit látunk, azt kapjuk”) szerkesztőt, és mindent megfelelő sablonba ágyaznak: a címek, címsorok, az oldal elrendezése és a menübejegyzések automatikusan elkészülnek, így teljes mértékben a tartalomra koncentrálhatunk. Ráadásul az oldal újratervezése esetén a tartalom nem tűnik el, hanem az új sablonhoz igazodik.
Dokumentumkezelő rendszer (Document Management System — DMS)
A dokumentumkezelő rendszer nem tévesztendő össze a tartalomkezelő rendszerrel. Míg egy CMS-t arra terveztek, hogy a tartalmat egy előre meghatározott sablonban jelenítse meg, például egy weboldal esetén, addig egy DMS-t dokumentumok, például szerződések, számlák, bizonylatok, e-mailek és mindenféle egyéb levelezés kezelésére használnak.
Egy másik különbség az, hogy a CMS-t gyakran használják nyilvános prezentációk esetén, míg a DMS-t többnyire olyan belső dokumentumok kezelésére használják, amelyeket nem a nagyközönségnek szánnak.
Egy nyílt forráskódú projektben kevésbé valószínű, hogy közreműködőként találkozunk a dokumentumkezelő rendszerrel, mivel az gyakran speciális szerepkörök, például a könyvelés vagy a jogi osztály számára van fenntartva.
Forráskód menedzsment (Source Code Management — SCM)
Ha fejlesztőként veszünk részt egy nyílt forráskódú projektben, az egyik legfontosabb eszköz, amellyel talákozunk, a forráskód-menedzser platform. Az SCM-eket a dokumentáció szerzőinek wikijéhez hasonlóan a szoftverfejlesztők használják a kóddal való közös munkára.
A történelmi SCM-ek közé tartozik a CVS és a Subversion, de manapság leginkább a Git-et használják, többek között a LibreOffice közösség is (https://git.libreoffice.org/). Ezek az eszközök parancssorban is elérhetők, de grafikus felületük is van, hogy (különösen a kezdők számára) megkönnyítsék a kezelésüket.
A forráskód-kezelő platformok nyomon követik az egyes fájlok különböző verzióit, kezelik a kód módosításait és szerkesztéseit, rögzítik, hogy ki milyen módosítást végzett, és ideális esetben teljes történetet adnak a szoftver fejlesztéséről.
A fejlesztők “kicheckolhatják” (check out) a szoftver egy adott állapotát, helyben dolgozhatnak rajta, például egy hiba kijavításával vagy egy új funkció megvalósításával, majd kérhetik, hogy ezt a változtatást egy úgynevezett merge request, más néven pull request segítségével a szoftver fő fejlesztési vonalához adják hozzá. A merge vagy pull request elfogadása “összevonja” (merge) az egyik szerző által elvégzett változtatásokat a fő kóddal.
Vannak olyan központi platformok (GitHub és GitLab), amelyek integrálják az SCM-et a wikivel, a problémakövetéssel és más kollaboratív eszközökkel.
A forráskód-menedzser platformok nem korlátozódnak szigorúan a programkódra! Például ezen a leckén is egy Git repositoryban dolgoztak közösen a résztvevők.
Dokumentáció
Minden nyílt forráskódú projekt sikerének kulcsa a megfelelő dokumentáció, ideális esetben több nyelven. A LibreOffice projekt naprakész könyveket, útmutatókat és referenciakártyákat (https://documentation.libreoffice.org) biztosít a szoftveréhez, valamint egyedi segédoldalakat az egyes funkciókhoz (https://help.libreoffice.org).
Általánosságban elmondható, hogy a dokumentációnak különböző fajtái vannak, amelyeket a következő fejezetekben tárgyalunk.
Felhasználói dokumentáció
A legismertebb a végfelhasználóknak szóló dokumentáció, amely elmagyarázza, hogyan kell használni a szoftvert. Ha nem ismerjük a program valamely funkcióját vagy tulajdonságát, a dokumentáció — amely az egyszerű súgóoldalaktól a teljes könyvig terjedhet — az első hivatkozási pont.
A dokumentációs weboldal, ahol a szoftver használatát magyarázzák el, gyakran az egyik leglátogatottabb weboldal a termék weboldal mellett, amely áttekintést nyújt a szoftverről és annak közösségéről.
Adminisztrátori dokumentáció
Nagyobb környezetekben, például vállalati telepítések esetén a rendszergazdai dokumentáció minden lényeges információt megad a szoftver nagyobb léptékű telepítéséhez. Ez magában foglalja a felhasználói adatbázisokhoz és fájltárolókhoz való csatlakozást, a központi konfigurációkezelést és a frissítések kezelését.
Fejlesztői és architektúra dokumentáció
A dokumentáció egy másik kategóriája a fejlesztőket célozza meg, és fejlesztői dokumentációnak vagy architektúra dokumentációnak nevezik. Ha fejlesztőként szeretnénk hozzájárulni egy program kódjához, ez a dokumentáció tájékoztat minket a szoftver architektúrájáról, a kódolási szabványokról, valamint a szoftveren való munkavégzéshez használt eszközökről és munkafolyamatokról.
A LibreOffice projekt közzétett egy fejlesztői útmutatót a wikin, hogy segítse az érdeklődő fejlesztőket a közösséghez való csatlakozásban (https://wiki.documentfoundation.org/Documentation/DevGuide).
Gyakorló feladatok
-
Miért kell különösen a nyílt forráskódú projekteknek gondoskodniuk a megfelelő kommunikációs és együttműködési eszközökről?
-
Nevezzünk meg egy-egy példát a szinkron és aszinkron kommunikációra!
-
Mi a messenger alkalmazások hátránya és hogyan lehet ezt elkerülni?
-
Nevezzük meg a wiki két funkcióját!
-
Mi a különbség a bug tracker és a helpdesk rendszer között?
-
Mi a különbség a tartalomkezelő és a dokumentumkezelő rendszer között?
-
Mi az önálló vagy szövetségi rendszerek előnye a központosított rendszerekkel szemben?
Gondolkodtató feladatok
-
Mi az egyik fő különbség egy helyi sportklub és egy nemzetközi nyílt forráskódú projekt között?
-
Miért lehet különösen kifizetődő egy nyílt forráskódú projekthez való hozzájárulás?
-
Melyik bug tracker szoftvert használja az Ubuntu projekt?
-
Mi a neve annak a weboldalnak, ahol a Linux kernel levelezési listái találhatók?
Összefoglalás
Ebben a leckében megismerkedtünk a nyílt forráskódú projektekben való kommunikációra és együttműködésre használt különböző eszközökkel. Láthattuk, hogy mi a különbség a szinkron és az aszinkron kommunikáció, valamint a decentralizált, a centralizált és az önálló eszközök között. Azt is megtudtuk, hogy miért lehetnek hasznosak bizonyos eszközök bizonyos feladatokhoz, annak érdekében, hogy a nyílt forráskódú projekthez való hozzájárulás szórakoztató és kifizetődő legyen.
Válaszok a gyakorló feladatokra
-
Miért kell különösen a nyílt forráskódú projekteknek gondoskodniuk a megfelelő kommunikációs és együttműködési eszközökről?
Egyrészt a világ különböző pontjain lévő csoportokban való együttműködésnek megvannak a maga kihívásai, amelyek kezelésében a megfelelő eszközök segíthetnek. Másrészt az önkéntesek nem biztos, hogy a végtelenségig maradnak, így a tudás megőrzése és megosztása egy másik fontos szempont a kommunikációs és együttműködési eszközök használatában. A hozzájárulások megkönnyítése segíti a projekt fenntarthatóságát.
-
Nevezzünk meg egy-egy példát a szinkron és aszinkron kommunikációra!
A szinkron kommunikáció lehet közvetlen beszélgetés, telefonhívás vagy videokonferencia. Az aszinkron kommunikációra példa az e-mail, az SMS, a postai levél és a fax.
-
Mi a messenger alkalmazások hátránya és hogyan lehet ezt elkerülni?
A telefonra való telepítés után sok értesítést kaphatunk, minden egyes új üzenetről egyet. A megfelelő konfiguráció segíthet ezt elkerülni. További hátrány, hogy sok messenger alkalmazást saját fejlesztésű gyártók futtatnak.
-
Nevezzük meg a wiki két funkcióját!
Cikkek közös szerkesztése és fordítása.
-
Mi a különbség a bug tracker és a helpdesk rendszer között?
A bug tracker egy speciális szoftver tool, amellyel hibákat jelenthetünk be vagy funkciókat kérhetünk a szoftverhez. A helpdesk rendszer a megkeresések támogatására és mindenféle probléma és kérés kezelésére összpontosít, pl. a weboldalon.
-
Mi a különbség a tartalomkezelő és a dokumentumkezelő rendszer között?
A CMS-t a tartalom meghatározott módon vagy sablonban történő bemutatására használják, többnyire nyilvánosan. A DMS-t a meglévő levelezés tárolására használják, többnyire belsős környezetben.
-
Mi az önálló vagy szövetséges rendszerek előnye a központosított rendszerekkel szemben?
A központosított rendszer egy külső szolgáltató ellenőrzése alatt áll. Minden tartalom a külső szolgáltató szerverein tárolódik, és az ő feltételei vonatkoznak rá.
Válaszok a gondolkodtató feladatokra
-
Mi az egyik fő különbség egy helyi sportklub és egy nemzetközi nyílt forráskódú projekt között?
A nyílt forráskódú projektek nem kötődnek egy adott nyelvhez vagy helyhez. A közreműködők különböző országokban és kontinenseken élhetnek, anyanyelvük, sőt, még az időzónák is eltérhetnek. A nyílt forráskódú projektekben végzett tevékenység nagy része virtuálisan történik, nem pedig személyesen.
-
Miért lehet különösen kifizetődő egy nyílt forráskódú projekthez való hozzájárulás?
Nyílt forráskódú projektekben általában sokféle ember vesz részt. Ha együttműködünk velük, tanulhatunk tőlük, új dolgokat fedezhetünk fel, és szélesíthetjük a látókörünket.
-
Melyik bug tracker szoftvert használja az Ubuntu projekt?
Launchpad
-
Mi a neve annak a weboldalnak, ahol a Linux kernel levelezési listái találhatók?
https://lkml.org/