Szavazás: Elgépelési hibák javításait, kozmetikai javításokat tartalmazó patchek tekinthetők-e valódi hozzájárulásnak?

Programozás

Gyakori jelenség nyílt forráskódú projektek környékén, hogy egyesek pl. a forráskódok kommentjeiben ejtett elgépelési hibák javításait, vagy kozmetikai javításokat küldenek be beolvasztásra. Aztán az egyes projektek karbantartóinak vérmérsékletétől függően vagy örülnek, vagy megtűrik vagy kifejezetten ki nem állhatják ezeket.

Szerinted az ilyen patchek tekinthetők valódi hozzájárulásnak?

Igen.
57% (363 szavazat)
Nem.
41% (263 szavazat)
Egyéb, leírom.
2% (13 szavazat)
Összes szavazat: 639

( gelei v | 2022. 05. 04., sze – 09:55 )

Egy százéves kommentben javítja ki a typo-t, vagy a GUI-n is megjelenő tróger helyesírást javítja? Nem mindegy. :)

( milgra | 2022. 05. 04., sze – 09:56 )

Mindenképpen jobbá teszi a szoftvert/kódot, én örülni szoktam neki.

( gee v | 2022. 05. 04., sze – 10:34 )

Szerkesztve: 2022. 05. 04., sze – 10:35

Bajnak nem tartom az ilyen javítást, és ha projekt karbantartó lennék, nem zavarna ez (amennyiben nem olyan mennyiségben jön, hogy az igazi munka kárára megy).

Viszont az nem tetszene, ha ezek az emberek ezután azt mondanák magukról (pl. aláírásban, CV-ben), hogy ők az XY projekt fejlesztésének aktív résztvevői, n mennyiségű beküldött patch-csel.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

amennyiben nem olyan mennyiségben jön, hogy az igazi munka kárára megy

Ha annyi typo javítás jön, hogy az az igazi munka kárára megy, ott más baj is van :)

Viszont az nem tetszene, ha ezek az emberek ezután azt mondanák magukról (pl. aláírásban, CV-ben), hogy ők az XY projekt fejlesztésének aktív résztvevői, n mennyiségű beküldött patch-csel.

+1, kivéve, ha tényleg kimutatható mennyiségű értelmes melót talál magának, lásd fentebb

Ha annyi typo javítás jön, hogy az az igazi munka kárára megy, ott más baj is van

Ez igaz. Én az olyan alibi változtatásokra gondoltam, hogy széttördeljük a kommentet több sorba, beszúrunk egy space-t, egy üres sort, külön fájlba veszünk valamit, aztán valaki más ugyanezeket a változásokat egyesével visszacsinálja. :-)

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

( denesb | 2022. 05. 04., sze – 11:11 )

Szerkesztve: 2022. 05. 04., sze – 11:53

Magam is maintainer vagyok egy open-source projektben és habár mergelem az ilyen patcheket gond nélkül, de nem szeretném ha sok lenne belőlük. Nem gondolom hogy sokat ad a projekthez ez régi typo javítása.

:wq

( Aadaam v | 2022. 05. 04., sze – 11:27 )

Szerkesztve: 2022. 05. 04., sze – 11:29

Kozmetika - kódkozmetika vagy UI?

Szerintem minden UI változás értékes a felhasználói élmény szempontjából, max negatív az értéke. 
 

Múltkor kicsit átrendeztem TCH YTFE-jének felületét, meg kikeresgettem az eddigi ascii-art ikonok megfelelőit a FontAwesome ikonnyelvében:

https://hup.hu/comment/2737279#comment-2737279

Félreértés ne essék, full kozmetikai a változás, de ha nem kell minden egyes alkalommal tooltipet olvasgatni hogy melyik gomb mit akar, az szerintem érték, max nem funkcionalitás (tény, nem fog jobban letölteni tőle a program)

engem pl ez a dark mode mizéria se izgat (full apple eszközkészlettel se), de azon is szívnak sokan mint az a bizonyos borz-faj.

( eff | 2022. 05. 04., sze – 11:41 )

Mennyiseg/minosegtol fugg. Ha csak 1-1 reszen par typo-t javit, az nem. Ha viszont egy komplett modult atnez, es mindenhol kijavitja a dolgokat, akkor mar igen. Es mondjuk ha egy komplett modulban 1db typo van, azt nem kuldi be :)

( rpsoft v | 2022. 05. 04., sze – 12:12 )

Persze, hogy hozzájárulás. Az alapvető igényesség, hogy amit a program kiír, abban ne legyen helyesírási hiba, az meg, hogy a comment-ben sem, az ugyanolyan, mint hogy otthon is porszívózunk a szekrény tetején is, nem csak a szoba közepén. A kód szépsége meg még fontosabb, mert a tákolás vonzza a tákolást. (Nagyon meg tudom becsülni az olyan programokat, amiket megírtak egyszer, valamilyen nyelvben annyira perfekten szabványkövetőn, hogy 20-40 év múlva gond nélkül lefordul, működik, azóta nem találtak benne bugot. Matematikusok által írt, publikált, numerikus szubrutinokkal szoktam ilyet látni. Fortran-77-ben írták, valamilyen akkori CDC nagygépen tesztelték, és ma, gfortran-nal lefordírva megy, működik. A comment-ek rendes angolul vannak írva, dokumentálják, hogy mit csinál, miért csinálja, és hogyan kell meghívni.)

Hogy jön ez most ide? A programozás megkövetel valamiféle fegyelmet, bizonyos programnyelvekben írt kódok le se fordulnak, ha a kód nem felel meg szigorú formai követelményeknek. Nyilvánvalóan, ennek precizitásra kellene tanítania a programozással foglalkozókat. Mint a mérnököt a szakrajz.

Azt gondolná az ember, hogy e precizitásnak tükröződnie kellene az ilyen munkát végző emberek egyéb produktumán is, pl. az írás. Egyik-másik ember esetében azt nem értem, hogy az érettségin hogy sikerült átcsúsznia ...

trey @ gépház

Van olyan elmélet, miszerint ahhoz, hogy jó legyél programozásból (ami, végülis, egy feladat kifejezése egy nyelven), jónak kell lenned más nyelvekben, elsősorban az anyanyelved használatában (Dijkstra). Mondjuk a programozásnak szerintem egy része csak valaminek a kifejezése egy nyelven, és egy másik része, hogy a probléma megoldását szisztematikussá tudd tenni (ha neked kellene megoldani papíron, ceruzával, lehet, hogy látnád a megoldást, és nem algoritmikusan keresnéd). A gépelési hiba megint más, láttam olyan embert, akinek a CS-ben elég jó híre van, programot is írt sokat és nem akármilyet, de ha angol szöveget gyorsan gépel, akkor nagyon sok gépelési hibát vét (pl. nem a szavak közé kerül a space, amikor váltani kell jobb és bal kéz között, akkor elrontja a két betű sorrendjét). Gondolom, amikor programkódot ír, többet gondolkozik közben, és ezért lassabban gépel.

Azt nem hiszem, hogy egy normális programozási feladathoz túl sok zseni kell. A zseni arra kell, hogy megoldja az olyan feladatokat, amilyet még senki sem oldott meg előtte. A program megírásának a nagy része viszont tisztességes iparosmunka (ismert algoritmusok használata, "bookkeeping", i/o, illetve kódolás, debugolás, refaktorálás, profiling), amiben az igényesség nagyon fontos.

( Botond | 2022. 05. 04., sze – 15:20 )

Rebase-elni kell az ilyen patch-eket.

( MaDog | 2022. 05. 04., sze – 15:42 )

Lassuk el sztori pontokkal a kereseket es aztan meg lehet mondani, hogy ki mennyi ponttal jarult hozza. Igy tobb gond is megoldodik. :)

Az Erő Legyen Veled!

( Hiena v | 2022. 05. 04., sze – 17:56 )

Általában ilyennel kezdődnek a project take-overek és szétcseszések.
Kell és hasznos a kód clean-up, typo fix, különösen a segítő, extra kommentek hozzáadása, miközben nem azonos értékű a funkcionális fejlesztéssel. A probléma, hogy nagyon sokan, az ilyen típusú kommiteket a cvjük és a renoméjük építésére használják. könnyen előjöhet az a helyzet, hogy egy nagyobb projectben a fő fejlesztőnek van 300-400 kommitje, miközben a lilahajú megmondónak meg 1200 mert kicserélte az összes mastert és slavet a kódbázisban, írt egy code of conduct-ot.

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

A JVM-en a legnepszerubb metrics library top 5 kontributora commit szam alapjan:

user A: 788 commits (kontributor, majdnem csak clean-up valtoztatasokkal)
user B: 497 commits (jelenlegi project lead, hivatalos maintainer, ezert kapja a fizeteset)
user C: 449 commits (elozo project lead, hivatalos maintainer volt, ezert kapta a fizeteset, a codebase nagy reszet o irta, ma mar leginkabb inaktiv)
user D: 250 commits (hivatalos maintainer, ezert kapja a fizeteset)
user E:   58 commits (hivatalos maintainer, ezert kapja a fizeteset)

User D en vagyok es egyaltalan nem erdekel/zavar, hogy az egyik kontributorunknak aki ezt szabad idejeben csinalja haromszor annyi kommitja van mint nekem aki meg nyolc oraban fizetesert dolgozik es hogy a commitjainak a nagyon nagy resze cleanup. Orulok neki mikor meglatom, hogy PR-t nyitott es nagyon magas szazalekban mergelem oket.

https://develotters.com

Te nem HR és fejvadász vagy. A modern nyugati HR github repot, meg nickeket kér a különféle projectjeidhez és megnézi a commitek számát. Minél jobban hangzó, ismertebb project annál nagyobb az esély, hogy behívják az embert, ha releváns a cégnek. Nagyon sok indiai pont emiatt tolja a kozmetikázást.

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Nem, en maintainer vagyok a modern nyugatrol (USA-ban elek). Sokszor lattam mar olyat amirol beszelsz (hacktoberfest-kor hatvanyozottan elojon) de engem nem annyira erdekel a motivacio (azon tul, hogy orulok neki, ha rendszeresen visszajar valaki). Ha elkezd ertelmetlen dolgokat betolni (lasd: #shitoberfest vagy @shitoberfest) akkor azt kivagjuk, de ez azert nagyon ritka.

https://develotters.com

( timar | 2022. 05. 04., sze – 18:00 )

Még mindig jobb, mint code of conductot fogalmazni, de azért nem jó. A gyakorlatban ritka, hogy valaki először javít egy elgépelést egy kommentben, aztán javít egy hibát, aztán fejleszt egy új feature-t. Nem látom ezt az evolúciót, pedig ez szokott az érv lenni arra, hogy fogadjuk tárt karokkal az ilyen jellegű hozzájárulásokat. Az ilyen kommentjavítók általában megragadnak az első lépcsőfoknál, aztán a statisztikában már nem látszik, hogy az x darab commitja mind ilyen volt, csak jól néz ki. De ez nem is zavarna, az szokott zavarni, ha a git blame-ben őt látom, nem az eredeti szerzőt, akinek a commitjára kíváncsi lettem volna.

Asszem erre ellenpelda vagyok. :)
Tobbek kozott a legnagyobb/legnepszerubb Java-s metrics library egyik hivatalos maintainere vagyok (ezert kapom a fizetesem) es ha jol emlekszem az elso modositasom a projekten (joval korabban) pont egy egy karakteres elgepeles javitasa volt.

https://develotters.com

( ivanov | 2022. 05. 04., sze – 18:58 )

Tobb elegge nagy es nepszeru open source project maintaineleseben veszek reszt. En szoktam az ilyen modositasoknak orulni, van olyan kontributorunk aki majdnem mindig ilyen "polishing" pull requesteket kuld es szerintem nagyon jol jon, hogy valaki "takarit".
Viszont ilyenbol nincs sok, egyaltalan nem zavaro, boldogan mergelem be oket. :)

Projecttol fuggoen a release notes-ban meg szoktuk emliteni a kontributorokat meg ha az egy typo is volt.

https://develotters.com

( Vamp | 2022. 05. 04., sze – 19:44 )

Bar ez nem ugyaz, de en egy Linux distro magyar forditasaba (GUI) segitek be. Bar nagyreszt magam miatt csinalom (en is ezt a distrot hasznalom) :) 

( PDA_FAN | 2022. 05. 04., sze – 22:31 )

Bennem is az a kérdés merül fel, hogy egy helyesírási hibáktól hemzsegő komment írója milyen kódot ír... Persze a mai korszerű fejlesztőeszközök, már minden hibás kódsornál csilingelnek, sőt, talán a nyilvánvaló hibákat javítják is. Megnéztem volna az ilyen dyslexiás* programozókat, hogy egy parancssori TASM vagy MASM mit dobott volna az elgépeléseikre...

 

*dyslexia: mindenkit meg lehet tanítani írni-olvasni, csak a modern pedagógiai módszerek erre alkalmatlanok. 50 évvel ezelőtt nem láttunk egyetlen dyslexiást sem, mert az akkori tanító nénik még értettek az oktatáshoz.

Dehogy értettek. Csak akkor nem dyslexiásnak hívták, hanem analfabétának. Simán buktatgatták, amíg el nem ment valahova, vagy le nem járt a kötelező tankötelezettség. (Amúgy ezen én is szoktam gondolkozni, hogy régen hogy a fenébe' programoztak az emberek. Amikor beírom, hogy make, általában több képernyőn át sorolja a compiler a hibákat, aminek a 90 %-a elgépelés, lemaradt zárójel, pontosvessző, rossz argumentum-sorrend. Ha programlapra kellene még ma is írni, szépen 80 karakter szélesen, első 6 a címke, utána kód, utolsó 8 opcionális sorszám, majd leadni kártyára lyukasztani, aztán másnap visszakapnám, hogy "Compilation error 001: syntax error, line 7.", hát, elég lassan készülne el bármi is.)

A saját példámat írtam. Vidéki faluban idős tanítónéni, aki első és második osztályban tanított minket. Senki nem bukott meg, senki nem lett analfabéta. Az én korosztályomban még volt kisegítő osztály, ahova a tényleg problémás gyerekeket tették, akik ha lassabban is, de megtanultak írni-olvasni-számolni. Aztán a 70-es évek végén, 80-as években jöttek a világmegváltó pedagógiai módszerek, a szóképben olvasás és társai, és onnantól tényleg egy csomó gyerek félanalfabétaként került ki az iskolából.

Egyrészt MO-on nagyon sokáig csökkent az analfabéták száma, és (legalábbis hivatalosan) a 80-as évekre lett 0. Ez nekem azt mondja, hogy a pedagógiai módszerek használtak. Aztán persze a pénztelenség, a tanárhiány rontotta a dolgokat. Másrészt, nekem 89 környékén, első általánosban, volt egy osztálytársam, akinek voltak tanulási nehézségei. Akkor nem tűnt fel semmi, nem volt a padtársam, vagy barátom, de ma már jobban átlátom a dolgot. Semmi segítséget nem kapott az iskolában, és év végén az iskola "felajánlotta" a szülőknek, hogy nem buktatják meg, ha elviszik máshova. (Kényelmes kis budapesti, zöldövezeti iskola, megszabadultak tőle.) A kisegítő osztállyal az a baj, hogy összezárják egy helyre azokat, akiknek különböző okok miatt kell segítség: a diszlexiást, és azt, aki csak motiválatlan, mert a családjában van már három generáció alkoholista előtte.

Ne érts félre, nem mondom, hogy a falusi iskola idős tanítónővel feltétlenül rossz. Csak abban az esetben a tanítás nem szakma, hanem művészet, ami a tanítónő tehetségén múlik. Ha szerencséd van, és a tanítónő/tanító tehetséges és szereti a gyerekeket, akkor jól működik. Ha meg valamelyik hiányzik, akkor nem.

Szerintem:

  1. Egyre bonyolultabb rendszerek készülnek, egyre több kóddal = több hibalehetőséggel
  2. A programozás szoftverfejlesztés egyre kisebb része az, hogy kódot írsz
  3. Olcsó lett hibázni, ha valamiben nem vagy biztos, megnyomod a compile-t, és két másodpercen belül kiderül

Utolsó talán a legfontosabb.

én is szoktam gondolkozni, hogy régen hogy a fenébe' programoztak az emberek. Amikor beírom, hogy make, általában több képernyőn át sorolja a compiler a hibákat, aminek a 90 %-a elgépelés, lemaradt zárójel, pontosvessző, rossz argumentum-sorrend. Ha programlapra kellene még ma is írni, szépen 80 karakter szélesen, első 6 a címke, utána kód, utolsó 8 opcionális sorszám, majd leadni kártyára lyukasztani, aztán másnap visszakapnám, hogy "Compilation error 001: syntax error, line 7.", hát, elég lassan készülne el bármi is.)

Pont ezért született meg az a megközelítés, hogy mielőtt a számítógép megkapta volna a "programot", előtte papíron többen átnézték. Nem csak az elütéseket, hanem azt is, hogy az algoritmus jól van-e megtervezve, a megtervezett algoritmus jól van-e lekódolva, jók a bemenő adatok, megfelelő sorrendben jönnek, stb.

Mondjuk úgy hallottam (de leírva így konkrétan nem láttam megbízható forrásban), hogy 1946-ban az ENIAC kb. két hét futás után adta vissza az eredményt, szóval nem másnap jött a hideg zuhany)

De akár egy nap volt, akár több, abban az időben a gépidő drágább volt, mint a papírprogramot ellenőrző emberek fizetése, plusz sorban álltak a számolási feladatok, szóval senki nem akart syntax errorral elkúrni pénzt és időt.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Elég sok helyen nem azért programoztak programlapon, mert azt még volt ember, aki átnézze, hanem mert nem volt annyi kártyalyukasztó. A programozó lapra írta, a titkárnő kártyára lyukasztotta, az operátor futtatta. Utána átvehetted, amit a sornyomtató kiköpött. Ismertem elég sok embert, aki még így kezdte. (Biztos voltak jobb helyek is, de ez azért nem USA és 1946 volt, hanem Magyarország, és talán a 70-es évek.)

Bizony, 1978 BME - Odra 1204.

Hozzá kellett jutni egy konzol írógéphez, ami lyukszalagra tudta írni a programot, amit Algol 60-ban írtam. Leadtam az operátornak, majd másnap megjött az eredmény, ami 17 s idő alatt ált elő. Fortran programokat már lyukkártyán kellett írni, vagy hozzáfértem a villamoskari rendszerhez, ami már crt terminállal ment BASIC+ nyelven.

Utána a kollégiumnak vettek egy 6800 alapú kisgépet.

A későbbi munkahelyemen (Videoton Fejlesztési Intézet) "csillagpromtos" rendszeren írtam a programokat. Egyik 160k-s flopin volt a forrás, a másikra került a lista. Csitt-csatt - ment a fordítás. A gép 3 MHz-es 8080 alapú volt.

A kolléga az 1 k x 16 bites programot bitenként nyomkodta be egy desktop pc méretű égetőbe.

De.

A program írása mindig folyamatábra készítéssel kezdődött. Fontos volt a hibátlan algoritmus, mert rossz esetben tört vagy kigyulladt a szerkezet. (Elektromechanika osztály ;))

No, akkor még egy embert ismerek, aki dolgozott Odra-n. MO-on, a kutatóintézetben, ahol dolgoztam, volt egy idősebb fickó, aki az ELTE-n Odra-n futtatott volna egy programot (Runge-Kutta differenciálegyenlet-megoldás) a szakdolgozatához. Bement a számítóközpontba, közölték vele, hogy elromlott a gép, de javítják. Gondolta, egy lépést kiszámol papíron, hogy lássa, hogy alakul a megoldás. Még nem volt jó a gép. Délután 5-kor még nem ment a gép, de megvolt a differenciálegyenlet megoldása, úghogy hazament, beleírta a szakdogába, leadta, és többé nem nyúlt az Odra-hoz. A kutatóintézetnek Gier, ICT, ESzR és BASF-gépei voltak régen, de amikor én kezdtem ott dolgozni, már a Pentium PC is elavult volt.

Hurrá! Híres lettem! :-D

Azért van az öregségnek és tapasztalatnak is egy előnye. Ma konzultáltam telefonon egy junior (java) programozóval. A teszt eredményeket hexdump formátumban fogom küldeni. Éééés megkérdeztem tőle, tudja-e mi az a hexdump? Nem volt biztos benne, talán látott már... Bizony itt tartunk. :(

Rögtön ajánlottam a google:joelonsoftware cikkek olvasgatását, hátha okosabb lesz.

Az utolsó olyan évfolyamba jártam, ahol még tanították a logarléc használatát, de már lehetett számológépet is használni. Volt is egy TI-57-esem, de a vizsgafeladat megoldásához két logarlécet használtam. Hülyét is kaptak a tanárok. :)

A logarléc használatának alapfeltétele, hogy bármilyen eszköz nélkül meg tudd becsülni a végeredmény nagyságrendjét. A számítógép annyiban bonyolultabb, hogy ott a feladathoz szükséges teljesítmény mellett a megfelelő eszközt is ki kell tudni választani. Így aztán azt is el tudom mondani a fiatalabbaknak, hogy nem vagyok annyira ügyes. Tehát a 8 bites mikrokontrollerrel nem verem le a Core i7-es mákbúkprót, mint a cölöpöt. Inkább az usb portot kezelő programot nem sikerült úgy megírni, ahogy kellett volna. ;)

Volt 50 évvel ezelőtt is, csak maximum nem volt úgy méltányolva, meg nem volt divat bevallani, hivatkozni rá. Én ilyen szigorú nem lennék, elvileg a diszlexia nem zárja ki azt, hogy valaki jó programozó legyen, bár azért nem is előny. A programozás tudáson, gondolkodáson, módszertanon, tapasztalaton is múlik, más részről meg a modern IDE-k sokat tudnak segíteni elgépelés ellen, elírt változó, függvény, objektumnevek, paraméterek, le nem zárt idézőjel/zárójel észrevétele, projektsablonok, stb. Helyesírás-ellenőrzők, modern, jobban olvasható betűtípusok szintén sokat segíthetnek, bár az már nem programozás témája. ASM szerintem nem speciális egy akármilyen programnyelvhez képest, nem könnyebb, nem nehezebb.

Az is igaz, hogy ma már kezdik túltolni ezt a diszlexiát, jó részük, akik ilyen disz-ilyen, disz-olyanságra vannak rágyúrva, azok többsége csak simán lusta, buta, nem tanult meg tanulni, figyelni, stb., de mivel kijátsszák a disz-kártyát, ezért mentesülnek, és ezzel legtöbbször magukat csapják be, meg nem tanulnak meg küzdeni az életben. Objektív ismérve szerintem nincs a diszlexiának, diszkalkuliának, de még az autizmusnak se, bár annak csak akkor, ha enyhébb fokú.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

ASM szerintem nem speciális egy akármilyen programnyelvhez képest, nem könnyebb, nem nehezebb.

Ha belegondolsz, a max 100 féle utasítás és 30 direktíva jobb-e, vagy mondjuk 2500 java class?

Avagy mit választanál egy pontos ábra razolásához: 1 tűs mátrixnyomtatót, ASCII art-ot, vagy 1 cm méretű kör, négyzet, stb. elemeket?

( Raynes v | 2022. 05. 05., cs – 05:39 )

Hasznosnak hasznos, így nekem nem lenne ellenemre, de túlzottan érdemi (valódi) hozzájárulásnak nem nevezném. A lokalizációs fordítás, dokumentációfordítás már határeset, el lehet vitatkozni, hogy azt tekinti-e valaki valódi hozzájárulásnak. Esetleg egy skin, téma, színtéma, ikon, az még lehet valódi.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

A lokalizacios forditast en mar azert annak tekintem. Sztm kb onnantol szamit igazan konstruktiv hozzajarulasnak valami, ha az alapvetoen plusz felhasznalot hoz. Ha ket alkalmazas kozott a felhasznalo iranyaban az dont, hogy az egyi lokalizalva van, a masik nem, akkor ott mar azt mondhatjuk, hogy igenis hozzajarulas volt a forditas.

És ha az egyik helyesírási hibáktól hemzseg a másik meg szépen szabatosan és jó helyesírással írja ki ugyanazokat az üzeneteket?

Simán lehet, hogy ez is szerez néhány felhasználót, szerintem.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

( bolond | 2022. 05. 05., cs – 09:06 )

Ha a kérdés az első bekezdés kontextusában értelmezendő, akkor szerintem az adott OSS projektnek kell meghatároznia, milyen típusú hozzájárulást vár ill. nem vár, és ezt illendő nyilvánosan közölnie. Ha nem szerepel ilyen információ nyilvánosan, akkor a patcheket beküldeni kívánó potenciális hozzájáruló megkérdezheti, szívesen fogadják-e azt a fajta hozzájárulást, amit ő nyújtani szeretne. A válaszadás után a projekt illetékese frissíti a projekttel kapcsolatos leírást, hogy az ezután érkezők könnyen megtalálják a választ.

:)