055.3 Lecke 1

A legtöbb nyílt forráskódú projekt fő kimenete a szoftver, így az ilyen projektekhez legalább programozókra, szoftvertervezőkre vagy architektekre, tesztelőkre, release menedzserekre és más kódfejlesztési szakértőkre van szükség. A dokumentáció általában szintén része az ilyen projekteknek, így a közösségnek szerzőkre, szerkesztőkre és véleményezőkre is szüksége van.

Más projektek esetleg nem kódot, hanem más “kézbesítendő termékeket”, például könyvet, művészeti vagy zenei projektet, vagy egy politikai jelentést hoznak létre. A Wikipédia jól ismert példája a szöveges dokumentumokra és médiára összpontosító nyílt forráskódú projektben való együttműködésnek. Ezekben a projektekben szakértőkre van szükség a tervezéshez, a gyártáshoz és a végtermék kiszállításához.

A közösségek számos más általános készségből is profitálnak, mint például a marketing és az igehirdetés, az adminisztráció, a jogi tanácsadás, a művészi tehetség a logók vagy a dokumentációban szereplő ábrák elkészítéséhez, valamint a projekt weboldalának és egyéb kommunikációs eszközeinek karbantartásához szükséges készségek. A nyílt forráskódú projektek szervezhetnek fizikai összejöveteleket, sőt konferenciákat is, ebben az esetben pedig szervezőkre van szükségük, akik életre keltik ezeket az eseményeket.

Az alábbi bekezdésekből megtudhatjuk, hogy milyen típusú készségeket keres egy közösség. Ezek az általános szerepek tovább oszthatók különböző célzott feladatokra. Ilyen feladat például az, hogy egyes írók más írók munkáját szerkesztik.

A programozók között sokféle tapasztalat létezik. Egy egészséges projektnek mindig szüksége van néhány veterán programozóra (vagy senior programozóra), akik jól ismerik a kódot és a kódolási szabványokat, valamint újoncokra (newbie), akik új ötleteket és egyszerű segítséget nyújtanak, például hibajavításokban. Néhány újoncból remélhetőleg a veteránok következő generációja lesz.

A kód minősége gondos ellenőrzést igényel abból a szempontból, hogy mi kerül a felhasználókkal megosztott központi repositoryba. Ezért néhány veterán committer státuszt kap. Ők felelősek a hozzájárulások minőségének, hasznosságának és a kódolási szabványoknak való megfelelésének ellenőrzéséért. Ők rendelkeznek azzal a kiváltsággal, hogy a javasolt kódot elfogadják és hozzáadják a trusted (megbízható) repositoryba. Más közreműködők a kódot a committereknek nyújtják be felülvizsgálatra.

Sok committer és más veterán is mentorálja az új közreműködőket, hogy megtanítsa nekik a szabványokat és gyakorlatokat, amelyek szükségesek ahhoz, hogy kódjuk elfogadásra kerüljön.

Egyes committerek nem értékelik azt ajándékot, amit a közreműködők adnak. Ha a hozzájárulás nem felel meg a minőségi vagy kódolási szabványoknak, a committer egyszerűen elutasíthatja azt. Az elutasítás azonban elriasztja a leendő közreműködőt, és így értékes oktatási lehetőséget veszít el. Ne feledjük, hogy a jó committerek egyben mentorok is. Ezért tippeket adnak a közreműködőnek arra vonatkozóan, hogy hogyan hozhatja a kódot a szabványoknak megfelelő szintre, és idővel együtt dolgoznak. Ha a hozzájárulás valóban használhatatlan, akkor legalább meg kell köszönni a közreműködőnek, és arra kell bátorítani, hogy dolgozzon valami máson a projektben. Fontos segíteni az embereket abban, hogy felfedezzék és fejlesszék a képességeiket. Amikor egy vállalat nyílt forráskódú projektet indít, néha saját munkatársai közül választ committereket, hogy ellenőrizni tudja a projekt irányát és minőségét. Gyakran azonban a vállalatok lehetővé teszik, hogy nem alkalmazottak is committerekké váljanak, ha azok készségesnek és elkötelezettnek bizonyulnak.

A projektvezetők (project lead) kritikus döntéseket hoznak, például arról, hogy milyen új funkciókat támogassanak. Ezeknek a projektvezetőknek gyakran nem kódolási döntéseket is meg kell hozniuk, például arról, hogy hogyan népszerűsítsék a projektet, hogyan oldják meg a nagyobb nézeteltéréseket, és hogyan szerezzenek finanszírozást. A projektvezetők és a committerek szorosan együttműködnek a release menedzserekkel, hogy eldöntsék, mikor stabil a kódbázis és mikor áll készen arra, hogy megosszák a felhasználókkal.

Néhány projektnek egyetlen projektvezetője van, akit gyakran jóindulatú diktátornak (benevolent dictator) neveznek. Ez gyakran egy olyan személy, aki a projektet elindította (jól ismert példa Linus Torvalds a Linux esetén), és aki nagy tekintéllyel, sőt karizmával rendelkezik. A legtöbb projekt azonban inkább a projektvezetők kis bizottságát hozza létre egyetlen jóindulatú diktátor helyett. Még a Linux projekt is áttért a bizottsági megközelítésre.

A projektek arra is felkérhetnek bizonyos közreműködőket, hogy nyújtsanak felhasználói támogatást a projekt fórumain. Az egészséges projekteknek azonban sok hozzáértő felhasználóval kell rendelkezniük, akik támogatják egymást.

Ezt a szakaszt egy nagyon fontos szereppel zárjuk: a közösségi menedzserrel. Ez az a személy, aki felelős a nyílt és konstruktív kommunikáció fenntartásáért, valamint azért, hogy a közösség haladjon a célja felé. A közösségi menedzser tudja, hogyan kell a közreműködőket felvenni és motiválni, a vitákat megoldani, a közösség tagjait megvédeni a visszaélésekkel szemben, és képes egyéb, a közösség egészségének megőrzését szolgáló feladatokat ellátni.

A nyílt forráskódú projektek sok szempontból ugyanazokat a feladatokat tartalmazzák, mint az egyetlen szervezeten belül megvalósuló hagyományos projektek. Például minden kód tesztelést igényel. A nyílt forráskódú projektek azonban bizonyos szempontból különböznek a zárt forrósákódúaktól, ahol csak korlátozott számú ember változtathatja meg a kódot, és ahol a forráskódot gyakran elrejtik a nyilvánosság elől.

A vállalatok például általában képzett minőségbiztosítási (QA) munkatársakat bíznak meg a kód tesztelésével. Sok nyílt forráskódú projekt azonban csak megkéri a felhasználókat, hogy teszteljenek minden egyes kiadást. (A saját fejlesztésű projektek a QA mellett a felhasználókat is bevonják a tesztelésbe.)

Egy másik példa a különbségekre: egy zárt projekt általában fizetett fejlesztőket rendel ki konkrét feladatokhoz, és megmondja nekik, hogy hetente mennyi időt kell a feladatokra fordítaniuk. Néhány nyílt forráskódú projektben olyan közreműködők dolgoznak, akiket a munkáltatójuk fizet, sőt néha maga a projekt alkalmazza őket, és akiknek ugyanúgy feladatokat osztanak ki, mint a védett fejlesztőknek. A legtöbb egészséges projektben azonban a hozzájárulások nagy része önkéntesektől származik, akik csak akkor végzik el a feladatokat, amikor az idejük engedi. Mivel a projekt nem támaszkodik arra, hogy minden önkéntes határidőre befejezi a projektet, előfordulhat, hogy egy nyílt forráskódú kiadás addig késik, amíg a fejlesztők úgy érzik, hogy a funkciók elkészültek, vagy pedig fix időpontokban adják ki, bármilyen, addig elkészült funkcióval.

A kommunikáció mind a szabadalmaztatott, mind a nyílt forráskódú projektek esetében kritikus fontosságú, de gyakran eltérő módon zajlik. A saját fejlesztésű projektek gyakran egy irodában gyűjtik össze a csapatot, és rendszeresen ütemezett megbeszéléseket tartanak egy fejlesztési módszertan, például a SCRUM alapján. Mivel a nyílt forráskódú projektek földrajzilag szétszórtak, az ilyen módszertanok ritkák. Ehelyett a kommunikáció aszinkron módon, online zajlik.

Röviden, a szabad szoftverek és a nyílt forráskódú projektek gyakran ugyanazokat a célokat érik el, mint a szabadalmaztatott projektek, de eltérő módon.

A hibajelentés a szoftverfejlesztés kritikus része, amely saját szerepkörökkel jár. Valakinek figyelemmel kell kísérnie a hibaadatbázist, és ki kell jelölnie a prioritásokat. Ha egy hiba kritikus (és különösen, ha gyengítheti a szoftver biztonságát), akkor egy kompetens szakembert kell megbízni a javításával.

A projektvezetőknek és a közösségi menedzsereknek át kell tekinteniük a projektben való részvételt, és meg kell nézniük, hol vannak hiányosságok. Túl kevesen hajlandóak tesztelni a kódot? Hiányzik a dokumentáció? Túl sok veterán vagy vezető projekttag távozik anélkül, hogy pótolnák őket? A projektvezetők és a közösségi menedzserek a szükséges szerepek betöltéséhez szükséges emberek toborzására összpontosíthatnak.

A nagy projektek projektvezetői és közösségi menedzserei gyakran gyűjtenek mérőszámokat is, hogy fontos dolgokat tudjanak meg, például azt, hogy a jelentős hibákat időben kijavítják-e.

Amint azt egy korábbi szakaszban már kifejtettük, azokat az embereket, akik kódot, dokumentációt vagy más elemeket tesznek a központi repositoryba, úgy hívjuk, hogy contributors (közreműködők). A projekt azon tagjait, akik jóváhagyják a hozzájárulásokat és hozzáadják azokat a repositoryhoz, committers-nek nevezzük. Egyes tagok a szoftverfejlesztés során más általános szerepeket is betöltenek.

Bár a contributor kifejezést általában annak tartják fenn, aki kódot vagy a projekt hivatalos kínálatának más részét fejleszti, mindenki, aki részt vesz a projekt sikerében, valamilyen módon hozzájárul, és ezt meg kell köszönni neki. Ezen nem hivatalos hozzájárulások közé tartozik egy hiba bejelentése, egy kérdés megválaszolása egy fórumon, adományozás vagy pénzgyűjtés, és a projekt népszerűsítése kívülállók számára.

Akárcsak a zárt forráskódú projektek, a nyíltak is megkérdezik a felhasználókat, hogy mit szeretnének a funkciók, a teljesítmény javítása vagy a projekt egyéb változtatásai tekintetében. Ezek a felhasználók fontos hozzájárulásokat tesznek azzal, hogy hangot adnak véleményüknek.

Bár sok nyílt forráskódú projektet lelkes egyének vagy önkéntesek kis csoportjai hoznak létre, általában amikor a projektek nagyobb méretűvé válnak, szervezeti támogatást keresnek. A szervezeti támogatás sokféle formát ölthet. Általában a szervezetek azért járulnak hozzá, mert egy nyílt forráskódú projekt olcsóbban és megbízhatóbban tudja kielégíteni üzleti igényeiket, mintha ugyanazokat a funkciókat saját kódban valósítanák meg újra. Az ingyenes vagy nyílt forráskódú licenc által nyújtott garanciákat sok szervezet nagyra értékeli.

Egyes idealisták nem bíznak a vállalatokban vagy más nagy szervezetekben, és a nyílt forráskódú projekteket inkább teljesen mentesítenék a befolyásuktól. Az évek során ez a meglehetősen leegyszerűsítő hozzáállás egyre kevésbé vált általánossá. A legtöbb nyílt forráskódot támogató úgy véli, hogy a vállalatok és más szervezetek döntő fontosságú alapokat nyújthatnak a nyílt forráskódú projektek számára.

Sok nyílt forráskódú projekt egy szervezeten belül indul, és akár saját, zárt kódon is alapulhat, amit a vállalat nyílttá tesz. A pénzszerzés érdekében a vállalat dönthet úgy, hogy szilárdan ellenőrzi a projektet, és nyílt és védett részekre bontja azt: ezt nevezzük open core modellnek. Sok projektalapító nyílt forráskódúként indul, de egy céget alapít köré, amely vagy alkalmazza, vagy nem alkalmazza az open core modellt.

Más projektek arra törekednek, hogy ne egyetlen vállalat szabja meg az irányt. A függetlenség fenntartásához általában több szervezeti támogatót kell szerződtetni, hogy senki se legyen elég erős ahhoz, hogy diktatórikus döntést hozzon.

Hogyan támogatják a szervezetek a nyílt forráskódot? Ahogy korábban említettük, sokan fizetett munkatársakat küldenek a projektekbe. Ezen túlmenően felvehetnek olyan rendkívül produktív egyéneket is, akik önkéntesként járultak hozzá a projekthez, és a projekthez kapcsolódó szakértelmet fejlesztettek ki. Ez a munkavállaláshoz vezető út értékes módja annak, hogy a diákok és más önkéntes közreműködők előrébb jussanak karrierjükben.

Azoknak a vállalatoknak, amelyek olyan bővítéseket szeretnének, amik más felhasználókat nem érdekelnek, nem kellene nyomást gyakorolniuk a nyílt forráskódú projektre, hogy adják hozzá ezeket az extra funkciókat, hanem fizetniük kellene az alkalmazottaiknak, hogy megírják a funkciókat anélkül, hogy részt vennének a projektben.

A vállalati igények által keltett lehetséges feszültségre érdekes példa a híres Android operációs rendszer, amely Linuxon alapul, és amelyet a Google fejlesztett ki mobileszközei vezérlésére. A Google által a Linuxon végrehajtott egyes változtatásokat a Linux-közösség visszakapja, míg más változtatások csak az Androidban jelennek meg. A Linux fejlesztői néha elutasítják a Google által hozzájuk eljuttatott változtatásokat, ahogyan minden projekt eldönti, hogy miket épít be.

Számos oka lehet annak, hogy egy vállalat vagy fejlesztők egy csoportja külön verziót készítsen a kódjából. Ideális esetben egy opcionális könyvtár vagy kódsorozat hozzáadásával elégíthetik ki igényeiket, amelyet a fordítás során ki lehet zárni. Néha azonban egy csoport olyan komoly igényt érez, amely nem összeegyeztethető a projekt vezetői által választott irányvonallal. Amikor egy különálló verzió készül, azt fork-nak (elágazás) nevezzük.

Régebben a forkokat az együttműködés hibáinak tekintették, de manapság már sokkal elfogadottabbak. Általában azok, akik forkot készítenek, új repositoryt hoznak létre és új projektet indítanak. Vannak, akik az eredeti projekten és a forkon is dolgoznak.

(Megjegyzendő, hogy a GitHub a “fork” szót egy egészen más jelenségre használja: a projekt kódjának klónozására vagy másolására azért, hogy külön dolgozhassunk rajta.)

A kód mellett számos vállalat anyagilag is hozzájárul a működéshez. Olyan erőfeszítéseket finanszírozhatnak, mint a marketing és a konferenciák. Csatlakozhatnak az igazgatótanácshoz, és szakértői tanácsot adhatnak a projekt irányával és stratégiájával kapcsolatban.

Az ilyen “puha támogatás” (soft support) fontosságára a történelmi Apache webszerver szolgáltat példát. A projekt nagyot ugrott előre a létezésének korai szakaszában, amikor az IBM érdeklődést mutatott iránta. Az IBM jogászai megmutatták a projektnek, hogyan hozzanak létre jogi biztosítékokat, és egy, az IBM által fizetett találkozó segített az Apache vezetőségének egy erős szervezet létrehozásában.

A függetlenség megőrzése érdekében sok nyílt forráskódú projekt nonprofit alapítványt hoz létre, vagy csatlakozik egy meglévő alapítványhoz. A nyílt forráskódú projekteket irányító alapítványok híres példái közé tartozik a Linux Foundation, az Apache Foundation és az Eclipse Foundation.

Az alapítványok támogatása azért értékes, mert olyan logisztikai feladatokat tudnak ellátni, amelyekkel a legtöbb szoftverfejlesztő nem akar foglalkozni: jogi támogatás, például a védjegyek, kártérítések és licencek ügyében; segítség a pénzszerzésben; infrastruktúra, például hibaadatbázisok és weboldalak; és így tovább.

A könyvekhez, zenéhez és más kreatív erőfeszítésekhez hasonlóan a szoftverek esetében is bonyolult kapcsolat van a fejlesztők, a hozzájárulásaikat terjesztő szervezetek és a nagyközönség között. Lényegében a közreműködőknek lépéseket kell tenniük annak érdekében, hogy egy nyílt forráskódú projekt formalizálja a kódjuk felhasználásának és terjesztésének jogát.

Ezért sok nyílt forráskódú szervezet kéri a közreműködőket, hogy írjanak alá egy közreműködői licencszerződést (contributor license agreement — CLA). Néha a közreműködő egyszerűen csak átadja a kódot a projektnek. A projekt tulajdonában van a kód és az ahhoz fűződő minden jog, ugyanúgy, ahogyan egy zártkörű vállalat tulajdonában van az a kód, amelynek kifejlesztéséért a munkatársait fizette.

Más CLA-k bizonyos jogokat az egyes közreműködők kezében hagynak, akiknek tetszhet ez a rugalmasság, mert ugyanezt a kódot egy másik projekthez is hozzáadhatják, vagy saját vállalkozást építhetnek rá.

A különböző emberek különböző hozzájárulásainak összehangolása érdekében a kódhoz rendelt licenc döntő fontosságú. A Linux kernel egyike azoknak a projekteknek, amelyek a tulajdonjogot a közreműködők kezében hagyják, így mára sok ezer ember rendelkezik a Linux kódhoz fűződő jogokkal. A core kódot azonban minden hozzájáruló a GNU General Public License (2. verzió) alá helyezi, így a Linux mindenki számára szabadon használható, módosítható és terjeszthető.

Egyetlen licenc használata a projektben található összes kódra a legegyszerűbb módja annak garantálására, hogy semmilyen teher nem akadályozza a kód terjesztését és használatát. Néha azonban egy projekt lehetővé teszi, hogy a kód különböző részei különböző licencek alatt legyenek elérhetőek, általában azért, mert a projekt ki akarja használni a már létező, más licenc alatt kiadott kód előnyeit. A licencszakértőknek meg kell győződniük arról, hogy a licencek kompatibilisek.

Sok online közösségben a korlátlan beszéd (a “bármi mehet” (anything goes) gondolat) hírneve verbális bántalmazáshoz és civakodáshoz vezet. Manapság a legtöbb nyílt forráskódú közösség küzd ezzel a tendenciával, amely túlságosan könnyen elragadja az embereket. Ezzel szemben a modern közösségek azt akarják, hogy az emberek konstruktívak, civilizáltak, tisztelettudóak és mindenkit befogadóak legyenek: minden nemet, etnikai csoportot, személyiségtípust stb. beleértve.

A csoporttagokkal szemben támasztott elvárásokat általában kifejezetten egy magatartási kódexben (code of conduct) határozzák meg, amely elmagyarázza, hogyan kell a projektben részt vevő többi emberrel online és személyesen együttműködni. Ahhoz, hogy ez a magatartási kódex hatékony legyen, a közösségi menedzsernek és a projektvezetőknek kell ennek érvényt szereznie.

Előfordul, hogy azt a személyt, aki durván kigúnyolja vagy becsmérli a közösség valamelyik tagját, véglegesen vagy ideiglenesen kizárják a közösségből. Máskor a közösségi menedzser vagy egy kolléga egyszerűen nyilvánosan bejelenti, hogy a viselkedés sérti a magatartási kódexet, és esetleg a fórumon kívül beszélget a szabálysértővel. Gyakran előfordul, hogy az elkövető korábban frusztrációt, a figyelem hiányát vagy kiégést érzett, és a közösségi tagok segíthetnek neki, hogy jobb módon fejezze ki magát.

A társadalmi viselkedés mellett a közösségek minőségi normákat is megállapítanak. A legformálisabbak a kódolási irányelvek (coding guideline), amelyek azt próbálják biztosítani, hogy minden kód hasonlóan nézzen ki. Az irányelvek emlékeztethetik a fejlesztőket a helyes gyakorlatokra, például a kódblokkok körüli kapcsos zárójelek használatára, vagy részletesen meghatározhatják, hogy hogyan nevezzük el a változókat és milyen behúzásokat használjunk.

A nyílt forráskódú közösségeknek is vannak szabályaik a kód vagy más termékek kiadására vonatkozóan. Néhány projekt a releasekre vonatkozóan rögzített időpontokat határoz meg; az Ubuntu például kétévente ígér egy új, hosszú távú támogatást nyújtó (LTS) verziót, valamint gyakoribb időközi releaseket. Más projektek listát vezetnek az új funkciókról és hibajavításokról, amelyeket a következő kiadásban szeretnének, és akkor hagyják jóvá a kiadást, ha mindent kipipáltak a listáról. A legtöbb vállalattól eltérően azonban a nyílt forráskódú közösségek általában nem határoznak meg határidőket a résztvevők számára, mivel nem lehet túl sokat kérni az önkéntesektől.

A korábban említett hozzájárulási licencszerződésen kívül néhány projekt arra kéri a közreműködőket, hogy írjanak alá egy fejlesztői eredetigazolást (developer certificate of origin — DCO). A DCO-ban a közreműködő megígéri, hogy törvényes joga van a kód eladományozására.

Miért fontos a DCO? Képzeljük el a következő forgatókönyvet: ha egy programozó kódot vesz át egy, a munkáltatója által gyártott zárt forráskódú termékből, és azt egy nyílt forráskódú projekthez adja hozzá, akkor a programozó megsérti a munkáltató licencét, és jogi kockázatnak teszi ki a nyílt forráskódú projektet.

A DCO-nak azt kell biztosítania, hogy valóban a közreműködő írta a kódot, vagy legálisan szerezte meg. A nyílt forráskódú projekt a tanúsítványt kitöltő közreműködő őszinteségétől függ.

A társadalomtudósok azt állítják, hogy a projektek és a vállalatok számára előnyös, ha sok különböző nemű, származású, gazdasági hátterű, nemzetiségű és képességű ember vesz részt bennük. Minden szervezetben természetes emberi tendencia, hogy olyan emberekhez kötődik, mint annak a tagjai, ezért egy olyan közösségnek, amely értékeli a sokszínűséget és a méltányosságot, tudatosan arra kell nevelnie a tagjait, hogy nyitottabbak legyenek olyan emberek iránt, akik nem olyanok, mint ők. Az ezt az eszményt megvalósító mozgalmat sokszínűségnek, egyenlőségnek és befogadásnak (diversity, equity, inclusion — DEI) nevezik.

A magatartási kódex a DEI kiindulópontja. Ennek kifejezetten üdvözölnie kell a különböző nemű, származású stb. embereket. A magatartási kódex minden megszegését azonnal, egyértelmű rosszallással kell kezelni. Ez azért van így, mert egyes kisebbségek egész életükben szenvedtek a kirekesztéstől és a negatív megjegyzésektől, és a fórumunkon egyetlen rossz interakció arra késztetheti őket, hogy úgy döntsenek, többé nincs okuk részt venni a projektben. Az agresszióra adott gyors válasz megnyugtathatja őket afelől, hogy a közösség támogatja őket.

A DEI azonban sokkal tovább megy. A közösségnek el kell érnie azokat a csoportokat, amelyeknek nagyobb képviseletre van szükségük. Ha például álláskereső alkalmazást fejlesztünk, gondoskodnunk kell arról, hogy az alacsony jövedelműek, valamint a felső- és középosztálybeliek számára is mutasson állásokat. Az alkalmazást az alacsony jövedelmű közösségek körében is hirdetnünk kell, és ezekből a közösségekből kell tagokat toborozni a teszteléshez.

A közösség számára hasznos lehet, ha találunk olyan szervezeteket, amelyek marginalizált csoportokból származó embereket képeznek, és amelyekből új tagokat toborozhatunk a csapatunkba. Sok ilyen szervezet helyi szinten jött létre, és országos vagy nemzetközi szinten nem ismert.

A marginalizált közösségek igényeinek megértése kulcsfontosságú. Elérhető a honlapunk a látássérültek számára is? Lefordítjuk a dokumentációt olyan nyelvekre, amelyeket a célközösség ismer? Esetleg hozhatunk létre külön fórumokat más nyelveken.

A nyílt forráskódú közösségekben a kommunikáció nagy része aszinkron és online zajlik. De ha találkozókat vagy szinkron chat-sessionöket tartunk, gondoljunk arra, hogy az emberek hol helyezkednek el földrajzilag, és találjunk módot arra, hogy mindenkit bevonjunk. Ha például sok országból és régióból származó emberek kommunikálnak angolul, próbáljuk meg a szókincset és a nyelvtant leegyszerűsíteni.

Végezetül, ha a csapatnak vannak kisebbségből származó tagjai, mindenképpen hallgassuk meg őket. A kirekesztés egyik jól ismert tünete, hogy a kisebbségek mondanivalóját nem veszik figyelembe, vagy egyszerűen csak alábecsülik annak fontosságát.

Másrészt ne terheljük a kisebbségi tagokat azzal, hogy magyarázatot kell adniuk a közösségük igényeire — ezt a kutatást mindenkinek el kellene végeznie. A kisebbségi tagok értékes felvilágosító munkát végezhetnek, de ne gyakoroljunk rájuk nyomást. Mindenkinek egyenlő lehetőséget kell biztosítani, hogy úgy vegyen részt a munkában, ahogyan szeretne, anélkül, hogy a kisebbség jelképe legyen.