Mi az a Firefox ESR? Hogyan kell telepíteni Ubuntun?

 Az Ubuntu snap verziója nem tetszik? Nem szereted, ha minden Firefox kiadással folyamatosan változnak a dolgok? Próbálja ki a Firefox ESR változatát, ha a stabilitást fontosabbnak tartja a funkcióknál.

Mi az a Firefox ESR?

A Firefox ESR a Firefox böngésző speciális kiadása, amely nem feltétlenül kap havonta új funkciókat, mint a normál kiadás, de stabil és biztonságos böngészési élményt nyújt. Ez olyan vállalatok, szervezetek és intézmények számára alkalmas, ahol a stabilitás és az alapvető funkciók fontosabbak, mint a csillogó új funkciók.

Gondoljon a Firefox ESR-re úgy, mint a Linux disztribúciók hosszú távú stabil kiadására. Nem feltétlenül kapnak vadonatúj funkciókat, de rendszeres biztonsági és karbantartási frissítéseket. Ezáltal a felhasználóknak egy megszokott és stabil környezetet biztosít.

Miért érdemes foglalkozni a Firefox ESR-rel?

A Firefox szinte minden hónapban kiad egy új verziót. Ez biztonsági és funkciófrissítéseket tartalmaz.

Néhány embernek azonban nem tetszhet a funkciók felvétele és eltávolítása. Ha egy frissítés után folyton azon tűnődik, hová tűntek bizonyos beállítások, vagy nem tetszik, hogy a korábbiakhoz képest másképp működnek a dolgok, a Firefox ESR-t érdemes lehet kipróbálni.

Alapvetően, ha számodra fontosabb a stabilitás, mint az új funkciók, akkor a Firefox ESR az önnek való. A Firefoxnak ez a verziója a Debianhoz is jár, amely arról ismert, hogy az egyik legstabilabb disztribúció, amit a piacon kaphatsz.

Hadd mutassam meg, hogyan szerezheted be a Firefox ESR-t Ubuntun. A Firefox és a Firefox-ESR verziókat egyszerre telepítheted. A logóik között nincs vizuális különbség, így figyelned kell, hogy melyik Firefox verziót nyitod meg.

A Firefox ESR telepítése Ubuntun

Mielőtt a telepítési részre ugranék, hadd osszam meg, mi a verzióbeli különbség a normál Firefox és a Firefox-ESR között. Miközben írtam,

A Firefox a 107.0-2-es verziószámon fut.

A Firefox-ESR jelenleg a 102.5.0esr verziószámmal rendelkezik.

Tehát ha ez megfelel neked, akkor nézzük az első módszert.

1. módszer: Firefox-ESR telepítése PPA használatával

A Firefox-ESR nem érhető el az Ubuntu alapértelmezett tárolójában, ezért a PPA-t használhatja.

A PPA nem más, mint egy olyan tároló, amelyet az egyes technikusok vagy fejlesztők tartanak fenn, hogy legyen, ami az alapértelmezett tárolóban nincs.

Ha pedig többet szeretnél megtudni a PPA-ról, akkor ajánlom figyelmedbe másik útmutatónkat, amely elmagyarázza, hogyan használhatja a PPA-t Linuxon.

Nyisd meg a terminált, és használd a megadott parancsot a PPA hozzáadásához a Firefox-ESR-hez:

sudo add-apt-repository ppa:mozillateam/ppa

És nyomd meg az Entert a PPA hozzáadásának megerősítéséhez:

Ha ez megtörtént, frissítened kell a tároló indexét az Ubuntuban, hogy a módosítások hatályba lépjenek:

sudo apt update

És most már telepítheted a Firefox-ESR-t a megadott paranccsal:

sudo apt install firefox-esr

Ezután a megadott paranccsal ellenőrizheti a Firefox-ESR telepített verzióját a rendszerében:

firefox-esr -v

A Firefox-ESR eltávolítása Ubunturól

Ha az ESR-t túl elavultnak érezted a munkádhoz, vagy bármilyen más okból szeretnéd eltávolítani a rendszeredből, akkor a Firefox-ESR csomag és a tároló eltávolításához kövesd a lépéseket.

Először távolítsuk el a Firefox-ESR csomagot a következőkkel:

sudo apt remove firefox-esr

Most a megadott paranccsal eltávolíthatjuk a PPA-t az Ubuntuból:

sudo add-apt-repository --remove ppa:mozillateam/ppa

És ennyi!

2. módszer: Firefox-ESR telepítése Snap segítségével

Szeretjük vagy utáljuk, a Snaps előre be van állítva az Ubuntun, és szerintem a snaps használata egy jó módja a csomagok telepítésének, különösen akkor, ha el akarod kerülni a forrásból való építést vagy a PPA használatát.

A Firefox-ESR telepítéséhez a snaps segítségével mindössze annyit kell tenned, hogy követed a megadott parancsot:

A snap install firefox --channel=esr/stable

A Firefox-ESR Snap eltávolítása

A Firefox-ESR (snap csomag) eltávolításához használja a snap remove parancsot:

sudo snap remove firefox

És kész is van!

Befejezés

Ebben az útmutatóban elmagyaráztam, hogyan telepítheti a Firefox-ESR-t Ubuntuban többféle módszerrel. Én személy szerint a Firefox-ESR-t használom a normál verzió helyett, mivel véletlenszerű összeomlások voltak.

Amióta áttértem a Firefox-ESR-re, a dolgok sziklaszilárdan mennek számomra. És ha neked is ugyanez volt a problémád, érdemes kipróbálnod.

Forrás: What is Firefox ESR? How to Install it in Ubuntu?

A "Hé, haver, hol kaphatom meg ezt a háttérképet?" blogbejegyzés

Alternatív cím: "Ez egy víziló?! Úgy néz ki, mint egy pár szőrös..."

Ha az elmúlt egy hónapban a színes asztali háttérképek után vágyakoztál, amelyeket a cikkekhez és a tweetekhez készített képernyőfotókon használtam, akkor ez a bejegyzés neked szól.

Elég sokan kerestek meg, hogy kérjenek tőlem egy linket a háttérképekhez, amelyeket megpillantottak egy képernyőfotón. Azt is megkérdeztétek, honnan szerzem be a háttérképeket. Ahelyett, hogy továbbra is egyenként válaszoljak a kérdésekre, gondoltam, hogy bedobok ide egy gyors posztot megosztani, és talán elérni azokat, akik nem kíváncsiak, de túlságosan féltek megkérdezni.

Ráadásul a háttérképekről szóló bejegyzés lehetőséget ad arra, hogy egy kicsit megtréfáljam az Ubuntu 21.04-et és annak "egyedi" asztali háttérképét:

A bemutatása óta az Ubuntu 21.04 alapértelmezett háttérképéről megoszlanak a vélemények. Egyesek egy játékos víziló körvonalát látják, egy ártalmatlan kabalafigurát, egy kis mókát. Mások? Nos, ők egy pár szőrös... Hívjuk őket egyszerűen kókuszdiónak! 🥥

A (többnyire humoros) ellenségeskedés fényében, amit a szőrös hajúak megszentelt formája elszenvedett, azt hiszem, a szokásosnál több ember kereshet alternatív asztali hátteret 😉 - egy újabb ok arra, hogy egy ilyen gyors posztot tegyek ki.

Az Ubuntu 21.04 mindössze két alternatív háttérképet kínál a vitatott alapértelmezett vászonhoz, mindkettő szintén vízilovak képe. Nos, én ugyanúgy szeretem a vízilovakat, mint bárki más, de egy kis változatosság az asztali háttér részlegben jól esett volna, 'Buntz.

A nemrégiben újraélesztett Ubuntu 21.10 háttérképverseny most zajlik, és biztosítja, hogy a következő kiadás eleve egy kicsit változatosabb képkészlettel érkezzen. De csak egy kicsit; a fejlesztők azt tervezik, hogy csak KÉT győztest választanak ki a .iso lemezre. Azt mondják, hogy így helyet takarítanak meg a lemezképen... 💁🏻♂️

Mégis, bármelyik verziót is használod, az Ubuntu asztali hátterét (gyakorlatilag) bármilyen képfájlra átállíthatod.

Ilyen például ezek...

WallsbyJFL

Egy kis minta @WallsbyJFL-től

A remek háttérképeim elsődleges forrása egy JFL nevű tervezőn keresztül érkezik. Ez a személy készít, tervez, fotóz, szerkeszt, és kurátori mappát tölt meg a fantasztikusan nagy felbontású (minimum 2K) hátterekkel. Bárcsak mindet egyszerre használhatnám. Ez egy olyan "...nem ez a kedvencem... nem ez... nem, ez!" helyzet.

Míg JFL háttérképeit nem engedélyezik a terjesztésre (tudomásom szerint), az "ingyenes" gyűjteménye ingyenesen letölthető személyes használatra asztali számítógépekre, mobilokra stb. A háttérképek felhasználásakor a @wallsbyjfl-nek kell elismerést adni a nem háttérképes munkáidban.

Nagy az esélye annak, hogy ha tetszett egy háttérkép kinézete az elmúlt 3-4 hónap valamelyik bejegyzésében, akkor az JFL háttérképét tartalmazza. Az alábbi linken keresztül böngészhetsz az ingyenes mappájában a Google Photos-on keresztül:

WallsbyJFL a Google Photos-on

Ha nagyon tetszik a JFL munkája, akkor előfizethetsz a prémium albumukra 5 dollárért (élethosszig). Ezzel még több képhez férhetsz hozzá, amelyek közül sok az előnézetben megtekinthető az Instagramon, mobilon és asztali számítógépen egyaránt.

A másik elsődleges forrásom a kiváló minőségű képekhez, amelyek általában jól működnek asztali háttérképként, az Unsplash. Az Unsplash összes képe ingyenesen letölthető és használható (ami nagyszerű). Kinyomtathatod őket, beboríthatod velük a kutyádat, eladhatod a kutyát egy művészeti installációnak, és aztán elviheted az összes dicsőséget - ez a fajta "ingyenesség".

Ó, és azt hiszem, meg kell említenem azt a "kék mosolygós buborékok" tapétát is, amit néha használok. Ez a .jpg már azóta megvan, amióta ez a blogom van.

Kék mosolygós buborékok a Fedora 34-ben

Nem emlékszem az eredeti forrásra (és 13 év elteltével csak nyúl üreg után nyúl üreg), de mindenféle kissé furcsa hangzású weboldalakon találsz felskálázott 2K és 4K verziókat, amelyekhez nem vagyok elég magabiztos ahhoz, hogy linkeljek - csak keresd a "blue smiley face wallpaper" szót.

Ezzel kapcsolatban gyakran gondoltam arra, hogy a fenti mosolyok lila/narancs színű változata BETEG Ubuntu háttérkép lenne.

Akárhonnan is csípted el a kívánt csettintést, könnyű háttérképet váltani az Ubuntuban. Megteheted a Beállítások > Háttér eszközön keresztül; a Firefoxon keresztül (ha jobb gombbal kattintasz egy kompatibilis képre a böngészőben); vagy a fájlkezelőn keresztül, csak kattints jobb gombbal bármely kompatibilis képfájlra, és válaszd a "set as desktop background" (beállítás asztali háttérképként) lehetőséget.

Forrás: The ‘Hey Dude, Where Can I Get That Wallpaper?’ Blog Post.

Hogyan skálázz fel régi játékokat Linuxon a Lutris-szal?

Bármelyik eszköz, ami könnyebbé teszi Linuxon a régi játékok futtatását, némi dicséretet érdemel, és egyik sem többet, mint a Lutris, véleményem szerint. De próbáltál már egy nagyon régi játékot futtatni, és azt találtad, hogy röhejesen kicsi a csicsás, modern HiDPI monitorodon? A felbontásokról, amik ma általánosak, még nem is álmodtak az 1990-es években. Vegyél egy játékot, mondjuk a Space Cadet-et, a klasszikus flipper játékot, amivel sokunk kínosan sok időt töltött.

3D Pinball for Windows – Space Cadet

Ez a játék eredetileg egy csomagban jött a Microsoft Plus! 95-tel, ami egyfajta képességbővítő csomag a Windows 95-höz. 1995-ről beszélünk, 25 évvel ezelőttről a cikk írásának pillanatában. A köznyelvben Space Cadet pinball-ként ismert, az igazi címe 3D Pinball for Windows – Space Cadet, és alapvetően az eredeti Full Tilt! játék egy darab flipper asztalának az újraírása, többnyire az eredeti művészi elemek felhasználásával.

Megjegyzés: Nem teszek közzé semmilyen hivatkozást vagy útmutatót ahhoz, hogy hogyan szerezd meg ennek a játéknak egy példányát.

A "Space Cadet pinball" futtatása Lutris-szal olyan egyszerű, mint a játék hozzáadása, bármelyik legutóbbi Wine verzió használatával. Én személy szerint külön Wine prefixet javaslok minden játékhoz. Számos bemutató videó van ezzel kapcsolatban, ha bizonytalan vagy, de tudd, hogy az alapbeállítások a Lutrisban jók, ahogy vannak.

A játék mindenféle vacakolás nélkül megy, és valahogy így néz ki egy modern Linux PC-n. Rá kell közelíts egy kicsit, hogy lásd. A képernyőkép felbontása 3440x1440.

Mi ez, egy játék hangyáknak? Habár a Lutris-nak van a tarsolyában néhány trükkje, a virtuális asztal nem segít, és a játék teljes képernyőben való futtatása nem teszi semmivel nagyobbá. A Xephyr egy lehetséges megoldás lehet, de mivel extra csomagokat is igényel, és bonyolultabb megoldás, ezért valami mást hoztam.

Az xpra használata

Nagyon egyszerűsített leírás: Az xpra egy okos kis dolog, ami lehetővé teszi egy alkalmazás futtatását egy X szerver-en egy X szerveren belül. Helyileg vagy távoli módon tudja megtenni, ami néhányatokat érdekelhet, de minket most csak egy kis ablak felskálázása érdekel.

A kiváló run_scaled script-et fogjuk használni, amit kaueraal készített, és rendszerszinten (systemwide) fogjuk telepíteni a jelenlegi felhasználód számára. Ezen a módon bármelyik másik játékhoz is használhatod ezt a script-et.

Ezek az instrukciók Debian specifikusak, szóval ha Debian alapú disztribúciót használsz, mint mondjuk az Ubuntu és annak származékai, akkor működnie kellene. Mások a választásuk szerinti disztribúciójukhoz tartozó instrukciókat követhetik.

Instrukciók

• sudo apt install xpra xvfb

Klónozd a run_scaled script-et git-tel, vagy alternatívaként töltsd le manuálisan a fentebbi hivatkozásról. Másold az általad preferált futtatható binárisok könyvtárba. Ebben a példában mi az aktuális ~/.local/bin/ felhasználói könyvtárat fogjuk használni, de ha te valami mást preferálsz, akkor egyszerűen módosítsd az elérési útvonalat. Csak bizonyosodj meg róla, hogy listázva van a $PATH környezeti változóban.

• git clone https://github.com/kaueraal/run_scaled.git
• cd run_scaled/
• cp run_scaled ~/.local/bin/

Nyisd meg a Lutris-t, válaszd ki a játékot, majd válaszd a Configure, System Options fület, görgess le a Command Prefix-ig, és add meg a script-et a kívánt skálázási faktorral. Ebben a példában 3-as faktort használtam, töredékes skálázást használhatsz a monitorod képfelbontásához való finomhangoláshoz. Egynél kisebb változókat is használhatsz.

• run_scaled --scale=3

 Ezt megcsinálva: Így néz ki háromszoros skálázással ugyanazon a monitoron.

Sokkal jobb. Lesz némi hátránya, mivel semmi sem tökéletes. Lehet, hogy a teljesítményt csökkenti, elmosódottság jön létre, és valószínűleg még több dolog, de ez egy megoldás, ami működik. Ha más megoldások nem működtek a régi kedvenc klasszikusaidhoz, ez meglehet, hogy fog.

Forrás:
How-to: upscale old games on Linux with Lutris.

Hogyan írj hatásos dokumentációt a nyílt forráskódú projektedhez?

A dokumentáció minősége jelentős hatással lehet a projektedet kipróbáló (vagy az arra rátaláló) emberekre.

Sajnos a jó kód nem beszél önmagáért. Még a világ legsürgetőbb problémáját megoldó, legelegánsabban megtervezett és jól megírt kódbázis sem megy át magától. Neked, a nyílt forráskódú alkotónak, beszélned kell a kódodért, és életet kell lehelned alkotásodba. Itt jön képbe a technikai írás és dokumentáció.

Egy projekt dokumentáció generálja messze a legnagyobb forgalmat. Ez az a hely, ahol az emberek eldöntik, folytatják-e a projekteddel kapcsolatos tanulást, ismerkedést, vagy továbbállnak. Ezért az idő és az energiabefektetés a dokumentációba és a technikai írásba, a kezdeti lépésekre összpontosítva, csodákat fog tenni a projekted fogadtatása számára.

Az írás kellemetlen, vagy akár megfélemlítő lehet sokatok számára. A mérnökök a kódírásra vannak kiképezve, nem a kóddal kapcsolatos írásra. Sok ember második vagy akár harmadik nyelvként beszéli az angolt, és bizonytalannak vagy megfélemlítettnek érezheti magát angol szöveg írása közben. Én második nyelvként tanultam meg az angolt, számomra viszonylag könnyű volt, de nem mindenki mondhatja el ezt.

De nem kerülhetjük meg a valóságot, hogy ha egy projektnek széles, globális térnyerést szeretnél, az angol az a nyelv, amelyet muszáj használnod. Ne félj. Ezt a bejegyzést ezen kihívások tudatában írtam. Nem kell a következő Shakespeare-nek lenned, hogy az itt található javaslatokat hasznosnak találd.

Öt gyakorlati tipp

Itt van öt gyakorlati írási tipp, amelyet már ma felhasználhatsz. Talán fájdalmasan egyszerűnek és egyértelműnek tűnhetnek, mégis újra és újra figyelmen kívül vannak hagyva technikai írásokban.

1. Használj cselekvő igenemet: Cselekvő igenem: "Megváltoztathatod ezeket a beállításokat azáltal, hogy", a szenvedő szerkezettel szemben: "Ezek a beállítások megváltoztathatók azáltal, hogy".
2. Használj egyszerű, rövid mondatokat: Bár nem nyílt forráskódú projektek, de a Hemingway App és a Grammarly egyaránt hasznos segédeszközök.
3. Formázd könnyű olvashatóságra: Használj fejezetcímeket, felsorolásokat, hivatkozásokat, hogy tömbökbe törd az információt, hosszú, magyarázó paragrafusok helyett.
4. Tartsd meg vizuálisnak: Használj táblázatokat és grafikonokat, nem mondatokat, hogy több dimenzióval ábrázold az információt.
5. Figyelj a helyesírásra és nyelvtanra: Mindig, mindig, mindig ellenőrizd az elgépeléseket és nyelvtani hibákat, hogy csiszolj a szövegen.

Azáltal, hogy folyamatosan alkalmazod ezeket a tippeket az írásodban és munkafolyamatodban, két nagy célt érsz el vele: hatékony kommunikációt és bizalomépítést.

• Hatékony kommunikáció: A mérnökök nem akarnak hosszú, terjengős paragrafusokat olvasni dokumentációkban (a novellák vannak nekik erre a célra). Olyan hatékony technikai információkat vagy instrukciókat szeretnének (amikor útmutatóról van szó), amennyire csak lehet. Ezért az írásodnak száraznak és hasznosnak kell lennie. Ennek ellenére némi humor, hangulatjel, "pihe" használata rendben van, hogy némi személyiséget adj a projektednek, és még emlékezetesebbé tedd. Hogy ezt pontosan hogyan csinálod, az a te személyiségeden múlik.
• Bizalomépítés: A legértékesebb valuta, amit muszáj felhalmoznod, különösen a projekted építésének korai szakaszában, az a bizalom. A bizalom nem csak a kódod minőségéből jön, hanem az írás minőségéből is, ami a kódodról beszél. Ezért, kérlek használd ugyanazokat a csinosításokat az írásodra, amiket a kódodra használnál. Ez a fő indok a fenti ötös ponthoz (a helyesírás és nyelvtan ellenőrzése).

Kezdés a "kezdeti lépések" dokumentációval

Ezen alapvető technikák írásodba szövésével, a dokumentáció azon része, amivel a legtöbb időt kellene töltened, az az első lépések. Ez messze a legfontosabb rész, egy klasszikus példája a 80/20-as elvnek a gyakorlatban. A terméked webes forgalmának legnagyobb része a dokumentációra érkezik, ennek a legnagyobb része pedig a kezdeti lépésekhez. Ha remekül van összerakva, akkor rögtön kapni fogsz egy új felhasználót. Ha nem, akkor a látogató elkattint, és valószínűleg soha nem jön vissza.

Hogyan rakj össze jól egy kezdeti lépések részt? Az alábbi három lépéses folyamatot ajánlom:

1. Csináld meg feladatnak: Egy hatásos kezdeti lépések dokumentációnak feladat-orientáltnak kellene lennie - egy diszkrét mini-project, amit egy fejlesztő el tud érni. Nem kellene túl sok információt tartalmaznia a felépítési designról, fő koncepcióról és egyéb magas szintű információkról. Egy egyszeri, vizuális felépítési design rendben van, de ne szánj több paragrafust arra, hogy miért a te projekted a legjobban felépített megoldás. Az az információ máshova tartozik (bővebben erről lentebb). Ehelyett a kezdeti lépések résznek egy lépés és parancslistának kellene lennie... Nos, a kezdeti lépésekhez.
2. Befejezhető kevesebb mint 30 perc alatt: Itt a legfontosabb húzóerő, hogy a befejezéshez szükséges idő olyan alacsony legyen, amennyire csak lehet: 30 perc a felső határ. Ez az időlimit azt is feltételezi, hogy a felhasználónak relatív kis ismerete van a projekteddel kapcsolatban. Ezt fontos észben tartani. A legtöbb ember, akik a kezdeti lépések útmutatódon való végigmenéssel vesződnek, egy technikai közönség tagjai a projekted bizonytalan megértésével, de nem sokkal többel annál. Azért vannak ott, hogy kipróbáljanak valamit, mielőtt eldöntik, hogy töltsenek-e több időt a mélyebbre ásással. A "befejezési idő" egy mérőszám, amit mérned kellene, hogy folyamatosan fejleszd a kezdeti lépések útmutatódat.
3. Csinálj valami jelentőségteljeset: A "jelentőségteljes" a nyílt forráskódú projekten múlik. Fontos erősen elgondolkozni azon, hogy mi az, szilárdan feladatban meghatározni, és lehetővé tenni egy fejlesztőnek, aki befejezi a kezdeti lépések útmutatódat, hogy véghez vigye ezt a jelentőségteljes feladatot. Ennek a jelentőségteljes feladatnak muszáj, hogy közvetlenül a projekted értékéhez szóljon, egyébként a fejlesztők úgy fogják érezni, hogy vesztegették az idejüket.

Inspirációnak: Ha a projekted egy elosztott adatbázis projekt, akkor meglehet, hogy a "jelentőségteljes" azt jelenti, hogy az egész fürt (cluster) maradjon elérhető kiesések nélkül, ha kilősz néhány csomópontot (node). Ha a projekted adatelemzéssel vagy üzleti ismeretekkel kapcsolatos eszközzel kapcsolatos, akkor meglehet, hogy a "jelentőségteljes" egy dashboard generálása különböző vizualizációkkal, miután betöltött némi adatot. Bármit is jelentsen a "jelentőségteljes" a projektednek, gyorsan és helyileg elérhetőnek kellene lennie egy laptopon.

Egy jó példa a Linkerd Getting Started-je. A Linkerd egy szolgáltatási háló (service mesh) a Kuberneteshez és más keretrendszerekhez. Én kezdő vagyok a Kubernetesben, és még annál is kevésbé ismerős a service mesh-ben. Mégis mindenféle macera nélkül végigmentem a Linkerd Getting Started útmutatóján egy laptopon, és ez megízleltette velem, hogy miről is szól egy service mesh kezelése.

A fenti három lépéses folyamat egy hasznos keretrendszer lehet nagyon hatékony kezdeti lépések útmutató elkészítéséhez, egy mérhető módon. Kapcsolódik az idő-érték mérőhöz is, amikor egy nyílt forráskódú projekted termékesítéséről van szó.

Egyéb alapvető komponensek

Amellett, hogy figyelmesen kalibrálod és optimizálod a kezdeti lépések útmutatódat, van öt másik felső szintű komponens, ami ahhoz szükséges, hogy teljes értékű dokumentációt építs: felépítési design, gyártásbeli használati útmutató, felhasználási lehetőségek, referenciák, és ütemterv.

• Felépítési design: Ez egy mély-merülés a projekted felépítésébe és a design-nal kapcsolatos döntéseid mögötti elvekbe. Mindennel kapcsolatos részletek, amiket stratégiailag megmagyaráztál a kezdeti lépések útmutatódban. Ez a részleg egy nagy része a teljes termékmarketing tervednek. Ez a részleg általában tele van vizuális elemekkel, rajzokkal, és arra hivatott, hogy egy hétköznapi hobbistát szakértő rajongóvá változtasson, aki abban érdekelt, hogy időt fektessen a projektedbe hosszú távon.
• Gyártásbeli használati útmutató: Egy világnyi különbség van aközött, hogy kipróbálni valamit egy laptopon, vagy gyártásra használni. Rávezetni egy felhasználót, aki a projektedet komolyabban szeretné használni, egy fontos következő lépés. Gyártásbeli kezelési tudást bemutatni egy módja is annak, hogy hogyan vonzd be a kezdeti üzleti ügyfeleidet, akik kedvelhetik a technológia ígéretét, de nem tudják, vagy nem érzik magukat magabiztosnak arra, hogy gyártási környezetben használják.
• Felhasználási lehetőségek: A közösségi bizonyíték értéke egyértelmű, szóval a projektedet gyártásra használók listázása fontos. A kulcs itt az, hogy megbizonyosodj róla, hogy ez az információ könnyen megtalálható. Valószínűleg a második legnépszerűbb hivatkozás lesz a kezdeti lépések után.
• Referenciák: Ez a részleg elmagyarázza a projektedet részletesen, és lehetővé teszi a felhasználónak, hogy megvizsgálja és megértse mikroszkóp alatt. Ez "szótár"-ként is funkcionál, ahol az emberek információt keresnek fel, amikor szükséges. Néhány nyílt forráskódú alkotó mértéktelen időt tölt a projektje minden egyes apróságának és élének kihangsúlyozásával. A motiváció érthető, de onnantól kezdve szükségtelen, amikor az időd limitált. Hatásosabb egyensúlyt elérni a részletesség és a segítség szerzés módjai között: hivatkozás a közösségi fórumodra, Stack Overflow cédula, vagy egy külső GYIK (Gyakran Ismételt Kérdések) oldal is megteheti.
• Ütemterv: A jövőbeli elképzeléseid és terveid kiterítése egy vázlatos idővonallal megtarthatják a felhasználók érdeklődését és ösztönözöttségüket hosszabb távra. A projekted talán nem tökéletes jelenleg, de van egy terved a tökéletesítésére. Az ütemterv arra is remek hely, hogy összehozd a közösségedet egy erős ökoszisztéma építésére, szóval bizonyosodj meg róla, hogy hagysz egy hivatkozást, ahol az emberek hangot adhatnak gondolataiknak és véleményüknek az ütemtervvel kapcsolatban (fogok írni közösségépítési konkrétumokról a jövőben).

Meglehet, hogy még nincsenek meg neked teljesen ezek a komponensek, és néhány rész később valósul meg, mint mások, különösen a felhasználási lehetőségek. Azonban legyél szándékos ezeknek a kiépítésével időben. Ezen öt elemek megvalósítása a kritikus következő lépés a felhasználóid projektedbe való "utazásának", feltételezve, hogy jó tapasztalatuk van a kezdeti lépések útmutatóval.

Egy végső megjegyzés: Tegyél bele egy tiszta egymondatos állítást azzal kapcsolatban, hogy milyen licencet használsz (valószínűleg a kezdeti lépésekben, vagy az olvassel-ben, vagy valami más jól látható helyen). Ez az apróság a végfelhasználó oldaláról sokkal hatékonyabb használatba vételt eredményez.

Töltsd az időt 20%-át írással

Általánosságban az időd 10-20 %-át írással töltéssel javaslom. Kontextusba helyezés: Ha teljes munkaidőben dolgozol a projekteden, akkor körülbelül heti fél naptól egy napig. A még árnyaltabb pont itt az, hogy az írással kellene dolgoznod az átlagos munkafolyamatodban. szóval így rutinná válik, nem pedig egy elzárt munkává. Az idővel növekedő folyamat, az egész írás egyszerre történő megírásával szemben, az, ami segíteni fog, hogy a projekted elérje végső célját: húzóerő és bizalom.

Forrás: How to write effective documentation for your open source project.