Kuidas saada komiteeliikmeks ja kas see tõeliselt vajalik on

Tere! Minu nimi on Dmitri Pavlov, ma töötan GridGain, samuti olen Apache Ignite'i komittee liige ja Apache Training'i panustaja. Hiljuti esinesin Sberbanki open source'i kohtumisel ettekandega komiteede töö kohta. Otsuste ja avatud lähtekoodiga kogukonna arengu tõttu on paljusid hakanud üha rohkem huvitama, kuidas saada komiteeks, milliseid ülesandeid võtta ja kui palju koodiridu tuleb kirjutada, et sellele kohale jõuda. Kui me mõtleme komiteedele, siis meie ette tulevad kõiketeadjad inimesed, kellel on peas kroon ja „Puhas kood“ käes. Kas see tõesti nii on? Oma postituses püüan vastata kõikidele olulistele küsimustele komiteede kohta, et te saaksite aru, kas see on tõeliselt vajalik.

Igal uuel open source'i kogukonna liikmel on mõtteid, et nad ei saa kunagi komiteeks. See on paljude jaoks prestiižne roll, milleks peavad nad olema erilised saavutused, kirjutades palju koodi. Aga asi polegi nii lihtne. Vaatame komiteed kogukonna seisukohalt.

Kes on komitee ja miks ta on vajalik?

Uue avatud lähtekoodiga toote loomisel lubame alati kasutajatel seda kasutada ja uurida, samuti modifitseerida ja levitada muudetud koopiaid. Kuid kui toimuvad kontrollimatult levivad koopiaid muudetud tarkvara, siis me ei saa panustusi põhikoodibaasi ja projekt ei arene. Siin ongi vajalik see komitee, kellel on õigus koguda kasutajate panuseid projekti.

Miks saada komiteeks?

Alustame sellest, et komiteeks saamine on pluss sinu CV-s, ja kui oled programmeerimas uus, siis on see veelgi suurem pluss, kuna sageli küsitakse tööle minnes koodinäiteid.

Teine vaieldamatu eelis komiteeks olemisel on võimalus suhelda tippspetsialistidega ja tuua oma projektidesse ägedaid ideid open source'ist. Lisaks, kui tead hästi mõnd avatud lähtekoodiga toodet, võid saada tööle firmas, mis seda toetab või kasutab. On isegi arvamus, et kui sa ei osale avatud lähtekoodis, siis on kõrgete karjääripositsioonide saavutamine võimatu.

Lisaks karjäärivõimalustele ja töö leidmisele on ka kommitterdamine iseenesest meeldiv. Sind tunnustatakse professionaalses kogukonnas, saad selgelt näha oma töö tulemusi. Mitte nagu mõnes ettevõtte arenduses, kus mõnikord ei saa üldse aru, miks sa seal XML-i väljendeid siia-sinna sättid.

Avatud koodiga kogukondades on võimalik tutvuda tipptehnoloogidega, nagu Linus Torvalds. Kuid kui sa selline ei ole, siis ei pea muretsema, et sul pole seal midagi teha — seal on erineva tasemega ülesandeid.

Lisaks on ka muid boonus võimalusi: näiteks saavad Apache kommitterid tasuta IntelliJ Idea Ultimate litsentsi (kuigi teatud piirangutega).

Mida teha, et saada kommitteriks?

See on lihtne — tuleb kommitteerida.

Kui arvate, et projektides pole teil ülesandeid — eksite. Lihtsalt liituge huvitava kogukonnaga ja tehke seda, mis neile vajalik. Apache Software Foundationis on eraldi juhendi kommitterite nõudmiste kohta.

Milliseid ülesandeid tuleb lahendada?

Kõige erinevamaid — arendusest testide ja dokumentatsioonini. Jah, katsetajate ja dokumenteerijate panust hinnatakse kogukonnas samamoodi nagu arendajate panust. On ka ebatavalisi ülesandeid — näiteks juhtida YouTube'i kanalit ja rääkida teistele kasutajatele, kuidas te avatud koodiga toodet kasutate. Näiteks Apache Software Foundationis on eraldi leht, kus on kirjas, millist abi vajatakse.  

Kas on vajalik kirjutada suur funktsioon, et saada kommitteriks?

Ei. See pole sugugi vajalik. Kommitter ei pea kirjutama tohutult koodi. Kuid kui olete kirjutanud suure funktsiooni, on projektijuhtimise komiteel teid lihtsam hinnata. Kogukonda panustamine ei tähenda ainult funktsioone, programmeerimist ja testimist. Kui kirjutate kirja ja räägite mõnest probleemist, pakute argumenteeritud lahendust — see on samuti panus.

Oluline on mõista, et kommitterdamine on usaldus. Otsuse, kas teid kommitteriks muuta või mitte, teevad samasugused inimesed nagu teie, lähtudes oma arvamustest teie kohta kui inimesest, kes toob tootele kasu. Seega peate oma tegevuste ja käitumisega kogukonnas selle usalduse saavutama.

Kuidas käituda?

Ole konstruktiivne, positiivne, viisakas ja kannatlik. Pea meeles, et avatud lähtekoodiga projektides on kõik vabatahtlikud ja keegi pole kellelegi midagi võlgu. Kui sulle ei vastata — oota ja tuleta oma küsimust meelde 3-4 päeva pärast. Kui sulle pidevalt ei vastata — noh, avatud lähtekood on vabatahtlik tegevus.

Ära palu kellelgi midagi sinu eest teha või sinu jaoks ära teha. Kogenud kogukonna liikmetel on selliste 'palujate' suhtes tunnetus ja nad saavad kiiresti allergiliseks nende vastu, kes soovivad oma tööd teistele üle anda.

Kui keegi sind aitab, on see suurepärane, kuid ära kuritarvita seda abi. Ära kirjuta: 'Poisid, parandage see asi, muidu kaotan aastapreemia.' Küsi parem, kuhu edasi liikuda ja räägi, mida oled selle vea kohta juba uuringud. Kui lubad pärast probleemi lahendamist viki uuendamist, siis on tõenäosus, et sulle vastatakse, kordades suurem.

Loe lõpuks Käitumisjuhend ja õpi küsimusi esitama.

Kuidas panustada, kui sa ei ole commit'i autor?

Projektides kasutatakse sageli RTC skeemi, kus kõik inimesed peavad esmalt läbima ülevaatuse ja alles siis lükatakse muudatused peamise haru sisse. Sel juhul läbib ülevaatuse tõepoolest igaüks, isegi commit'i autorid. Seega on võimalik projekti edukalt kaasa aidata, olemata commit'i autor. Ja selleks, et saada kergemini uuteks commit'iteks, on hea tegeleda uute liikmete mentorlusega, jagada teadmisi ja luua uusi materjale.

Mitmekesisus — kas kasu või kahju?

Apache Software Foundationi mõistes tähendab mitmekesisus, et avatud lähtekoodiga projektis osaleb osalejaid mitmest ettevõttest. Kui kõik osalejad on seotud ainult ühe organisatsiooniga, lahkuvad kõik selle koosolekult kiiresti, kui selle huvi projekti vastu väheneb. Mitmekesisus tagab projekti pikaealisuse, stabiilsuse, mitmekesise kogemuse ja osalejate lai spekter arvamusi.

Armastuse või arvestuse pärast?

Avatud lähtekoodiga projektides on olemas kahte tüüpi inimesi: need, kes töötavad organisatsioonis, mis panustab antud tootesse, ja need, kes on siin armastuse pärast, st vabatahtlikud. Kes neist on tootlikum? Üldiselt on tootlikumad osalejad, kes toetavad toodet organisatsiooni katkestamiseks. Nendel on lihtsalt rohkem aega ja selge motivatsioon tõde välja selgitada, nad on ülesandele keskendunud ja lähemal kasutajale.

Need, who does it "out of love," is also motivated, but in a different way — they are eager to explore the project, make the world better. And just such participants are more stable and focused on the long term, because those who come to the community on their own initiative are unlikely to leave it overnight.

How to find a balance between productivity and stability? There are two options. The first option: when a participant works in a company that officially engages in this open-source project and does something additionally out of interest — for example, supporting newcomers. The second option is a company that has undergone open-source transformation. For example, when employees work four days a week on the core business project, and spend the rest of the time on open source.

Committer — to be or not to be?

Committership is a good and useful topic, but one should not strive solely to become a committer. This role can be obtained not through code, and it does not prove your knowledge. What matters is expertise, that is, the knowledge and experience you acquire by studying the project, delving into it, and helping others solve problems.

Allikas: habr.com