Have you ever been to a (tech-) event where you didn't know anyone, but everyone else seemed to stand in groups and chat like old friends? (...) Now imagine you want to contribute to an open source project, but you don't see why or how this is happening.
-— @janl, ["Sustainable Open Source"](http://writing.jan.io/2015/11/20/sustainable-open-source.html) +— @janl, ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
@@ -117,10 +118,10 @@ Any popular project will inevitably attract people who harm, rather than help, y Do your best to adopt a zero-tolerance policy towards these types of people. If left unchecked, negative people will make other people in your community uncomfortable. They may even leave. @@ -136,23 +137,23 @@ In your CONTRIBUTING file, explicitly tell new contributors how to get started.  -In your issue queue, label bugs that are suitable for different types of contributors: for example, [_"first timers only"_](https://medium.com/@kentcdodds/first-timers-only-78281ea47455#.g1k01jy05), _"good first issue"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) make it easy for someone new to your project to quickly scan your issues and get started. +In your issue queue, label bugs that are suitable for different types of contributors: for example, [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) make it easy for someone new to your project to quickly scan your issues and get started. Finally, use your documentation to make people feel welcome at every step of the way. You will never interact with most people who land on your project. There may be contributions you didn't receive because somebody felt intimidated or didn't know where to get started. Even a few kind words can keep someone from leaving your project in frustration. -For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts [its contributing guide](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md): +For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md): > We want to start off by saying thank you for using Rubinius. This project is a labor of love, and we appreciate all of the users that catch bugs, make performance improvements, and help with documentation. Every contribution is meaningful, so thank you for participating. That being said, here are a few guidelines that we ask you to follow so we can successfully address your issue. ### Share ownership of your project @@ -164,7 +165,7 @@ See if you can find ways to share ownership with your community as much as possi  -* **Start a CONTRIBUTORS or AUTHORS file in your project** that lists everyone who's contributed to your project, like [Sinatra](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md) does. +* **Start a CONTRIBUTORS or AUTHORS file in your project** that lists everyone who's contributed to your project, like [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) does. * If you've got a sizable community, **send out a newsletter or write a blog post** thanking contributors. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) are two good examples. @@ -254,7 +255,7 @@ If a conversation clearly isn't going anywhere, there are no clear actions to be
Guiding a thread toward usefulness without being pushy is an art. It won't work to simply admonish people to stop wasting their time, or to ask them not to post unless they have something constructive to say. (...) Instead, you have to suggest conditions for further progress: give people a route, a path to follow that leads to the results you want, yet without sounding like you're dictating conduct.
-— @kfogel, [_Producing OSS_](http://producingoss.com/en/producingoss.html#common-pitfalls) +— @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
diff --git a/_articles/code-of-conduct.md b/_articles/code-of-conduct.md index 432ebad723c956055cdac375856a96f6a65d9b85..0b21e42d4583e4d1a5c8b49400372b607e5b7a09 100644 --- a/_articles/code-of-conduct.md +++ b/_articles/code-of-conduct.md @@ -8,6 +8,7 @@ toc: establishing-a-code-of-conduct: "Establishing a code of conduct" deciding-how-youll-enforce-your-code-of-conduct: "Deciding how you’ll enforce your code of conduct" enforcing-your-code-of-conduct: "Enforcing your code of conduct" + your-responsibilities-as-a-maintainer: "Your responsibilities as a maintainer" order: 8 image: /assets/images/cards/coc.png related: @@ -59,7 +60,7 @@ You should explain how your code of conduct will be enforced **_before_** a viol You should give people a private way (such as an email address) to report a code of conduct violation and explain who receives that report. It could be a maintainer, a group of maintainers, or a code of conduct working group. -Don't forget that someone might want to report a violation about a person who receives those reports. In this case, give them an option to report violations to someone else. For example, @ctb and @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): +Don't forget that someone might want to report a violation about a person who receives those reports. In this case, give them an option to report violations to someone else. For example, @ctb and @mr-c [explain on their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): > Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.* diff --git a/_articles/de/best-practices.md b/_articles/de/best-practices.md new file mode 100644 index 0000000000000000000000000000000000000000..10cc7bdd7fa7ac1d5f73913fdc73ae7db055f5f0 --- /dev/null +++ b/_articles/de/best-practices.md @@ -0,0 +1,312 @@ +--- +lang: de +title: Gute Maintainer-Praxis +description: Erleichtern Sie Ihr Leben als Open-Source-Maintainer! Von der Dokumentation von Prozessen bis zum Einsatz Ihrer Community. +class: best-practices +order: 5 +image: /assets/images/cards/best-practices.png +related: + - metrics + - leadership +--- + +## Was bedeutet es, eine Software instand zu halten? + +Wenn Sie ein Open-Source-Projekt pflegen, welches viele Leute benutzen, haben Sie vielleicht bemerkt, dass Sie weniger programmieren und mehr auf Issues reagieren. + +In der Anfangsphase eines Projekts experimentieren Sie mit neuen Ideen und treffen Entscheidungen nach Ihren Wünschen. Da Ihr Projekt immer beliebter wird, werden Sie mehr mit Ihren Benutzer\*innen und Mitwirkenden zusammenarbeiten. + +Die Instandhaltung eines Projekts erfordert mehr als nur Code. Diese Aufgaben sind oft unerwartet, aber genauso wichtig für ein wachsendes Projekt. Wir haben einige Möglichkeiten zusammengestellt, um Ihnen das Leben zu erleichtern, von der Dokumentation von Prozessen bis hin zur Nutzung Ihrer Community. + +## Dokumentieren Sie Ihre Prozesse + +Dinge aufzuschreiben, ist eine der wichtigsten Aufgaben, die Sie als Maintainer\*in erledigt. + +Dokumentation verdeutlicht nicht nur Ihr eigenes Denken, sondern macht auch anderen Menschen verständlich, was Sie brauchen oder erwarten, bevor sie überhaupt fragen. + +Dinge aufzuschreiben, erleichtert das "Nein" sagen, wenn etwas nicht in Ihren Projektrahmen passt. Es macht es auch einfacher für die Menschen, mitzumachen und zu helfen. Sie wissen nie, wer Ihr Projekt lesen oder nutzen könnte. + +Selbst wenn Sie keine vollständigen Absätze niederschreiben: besser Stichworte aufzulisten, als gar nichts zu schreiben. + +Denken Sie daran, Ihre Dokumentation auf dem neuesten Stand zu halten. Wenn Sie dies nicht immer tun können, löschen Sie Veraltetes oder markieren es als solches, damit Mitwirkende wissen, dass Updates gerne angenommen werden. + +### Schreiben Sie Ihre Projektvision auf + +Schreiben Sie zunächst die Ziele Ihres Projekts auf. Fügen Sie sie Ihrer README hinzu oder erstellen Sie eine separate Datei namens VISION. Wenn es andere dafür nützliche Artefakte gibt (z.B. eine Projekt-Roadmap) machen Sie auch diese öffentlich. + +Eine klare, dokumentierte Vision hilft Ihnen, sich zu konzentrieren und den "Scope Creep" durch Beiträge anderer zu vermeiden. + +Zum Beispiel entdeckte @lord, dass eine Projektvision ihm herauszufinden half, in welche Anfragen er Zeit stecken sollte. Als frisch gebackener Maintainer bedauerte er, dass er sich nicht auf den Kern seines Projekts fokussiert hat, als er seine erste Feature-Anfrage für [Slate](https://github.com/lord/slate) erhielt. + + + +### Kommunizieren Sie Ihre Erwartungen + +Es kann nervenaufreibend sein, Regeln niederzuschreiben. Manchmal hat man das Gefühl, das Verhalten anderer Leute zu überwachen, oder ein Spaßverderber zu sein. + +Allerdings sind niedergeschriebene und fair durchgesetzte Regeln nützlich für Projektbetreuer\*innen. Sie verhindern, dass man in Dinge hineingezogen wird, die man nicht tun will. + +Die meisten Menschen, die auf Ihr Projekt stoßen, wissen nichts über Sie oder Ihre Lebensumstände. Sie vermuten vielleicht, dass Sie dafür bezahlt werden, daran zu arbeiten, insbesondere wenn sie Ihr Projekt regelmäßig benutzen und davon abhängig sind. Vielleicht haben Sie mal viel Zeit in Ihr Projekt gesteckt, sind aber jetzt mit einem neuen Job oder Familienmitglied beschäftigt. + +All das ist völlig in Ordnung! Stellen Sie nur sicher, dass andere davon erfahren. + +Wenn Sie Ihr Projekt in Teilzeit oder auf freiwilliger Basis betreuen, seien Sie ehrlich, wie viel Zeit Ihnen zur Verfügung steht. Die weicht vermutlich von der Zeit ab, die Ihrer Meinung nach für das Projekt benötigt wird, oder die andere erwarten. + +Hier sind ein paar Regeln, die es wert sind, aufgeschrieben zu werden: + +* Wie ein Beitrag geprüft und akzeptiert wird (_Benötigen sie Tests? Ein Issue-Template?_) +* Die Arten von Beiträgen, die Sie akzeptieren werden (_Wollen Sie nur Hilfe bei einem bestimmten Teil Ihres Codes?_) +* Wenn es angebracht ist, den Vorgang zu verfolgen (z.B. _"Sie können innerhalb von 7 Tagen eine Antwort von einer Betreuerin oder einem Betreuer erwarten. Wenn Sie bis dahin noch nichts gehört haben, können Sie gerne den Thread pingen."_) +* Wie viel Zeit Sie für das Projekt aufwenden (z.B. _"Wir verbringen nur ca. 5 Stunden pro Woche für dieses Projekt"_) + +[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules) und [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) bspw. geben ihren Betreuer\*innen und Mitwirkenden nützliche Grundregeln mit. + +### Kommunikation öffentlich halten + +Vergessen Sie nicht, auch Ihre Interaktionen zu dokumentieren. Wo immer Sie können, halten Sie die Kommunikation über Ihr Projekt öffentlich. Wenn jemand versucht, Sie privat zu kontaktieren, um eine Feature- oder Support-Anfrage zu besprechen, verweisen Sie sich höflich an einen öffentlichen Kommunikationskanal, wie z.B. eine Mailingliste oder einen Issue Tracker. + +Wenn Sie sich mit anderen Betreuer\*innen treffen oder eine wichtige Entscheidung privat treffen, dokumentieren Sie diese Gespräche in der Öffentlichkeit, selbst wenn es nur um die Veröffentlichung einer Notiz geht. + +Auf diese Weise haben alle Neulinge in Ihrer Community die selben Informationsmöglichkeiten wie Alteingesessene. + +## Lernen, "Nein" zu sagen + +Sie haben Dinge aufgeschrieben, und im Idealfall würden auch alle Ihre Dokumentation lesen. Allerdings werden Sie in Wirklichkeit andere daran erinnern müssen, dass dieses Wissen existiert. + +Alles zu verschriftlichen hilft, persönliche Befindlichkeiten aus Situationen zu entfernen, in denen Sie Ihre Regeln durchsetzen müssen. + +"Nein" zu sagen macht keinen Spaß, aber _"Ihr Beitrag entspricht nicht den Kriterien dieses Projekts"_ fühlt sich weniger persönlich an als _"Ich mag Ihren Beitrag nicht"_. + +"Nein" zu sagen hilft in viele Situationen, in denen Sie als Maintainer\*in auftreten werden: unnötige Arbeit für andere erledigen, nicht in den Anwendungsbereich passende Feature-Anfragen, jemand zur Ordnung rufen, der eine Diskussion entgleist, usw. + +### Das Gespräch freundlich halten + +Die wichtigsten Orte, an denen Sie üben werden "Nein" zu sagen, sind Ihr Issue Tracker und die Pull-Request-Liste. Als Projektbetreuer\*in werden Sie unweigerlich Vorschläge erhalten, die Sie nicht akzeptieren wollen. + +Vielleicht verändert ein dort eingereichter Beitrag den Umfang Ihres Projekts oder passt nicht zu Ihrer Vision. Vielleicht ist die Idee gut, aber schlecht umgesetzt. + +Unabhängig vom Ablehnungsgrund ist es möglich, Beiträge, die nicht den Standards Ihres Projekts entsprechen, taktvoll zu behandeln. + +Wenn Sie einen Beitrag erhalten, den Sie nicht annehmen möchten, könnte Ihre erste Reaktion darin bestehen, ihn zu ignorieren oder so zu tun, als ob Sie ihn nicht gesehen hätten. Dies könnte die Gefühle anderer Personen verletzen und sogar andere potenzielle Mitwirkende in Ihrer Gemeinschaft demotivieren. + + + +Lassen Sie keinen unerwünschten Beitrag offen, weil Sie sich schuldig fühlen oder nett sein wollen. Im Laufe der Zeit werden unbeantwortete Issues und PRs die Projektarbeit stressiger und einschüchternder machen. + +Schließen Sie Beiträge lieber sofort, von denen Sie wissen, dass Sie sie nicht annehmen wollen. Wenn Ihr Projekt bereits unter einem großen Rückstand leidet, hat @steveklabnik Vorschläge für [eine effiziente Behandlung von Issues](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) (Englisch). + +Zweitens sendet das Ignorieren von Beiträgen ein negatives Signal an die Gemeinschaft um Ihr Projekt. Einen Projektbeitrag einzureichen, kann einschüchternd sein, besonders für Neulinge. Auch wenn Sie ihren Beitrag nicht annehmen, danken Sie der einreichenden Person für ihr Interesse. Das ist ein großes Kompliment! + +Wenn Sie einen Betrag nicht annehmen wollen: + +* **Bedanken** Sie sich für den Beitrag. +* **Erklären Sie, warum es nicht in den Rahmen des Projekts passt** und geben Sie klare Verbesserungsvorschläge, wenn Sie dazu in der Lage sind. Seien Sie dabei freundlich, aber bestimmt. +* **Verlinken Sie auf die entsprechende Dokumentation**, wenn Sie diese haben. Wenn Sie wiederholt ähnliche Beiträge bekommen, die Sie nicht akzeptieren wollen, weisen Sie darauf in Ihrer Dokumentation hin, um weitere Wiederholungen zu vermeiden. +* **Schließen Sie die Anfrage** + +Sie sollten nicht mehr als 1-2 Sätze benötigen, um zu antworten. Als beispielsweise ein Benutzer von [celery](https://github.com/celery/celery/) einen Windows-bezogenen Fehler meldete, [antwortet](https://github.com/celery/celery/issues/3383) @berkerpeksag mit: + + + +Wenn Ihnen der Gedanke, "Nein" zu sagen, Angst macht, sind Sie nicht allein. Wie @jessfraz [es formulierte](https://blog.jessfraz.com/post/the-art-of-closing/): + +> Ich habe mit Maintainern aus verschiedenen Open-Source-Projekten gesprochen, Mesos, Kubernetes, Chromium, und sie alle sind sich einig, dass einer der schwierigsten Aufgaben des Maintainertums darin besteht, "Nein" zu Patches zu sagen, die man nicht will. +> +> I've talked to maintainers from several different open source projects, Mesos, Kubernetes, Chromium, and they all agree one of the hardest parts of being a maintainer is saying "No" to patches you don't want. + +Fühlen Sie sich nicht schuldig, weil Sie den Beitrag von jemandem nicht annehmen wollen. Die erste Regel in Open-Source-Projekten, [nach](https://twitter.com/solomonstre/status/715277134978113536) @shykes lautet: "'Nein' ist vorübergehend. 'Ja' ist für immer." Obwohl es gut ist, sich in die Begeisterung einer anderen Person hineinzufühlen, ist die Ablehnung eines Beitrags nicht dasselbe wie die Ablehnung der Person dahinter. + +Wenn ein Beitrag nicht gut genug ist, sind Sie nicht verpflichtet, ihn anzunehmen. Seien Sie freundlich und reaktionsschnell, wenn Menschen zu Ihrem Projekt beitragen möchten. Aber akzeptieren Sie nur Änderungen, von denen Sie wirklich glauben, dass sie Ihr Projekt verbessern werden. Je öfter Sie "Nein" sagen, desto einfacher wird es. Versprochen. + +### Seien Sie proaktiv + +Um das Volumen der unerwünschten Beiträge zu reduzieren, erklären Sie den Prozess der Einreichung und Annahme von Beiträgen in einem "Contribution Guide". + +Wenn Sie zu viele minderwertige Beiträge erhalten, verlangen Sie zum Beispiel, dass die Mitwirkenden vorher ein wenig Arbeit leisten, z.B.: + +* eine Issue- oder PR-Vorlage/-Checkliste ausfüllen +* ein Issue erstellen, bevor sie ein Pull Request einreichen + +Wer nicht Ihren Regeln folgt, dessen Issue können Sie sofort schließen und dabei auf Ihre Dokumentation verweisen. + +Auch wenn sich dieser Ansatz zunächst unfreundlich anfühlt, ist es für beide Seiten gut, proaktiv zu sein. Es verringert die Chance, dass jemand zu viele Arbeitsstunden in ein Pull Request vergeudete, das Sie nicht akzeptieren werden. Und es macht Ihre Arbeit einfacher zu verwalten. + + + +Manchmal, wenn Sie "Nein" sagen, kann Ihr potenzieller Mitwirkender verärgert sein oder Ihre Entscheidung kritisieren. Wenn deren Verhalten feindselig wird, unternehmen Sie [Schritte, um die Situation zu entschärfen](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) oder entfernen Sie sie sogar aus Ihrer Gemeinschaft, wenn keine Bereitschaft zur konstruktiven Zusammenarbeit erkennbar ist. + +### Mentorschaft etablieren + +Vielleicht reicht jemand in Ihrer Community regelmäßig Beiträge ein, die nicht den Standards Ihres Projekts entsprechen. Es kann für beide Seiten frustrierend sein, immer wieder Ablehnungen zu erfahren. + +Wenn Sie sehen, dass jemand von Ihrem Projekt begeistert ist, aber ein wenig aufpoliert werden muss, haben Sie Geduld. Erklären Sie in jeder Situation deutlich, warum ein Beitrag nicht den Erwartungen des Projekts entspricht. Versuchen Sie, sie auf eine einfachere oder weniger zweideutige Aufgabe hinzuweisen. Beispielsweise ein Problem, das mit _"good first issue"_ gekennzeichnet ist. Wenn Sie die Zeit dazu haben, erwägen Sie folgendes: Die oder den Mitwirkenden durch den ersten Beitragsprozess hindurch anzuleiten oder finden Sie in Ihrer Community jemanden, der/die zu einer solchen Betreuung bereit sein könnte. + +## Nutzen Sie Ihre Community + +Sie müssen nicht alles selbst machen. Die Gemeinschaft Ihres Projekts existiert aus einem bestimmten Grund! Auch wenn Sie noch keine aktiv Beitragenden haben: Viele Benutzer\*innen können Ihnen bei der Projektarbeit helfen. + +### Teilen Sie die Arbeitslast + +Wenn Sie auf der Suche nach Mitwirkenden sind, fragen Sie doch einfach mal herum. + +Sie können auch [Issues, die für Anfänger einfach genug sind, explizit markieren (Englisch)](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub weist auf solche Issues vermehrt hin, sodass beitragswillige Neulinge zu nützlicher Mitarbeit ermuntert werden. + +Wenn Sie neue Mitwirkende bemerken, die wiederholt Beiträge leisten, erkennen Sie deren Arbeit an, indem Sie ihnen mehr Verantwortung anbieten. Dokumentieren Sie, wie andere in Führungsrollen hineinwachsen können, wenn sie es wünschen. + +Andere zu ermutigen, [sich am Projekt zu beteiligen](../building-community/#teilen-sie-die-eigentümerschaft-an-ihrem-projekt), kann den eigenen Arbeitsaufwand erheblich reduzieren, wie @lmccart in ihrem Projekt [p5.js](https://github.com/processing/p5.js) feststellte. + + + +Wenn Sie sich aus Ihrem Projekt zurückziehen müssen (egal ob temporär oder auf Dauer), ist es keine Schande, jemand anders zu bitten, für Sie zu übernehmen. + +Wenn andere Leute von Ihrer Projektrichtung begeistert sind, gewähren Sie ihnen Commit-Rechte oder übergeben Sie formell die Kontrolle. Wenn jemand einen Fork Ihres Projektes erstellt hat, und es an anderer Stelle aktiv pflegt, sollten Sie in Erwägung ziehen, aus Ihrem ursprünglichen Projekt heraus auf den Fork zu verweisen. Es ist großartig, dass Menschen Ihr Projekt weiterleben sehen wollen! + +@progrium [fand heraus](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) (Englisch), dass es seinem Projekt [Dokku](https://github.com/dokku/dokku) auch nach seinem Rückzug weiter zu leben half, dass er die Vision dokumentiert hatte, + +> Ich habe eine Wiki-Seite geschrieben, die beschreibt, was ich wollte und warum ich es wollte. Aus irgendeinem Grund war es für mich eine Überraschung, dass die Maintainer\*innen das Projekt in diese Richtung bewegten! Ist es genau so passiert, wie ich es getan habe? Nicht immer. Aber sie brachten das Projekt trotzdem näher an das heran, was ich aufgeschrieben habe. +> +> I wrote a wiki page describing what I wanted and why I wanted it. For some reason it came as a surprise to me that the maintainers started moving the project in that direction! Did it happen exactly how I'd do it? Not always. But it still brought the project closer to what I wrote down. + +### Lassen Sie andere ihre eigenen Lösungen bauen + +Wenn ein potenzieller Mitwirkender eine andere Meinung über das Ziel Ihres Projekt hat, sollten Sie ihn oder sie vielleicht sanft ermutigen, an einem eigenem Fork zu arbeiten. + +Ein Projekt zu forken, muss keine schlechte Sache sein. Projekte kopieren und modifizieren zu können, ist eine der besten Möglichkeiten, die Open Source mitbringt. Ihre Community-Mitglieder zur Arbeit an eigenen Forks zu ermutigen, kann ein notwendiges Ventil für Kreativität bieten, die nicht mit der Vision Ihres Projekts in Konflikt gerät. + + + +Das Gleiche gilt für Benutzer\*innen, die wirklich eine Lösung haben möchten, deren Erstellung Sie einfach nicht leisten können. Das Anbieten von APIs und Plugin-Systemen kann anderen helfen, ihre eigenen Bedürfnisse zu erfüllen, ohne den Quellcode direkt ändern zu müssen. @orta [fand heraus](https://artsy.github.io/blog/2016/07/03/handling-big-projects/), dass Plugins für CocoaPods zu "einigen der interessantesten Ideen" führten: + +> Es ist fast unvermeidlich, dass Maintainer, sobald ein Projekt groß wird, viel konservativer werden müssen, was die Einführung von neuem Code angeht. Sie werden gut darin, "Nein" zu sagen, aber viele Menschen haben legitime Bedürfnisse. Verwandeln Sie also Ihr Werkzeug in eine Plattform. +> +> It's almost inevitable that once a project becomes big, maintainers have to become a lot more conservative about how they introduce new code. You become good at saying "no", but a lot of people have legitimate needs. So, instead you end up converting your tool into a platform. + +## Delegieren Sie an Bots + +So wie es Aufgaben gibt, die andere Menschen Ihnen abnehmen können, gibt es auch Aufgaben, die kein Mensch jemals zu erledigen haben sollte. Bots sind Ihre Freunde. Verwenden Sie sie, um sich Ihr Leben als Maintainer\*in zu erleichtern. + +### Verlangen Sie Tests und andere Kontrollen, um die Codequalität zu verbessern. + +Eine der wichtigsten Möglichkeiten, wie Sie Ihr Projekt automatisieren können, ist das Hinzufügen von Tests. + +Tests geben Mitwirkenden den Mut zu Änderungsvorschlägen, denn sie können nichts (unbemerkt) kaputt machen. Sie erleichtern es sich damit auch selbst, Beiträge schnell zu prüfen und anzunehmen. Je reaktionsschneller Sie sind, desto engagierter kann Ihre Gemeinschaft sein. + +Richten Sie automatische Tests ein, die bei allen eingehenden Beiträgen ausgeführt werden und stellen Sie sicher, dass Ihre Tests problemlos lokal von den Mitwirkenden ausgeführt werden können. Verlangen Sie, dass alle Codebeiträge Ihre Tests bestehen, bevor sie eingereicht werden können. Sie sichern einen Mindeststandards für die Qualität aller Einreichungen. [Verpflichtende Status-Checks](https://help.github.com/articles/about-required-status-checks/) auf GitHub können dazu beitragen, dass keine Änderungsvorschläge angenommen werden, die nicht Ihre Tests bestanden werden. + +Wenn Sie Tests hinzufügen, erklären Sie deren Funktionsweise in Ihrer CONTRIBUTING-Datei. + + + +### Automatisieren Sie grundlegende Wartungsaufgaben + +Viele Maintainer\*innen populärer Projekte sind mit ähnlichen Problemen konfrontiert, darum gibt es [viele fertig entwickelte Lösung](https://github.com/showcases/tools-for-open-source), die Wartungsarbeiten automatisieren können. Einige Beispiele: + +* [semantic-release](https://github.com/semantic-release/semantic-release) automatisiert Ihre Veröffentlichungen +* [mention-bot](https://github.com/facebook/mention-bot) erwähnt potentielle Reviewer für Pull Requests +* [Danger](https://github.com/danger/danger) hilft bei der Automatisierung des Code Review +* [no-response](https://github.com/probot/no-response) schließt Issues deren Autor\*in nicht auf Nachfragen antwortet +* [dependabot-preview](https://github.com/marketplace/dependabot-preview) prüft bekannte Abhängigkeitsdateien täglich und eröffnet Pull Requests, sobald Aktualisierungen verfügbar werden + +Für Fehlerberichte und andere allgemeine Beiträge hat GitHub [Issue- und Pull-Request-Templates](https://github.com/blog/2111-issue-and-pull-request-templates), die Sie erstellen können, um die Kommunikation zu optimieren. @TalAter hat einen [Choose Your Own Adventure Guide](https://www.talater.com/open-source-templates/#/) erstellt, der Ihnen beim Schreiben dieser Vorlagen hilft. + +Um Ihre E-Mail-Benachrichtigungen zu verwalten, können Sie [E-Mail-Filter](https://github.com/blog/2203-email-updates-about-your-own-activity) so einrichten, dass sie nach Priorität sortiert werden. + +Wenn Sie etwas fortgeschrittener werden wollen, können Stilvorgaben und Linter die Projektbeiträge standardisieren, und so leichter überprüf- und akzeptierbar machen. + +Wenn Ihre Standards jedoch zu kompliziert sind, erhöht dies möglicherweise die Barriere für Mitwirkende. Stellen Sie sicher, dass Sie nur gerade genug Regeln einführen, um allen das Leben leichter zu machen. + +Wenn Sie sich nicht sicher sind, welche Tools Sie verwenden sollen, schauen Sie sich an, was andere beliebte Projekte tun, insbesondere die in Ihrem Ökosystem. Wie sieht beispielsweise der Beitragsprozess für andere Node-Module aus? Durch die Verwendung ähnlicher Tools und Ansätze wird Ihr Prozess auch für Ihre Zielgruppe vertrauter. + +## Es ist okay, Pause zu machen + +Open-Source-Arbeit hat Ihnen einmal Freude gemacht. Vielleicht bereitet sie Ihnen inzwischen Sorgen oder Schuldgefühle. + +Vielleicht fühlen Sie sich überfordert oder spüren eine wachsende Angst, wenn Sie an Ihre Projekte denken. Und in der Zwischenzeit häufen sich die Issues und Pull Requests. + +Burnout ist ein echtes und allgegenwärtiges Problem in der Open-Source-Arbeit, vor allem bei Maintainer\*innen. Dabei ist Ihr Wohlbefinden eine unabdingbare Voraussetzung für das Überleben eines jeden Open-Source-Projekts. + +Obwohl es gar nicht extra gesagt werden müsste: Machen Sie ruhig mal Urlaub! Sie sollten darauf nicht warten, bis Sie sich ausgebrannt fühlen. @brettcannon, ein Python Core Developer, entschied sich nach 14 Jahren freiwilliger OSS-Arbeit für einen [einmonatigen Urlaub](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/). + +Genau wie bei jeder anderen Art von Arbeit, werden Sie durch regelmäßige Pausen ausgeruht, glücklich und wieder gespannt auf Ihre Arbeit sein. + + + +Manchmal kann es schwierig sein, eine Pause von der Open-Source-Arbeit zu machen, wenn es sich so anfühlt, als ob alle Sie brauchen. Vielleicht versuchen die Leute Ihnen für Ihre Abwesenheit Schuldgefühle einzureden. + +Tun Sie Ihr Bestes, um Unterstützung für Ihre Benutzer\*innen und die Community zu finden, während Sie von einem Projekt weg sind. Wenn Sie nicht die Unterstützung finden, die Sie brauchen, machen Sie trotzdem eine Pause. Stellen Sie sicher, dass Sie kommunizieren, wann Sie nicht erreichbar sind, damit die Leute nicht durch Ihre mangelnde Reaktionsfähigkeit verwirrt werden. + +Pausen gelten nicht nur für den Urlaub. Wenn Sie keine Open-Source-Arbeit am Wochenende oder während der Arbeitszeit machen wollen, teilen Sie diese Erwartungen anderen mit, damit sie Sie nicht stören. + +## Achten Sie zuerst auf sich! + +Die Aufrechterhaltung eines beliebten Projekts erfordert andere Fähigkeiten als die früheren Phasen des Wachstums, aber es ist nicht weniger lohnend. Als Maintainer\*in üben Sie Führung und persönliche Fähigkeiten auf einem Niveau, das nur wenige Menschen erleben. Es ist zwar nicht immer einfach zu handhaben, aber klare Grenzen zu setzen und nur das zu übernehmen, womit Sie sich wohlfühlen, hilft Ihnen, glücklich, ausgeruht und produktiv zu bleiben. diff --git a/_articles/de/building-community.md b/_articles/de/building-community.md new file mode 100644 index 0000000000000000000000000000000000000000..40ae61a003275d2868d9523d6ca46fce365479d5 --- /dev/null +++ b/_articles/de/building-community.md @@ -0,0 +1,312 @@ +--- +lang: de +title: Offenherzige Gemeinschaften aufbauen +description: Bauen Sie eine Community auf, die Menschen ermutigt, Ihr Projekt zu nutzen, zu unterstützen und weiter zu verbreiten. +class: building +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +--- + +## Ihr Projekt zum Erfolg führen + +Ihr gerade gestartetes Projekt wird schon verbreitet und Leute schauen vorbei? Fantastisch! Wie überzeugen Sie sie, da zu bleiben? + +Eine einladende, offenherzige Gemeinschaft ist eine Investition in die Zukunft und in den Ruf Ihres Projekts. Wenn Ihr Projekt gerade erst die initialen Kontributionen erfährt, fangen Sie damit an, den frühen Kontributor\*innen eine positive Erfahrung zu bereiten, und machen Sie es ihnen leicht, wiederzukommen. + +### Geben Sie Leuten das Gefühl, willkommen zu sein + +Die Community Ihres Projekts kann nach @MikeMcQuaid als "Kontributorentrichter" ([contributor funnel](https://speakerdeck.com/mikemcquaid/the-open-source-contributor-funnel)) aufgefasst werden: + + + +Während Sie Ihre Community aufbauen, überlegen Sie sich, wie jemand am Eingang des Trichters (potenzielle\*r Benutzer\*in) theoretisch den Weg nach unten finden könnte (aktiver\* Mitstreiter\*in). Ihr Ziel ist es, jede Phase des Mithelfens möglichst reibungslos zu gestalten. Denn wenn die Leute "leichte Beute" machen können, ermutigt sie dies zu weiteren Beiträgen. + +Beginnen Sie mit der Dokumentation: + +* **Helfen Sie beim Einstieg in ihr Projekt.** [Eine freundliche README](../starting-a-project/#eine-readme-schreiben) und anschauliche Codebeispiele erleichtern Allen, die auf Ihr Projekt stoßen, den Einstieg. +* **Erklären Sie in klaren Worten, wie Leute beitragen sollen**, bspw. in [einer CONTRIBUTING-Datei](../starting-a-project/#ihre-beitragsrichtlinien-aufschreiben), und indem Sie die Issues stets aktuell halten. +* **Good first issues**: Um neuen Mitwirkenden den Einstieg zu erleichtern, sollten Sie [für Anfänger\*innen* geeignete Issues explizit kenntlich machen (Englisch)](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub weist auf solche Issues vermehrt hin, sodass beitragswillige Neulinge zu nützlicher Mitarbeit ermuntert werden, ohne sich erst durch vermutlich zu schwere Issues durchkämpfen zu müssen. + +[GitHubs 2017er Open-Source-Umfrage](http://opensourcesurvey.org/2017/) zeigte, dass unvollständige oder verwirrende Dokumentation das größte Problem für Open-Source-Anwender\*innen ist. Eine gute Dokumentation lädt zur Interaktion mit Ihrem Projekt ein. Wenn jemand ein Issue oder Pull Request erstellt, bietet sich für Sie die Möglichkeit, diese Person durch den Trichter zu bugsieren. + +* **Wenn Leute neu zu Ihrem Projekt hinzustoßen, danken Sie ihnen für ihr Interesse!** Ansonsten braucht es nur eine negative Erfahrung, um jemanden nachhaltig abzuschrecken. +* **Antworten Sie schnell.** Wenn Sie einen Monat lang nicht auf jemandes Issue reagieren, ist es wahrscheinlich, dass diese Person Ihr Projekt bereits vergessen hat. +* **Nehmen Sie verschiedener Beitragsarten an.** Viele Mitwirkende beginnen mit einem Fehlerbericht oder einer kleinen Korrektur: Es gibt [viele Möglichkeiten, einen Beitrag zu leisten](../how-to-contribute/#was-einen-beitrag-leisten-bedeutet) zu einem Projekt. Lassen Sie Leute so helfen, wie diese es möchten. +* **Wenn es einen Beitrag gibt, mit dem Sie nicht einverstanden sind,** bedanken Sie sich trotzdem, aber [erklären warum](../best-practices/#lernen-nein-zu-sagen) die Idee nicht in den Projektrahmen passt. Verlinken Sie auf relevante Dokumentation, wenn vorhanden. + + + +Die Mehrheit der Open-Source-Mitwirkenden sind "Gelegenheitsmitwirkende": Personen, die nur gelegentlich an einem Projekt mitarbeiten. Möglicherweise haben sie nicht die Zeit, sich mit Ihrem Projekt vertraut zu machen. Daher ist es Ihre Aufgabe, es Leuten leicht zu machen, einen Beitrag zu leisten. + +Andere zur Mitarbeit zu ermutigen, ist auch eine Investition in sich selbst: Wenn Sie Ihre größten Fans dazu befähigen, mit an etwas zu arbeiten, das sie begeistert, stehen Sie unter weniger Druck, alles selbst zu erledigen. + +### Dokumentieren Sie alles + + + +Wenn Sie ein neues Projekt starten, mag es sich normal anfühlen, Ihre Arbeit privat zu halten. Aber Open-Source-Projekte gedeihen, wenn Sie Ihren Prozess öffentlich dokumentieren. + +Wenn Sie Dinge aufschreiben, können mehr Leute an jedem Schritt des Weges teilnehmen. Vielleicht bekommen Sie Hilfe zu etwas, von dem Sie nicht einmal wussten, dass Sie es brauchen. + +Dinge aufzuschreiben, ist mehr als nur technische Dokumentation. Wenn Sie den Drang verspüren, etwas aufzuschreiben oder Ihr Projekt privat zu diskutieren, fragen Sie sich, ob Sie es nicht doch öffentlich machen können. + +Seien Sie transparent was die Roadmap Ihres Projekts angeht, die Arten von Beiträgen, nach denen Sie suchen, wie Beiträge überprüft werden, oder warum Sie bisherige Entscheidungen so getroffen haben. + +Wenn Sie feststellen, dass mehrere Benutzer\*innen auf das gleiche Problem stoßen, dokumentieren Sie die Antworten in der README. + +Ziehen Sie in Betracht, Besprechungsnotizen oder Schlussfolgerungen zu veröffentlichen. Die Rückmeldungen, die Sie aufgrund dieser Transparenz erhalten, könnten Sie überraschen. + +Alles zu dokumentieren, gilt auch für Ihre Arbeit. Wenn Sie an einem umfangreichen Update Ihres Projekts arbeiten, erstellen Sie früh einen Pull Request und kennzeichnen Sie ihn als "Work in Progress" (WIP). So fühlen sich andere Personen frühzeitig in den Prozess eingebunden. + +### Antworten Sie schnell + +Wenn Sie [für Ihr Projekt werben](../finding-users), werden Leute Ihnen Rückmeldungen geben. Vielleicht in Form von Fragen, wie etwas in Ihrem Projekt funktioniert, oder sie brauchen Starthilfe bei der Benutzung. + +Versuchen Sie, schnell zu reagieren, wenn jemand ein Issue oder Pull Request einreicht, oder eine Frage zu Ihrem Projekt stellt. Eine schnell Antwort gibt den Leuten das Gefühl, an einem Dialog teilzunehmen, und das kann ermutigend wirken, weiter mitzuhelfen. + +Auch wenn Sie die Anfrage nicht sofort inhaltlich prüfen können, hilft die frühzeitige Bestätigung, das Engagement zu erhöhen. Ein Beispiel: @tdreyno reagiert auf einen Pull Request an [Middleman](https://github.com/middleman/middleman/pull/1466): + + + +[Eine Mozilla-Studie fand heraus, dass](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) Kontributor\*innen, deren Codebeitrag innerhalb von 48 Stunden überprüft wurde, deutlich häufiger nochmal mithalfen. + +Ihr Projekt kann an allen möglichen Stellen des Internets besprochen werden, wie z.B. auf Stack Overflow, Twitter oder Reddit. Dort können Sie Benachrichtigungen einrichten, um über Erwähnungen Ihres Projektes informiert zu werden. + +### Geben Sie Ihrer Gemeinschaft einen Ort, an dem sie sich versammeln kann. + +Es gibt zwei Gründe, Ihrer Gemeinschaft einen Ort der Begegnung zu geben. + +Der erste Grund ist, Menschen mit gemeinsamen Interessen zu helfen, sich kennenzulernen. Menschen mit gemeinsamen Interessen wollen sich zwangsläufig treffen können, um über diese zu reden. Wenn die Kommunikation öffentlich und zugänglich ist, kann jede\*r die Archive lesen, um sich auf den neuesten Stand zu bringen und sich daran zu beteiligen. + +Der zweite Grund nützt Ihnen selbst: Wenn Sie den Leuten _keinen_ öffentlichen Ort geben, um über Ihr Projekt zu sprechen, werden sie wahrscheinlich direkt mit Ihnen in Verbindung treten. Am Anfang mag es einfach erscheinen, hin und wieder mal auf private Nachrichten zu antworten, aber mit der Zeit, besonders wenn Ihr Projekt populär wird, werden Sie sich erschöpft fühlen und der Versuchung widerstehen, mit Leuten über Ihr Projekt privat zu kommunizieren, anstatt sie an einen bestimmten öffentlichen Kanal zu verweisen. + +Öffentliche Kommunikation kann ganz einfach sein: Bitten Sie Leute, ein Issue zu öffnen, anstatt Ihnen direkt eine E-Mail zu schreiben oder in Ihr Blog zu kommentieren. Sie können für Leute, die über Ihr Projekt sprechen möchten, auch eine Mailingliste einrichten oder einen Twitter-Account, einen Slack- oder IRC-Kanal. Oder all dies gleichzeitig ausprobieren! + +[Kubernetes' Kops](https://github.com/kubernetes/kops#getting-involved) legt alle zwei Wochen Bürozeiten fest, um den Mitgliedern der Gemeinschaft zu helfen: + +> Die Kops-Betreuer\*innen haben sich bereit erklärt, Zeit einzuplanen für die Arbeit mit Neuankömmlingen, die Unterstützung von Pull Requests, sowie für die Diskussion über neue Funktionen. +> +> Kops also has time set aside every other week to offer help and guidance to the community. Kops maintainers have agreed to set aside time specifically dedicated to working with newcomers, helping with PRs, and discussing new features. + +Wichtige Ausnahmen von öffentlicher Kommunikation sind: 1) Sicherheitsprobleme und 2) Verstöße gegen den Verhaltenskodex; Sie sollten immer eine Möglichkeit anbieten, solche Probleme privat zu melden. Wenn Sie Ihre persönliche E-Mail-Adresse dafür nicht verwenden möchten, richten Sie eine dedizierte Adresse ein. + +## Ihre Nutzergemeinschaft vergrößern + +Eine Gemeinschaft kann sehr kraftvoll sein. Dies kann zu Segen und Fluch werden, je nach Art der Nutzung. Wenn die Projektgemeinschaft wächst, gibt es Möglichkeiten, ihr zu einer konstruktiven Kraft zu verhelfen, anstatt zu einer destruktiven. + +### Dulden Sie keine destruktiven Akteure + +Jedes populäre Projekt wird unweigerlich Menschen anziehen, die Ihrer Gemeinschaft mehr schaden als helfen. Beispielsweise indem Sie können unnötige Debatten starten, über triviale Dinge streiten oder andere schikanieren. + +Tun Sie Ihr Bestes, um eine Null-Toleranz-Politik gegenüber solchen Leuten zu verfolgen. Denn wenn obiges Verhalten unsanktioniert bleibt, werden andere Kontributor\*innen sich genervt fühlen und evtl. sogar Ihr Projekt verlassen. + + + +Regelmäßige Debatten über triviale Aspekte Ihres Projekts lenken alle davon ab, sich auf wichtige Aufgaben zu konzentrieren. Neue Leute, die zu Ihrem Projekt kommen, können diese Gespräche sehen und wollen nicht teilnehmen. + +Wenn Sie ein destruktives Verhalten in Ihrem Projekt beobachten, sprechen Sie es öffentlich an. Erklären Sie freundlich aber bestimmt, warum so etwas nicht akzeptabel ist. Wenn das Problem weiterbesteht, müssen Sie die [Verursacher\*innen bitten, das Projekt zu verlassen](../code-of-conduct/#ihre-verantwortung-als-maintainerin), Ihr [Verhaltenskodex](../code-of-conduct/) kann eine konstruktive Anleitung für solche Gespräche sein. + +### Holen Sie Mitwirkende dort ab, wo sie sich stehen + +Eine gute Dokumentation wird nur immer wichtiger, je mehr Ihre Community wächst. Gelegenheitskontributor\*innen, die mit Ihrem Projekt nicht vertraut sind, lesen Ihre Dokumentation, um schnell den nötigen Überblick zu bekommen. + +Geben Sie in Ihrer CONTRIBUTING-Datei explizit an, wie sie anfangen sollen. Vielleicht möchten Sie sogar eine eigene Sektion für diesen Zweck einrichten: [Django](https://github.com/django/django) zum Beispiel, hat eine spezielle Startseite, die neue Mitwirkende willkommen heißt. + + + +Die Liste der Issues sollte durchsortiert sein, Bugs z.B. als solche markiert, sowie Issues auch für unterschiedliche potentielle Kontributor\*innen: z.B. [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, oder _"documentation"_. [Solche "Labels"](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) vereinfachen es Neuankömmlingen, sich in Ihrem Projekt zurechtzufinden und mit der Lösung eines Problems zu beginnen. + +Nicht zuletzt sollten Sie die Dokumentation nutzen, um Leute mit offenen Armen zu empfangen und ihnen Schritt-für-Schritt zu helfen. + +Sie werden mit den meisten Leuten, die auf Ihr Projekt stoßen nie interagieren. Ihnen könnten Beiträge entgehen, weil jemand sich eingeschüchtert fühlte, oder nicht herausfand, was es denn zu tun gab. Schon ein paar freundliche Worte können verhindern, dass jemand einfach weiter zieht. + +Zum Beispiel: [Rubinius](https://github.com/rubinius/rubinius/) beginnt [den Kontributionsratgeber](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md) mit: + +> Zum Einstieg möchten wir Dir erstmal unseren Dank aussprechen, dass Du Rubinius nutzt. Dieses Projekt wurde mit viel Liebe aufgebaut und wir schätzen alle Benutzer\*innen, die Fehler aufspüren, Geschwindigkeitsverbesserungen vornehmen und bei der Dokumentation helfen. Jeder Beitrag bedeutet uns etwas, also vielen Dank für Ihre Teilnahme! Wir bitten Sie jedoch, einige Richtlinien zu befolgen, damit wir Ihr Issue erfolgreich bearbeiten können. +> +> We want to start off by saying thank you for using Rubinius. This project is a labor of love, and we appreciate all of the users that catch bugs, make performance improvements, and help with documentation. Every contribution is meaningful, so thank you for participating. That being said, here are a few guidelines that we ask you to follow so we can successfully address your issue. + +### Teilen Sie die Eigentümerschaft an Ihrem Projekt + + + +Leute sind begeistert davon, an Projekten mitzuwirken, wenn sie ein Gefühl für Verantwortung bekommen. Das bedeutet nicht, dass Sie Ihre Projektvision umdrehen müssen, oder Beiträge annehmen, die Sie nicht wollen. Je mehr Anerkennung Sie anderen Menschen jedoch zollen, desto eher werden diese bei Ihrem Projekt bleiben. + +Schauen Sie, ob Sie Wege finden können, Verantwortlichkeiten so weit wie möglich mit Ihren Projektteilnehmer\*innen zu teilen: + +* **Lassen Sie einfache (unkritische) Bugs unangetastet.** Nutzen Sie diese stattdessen als Gelegenheit, neue Mitwirkende zu rekrutieren, oder helfen Sie einem hilfsbereiten Neuling, den Prozess eines Bug-Fixes zu durchlaufen. Es mag zunächst unnatürlich erscheinen, aber Ihre Investition wird sich im Laufe der Zeit auszahlen. @michaeljoseph hat zum Beispiel einen Mitwirkenden gebeten, einen Pull Request zu einem der folgenden Probleme in [Cookiecutter](https://github.com/audreyr/cookiecutter) zu stellen, anstatt es selbst zu beheben. + + + +* **Führen Sie eine CONTRIBUTORS- oder AUTHORS-Datei in Ihrem Projekt**, die alle Leute aufzählt, die einen Beitrag geleistet haben, wie z.B. bei [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md). + +* Wenn Sie schon eine etwas größere Gemeinschaft versammelt haben, **senden Sie eine Rundmail oder schreiben ins Blog**, dass Sie Kontributor\*innen danken. Rusts [This Week in Rust](https://this-week-in-rust.org/) und Hoodies [Shoutout-Grüße](http://hood.ie/blog/shoutouts-week-24.html) sind zwei gute Beispiele dafür. + +* **Geben Sie allen Kontributor\*innen Schreibzugriff.** @felixge fand heraus, dass dies Leute [zu mehr Feinschliff ihrer Beiträge anspornt](https://felixge.de/2013/03/11/the-pull-request-hack.html), und gewann sogar neue Maintainer\*innen für Projekte, an denen er selbst schon eine Weile nicht mehr arbeitete. + +* Wenn Ihr Projekt auf GitHub liegt, **verschieben Sie es von Ihrem Privat-Konto in das einer [Organisation](https://help.github.com/articles/creating-a-new-organization-account/)** und fügen Sie zur Sicherheit mindestens eine\*n weitere\*n Administrator\*in hinzu. Organisationen machen die Zusammenarbeit mit externen Mithelfenden einfacher. + +Realistischerweise haben [die meisten Projekte](https://peerj.com/preprints/1233.pdf) nur einen oder zwei Verantwortliche, welche die meiste Arbeit erledigen. Ja größer Ihr Projekt, und je größer seine Nutzer\*innengemeinschaft, desteo einfacher wird es sein, Hilfe zu finden. + +Während Sie vielleicht nicht immer Leute finden, die einem Aufruf folgen, erhöht so ein Signals doch die Wahrscheinlichkeit, dass Andere mitmachen. Je früher Sie damit anfangen, desto eher können die Leute helfen. + + + +## Konflikte beilegen + +In der Anfangsphase Ihres Projekts ist es einfach, wichtige Entscheidungen zu treffen: Wenn Sie etwas tun wollen, dann tun Sie es einfach. + +Je beliebter Ihr Projekt wird, desto mehr Menschen werden sich für von Ihnen getroffene Entscheidungen interessieren. Selbst wenn Sie keine große Gemeinschaft von Mitwirkenden haben: Wenn Ihr Projekt viele Benutzer\*innen hat, werden darunter Leute sein, die sich über Entscheidungen auslassen oder ihre eigenen Themen ansprechen. + +Wenn Sie eine freundliche, respektvolle Gemeinschaft gepflegt und Ihre Prozesse offen dokumentiert haben, sollten Alle zur Lösungsfindung in der Lage sein. Aber manchmal stoßen Sie auf ein Problem, das etwas schwieriger zu lösen ist. + +### Setzen Sie die Messlatte für Freundlichkeit + +Wenn sich Ihre Gemeinschaft mit einem schwierigen Thema auseinandersetzt, können sich Gemüter schnell mal erhitzen. Menschen können wütend oder frustriert werden und es an Anderen oder an Ihnen auslassen. + +Ihre Aufgabe als Maintainer\*in ist es, solche Situationen vor einer Eskalation zu bewahren. Selbst wenn Sie eine klare eigene Meinung zu diesem Thema haben, versuchen Sie, die moderierende Position einzunehmen, anstatt sich in den Kampf zu stürzen und Ihre Ansichten durchzusetzen. Wenn jemand unfreundlich wird oder das Gespräch an sich reißt, [handeln Sie sofort](../building-community/#dulden-sie-keine-destruktiven-akteure), um die Diskussionen zivil und produktiv zu halten. + + + +Andere Leute erwarten von Ihnen, ein gutes Beispiel abzugeben. Sie können immer noch Enttäuschung, Unzufriedenheit oder Besorgnis ausdrücken, aber tun Sie dies auf eine ruhige Art und Weise. + +Es ist nicht einfach, einen kühlen Kopf zu bewahren, aber Führung zu zeigen, verbessert die Gesundheit der Gemeinschaft. Das Internet wird es Ihnen danken! + +### Nutzen Sie die README als Verfassung + +Ihre README-Datei ist [mehr als nur eine Anleitung](../starting-a-project/#eine-readme-schreiben). Sie ist auch das Dokument, das Ihre Ziele, Ihre Produktvision und Ihre Roadmap aufzeigt. Wenn die Leute sich zu sehr darauf konzentrieren, über die Vorzüge einer bestimmten Funktion zu diskutieren, kann es helfen, Ihre README zu überprüfen und das überragende Ziel Ihres Projekts anzusprechen. Der Verweis auf Ihre README entpersönlicht eine Diskussion auch, sodass Sie wieder konstruktiver geführt werden kann. + +### Der Weg ist das Ziel + +Einige Projekte nutzen einen Abstimmungsprozess, um wichtige Entscheidungen zu treffen. Auf den ersten Blick ist es sinnvoll, so eine Antwort zu finden, anstatt sich gegenseitig zuzuhören und auf die Sichtweisen Anderer einzugehen. + +Abstimmungen können aber politisch werden, wenn sich die Community-Mitglieder unter Druck gesetzt fühlen, sich gegenseitig einen Gefallen zu tun oder auf eine bestimmte Wahl zu treffen. Außerdem stimmt nicht jede\*r mit ab, z.B. weil es ein [stille Mehrheit](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) in Ihrer Gemeinschaft geben könnte, oder neue Benutzer\*innen einfach nicht wussten, dass eine Abstimmung stattfindet. + +Manchmal ist eine Abstimmung notwendig, um ein Patt aufzulösen. Aber soviel Sie können, betonen Sie die [Konsensfindung](https://de.wikipedia.org/wiki/Konsensprinzip) statt des Konsenses an sich. + +Im Rahmen der Konsensfindungsprozesses diskutieren die Mitglieder der Gemeinschaft wichtige Anliegen, bis sie das Gefühl haben, angemessen gehört worden zu sein, und wenn nur noch geringe Bedenken bestehen, kommt die Gemeinschaft voran. Die Konsensfindung erkennt an, dass eine Gemeinschaft möglicherweise keine perfekte Antwort finden kann. Stattdessen priorisiert sie das Zuhören und die Diskussion. + + + +Auch wenn Sie als Projektbetreuer\*in keine Konsensfindung betreiben möchten, ist es wichtig, dass die Leute ein offenes Ohr bei Ihnen finden. Anderen zuzuhören, und sich für die Lösung ihrer Probleme einzusetzen, hilft beim Entschärfen sensibler Situationen sehr. Lassen Sie Ihren Worten aber auch Taten folgen. + +Überstürzen Sie Entscheidungen nicht, nur um eine Lösung herbeizuführen. Stellen Sie sicher, dass jede\*r sich gehört fühlt und dass alle Informationen öffentlich gemacht wurden, bevor Sie sich auf eine Entscheidung zubewegen. + +### Halten Sie Diskussionen fokussiert auf Aktionen + +Diskussionen sind wichtig, aber es gibt einen Unterschied zwischen produktiven und unproduktiven Gesprächen. + +Fördern Sie Diskussionen, die sich aktiv auf eine Lösung zubewegen: Wenn klar ist, dass Dinge zerredet werden, oder die Konversation vom Thema abweicht, persönliche Anfeindungen passieren, oder die Leute sich über kleine Details streiten, ist es Zeit für eine Beendigung der Diskussion. + +Die Fortsetzung solcher Diskussionen ist nicht nur schlecht für das jeweilige Thema, sondern auch für die Gesundheit Ihrer Gemeinschaft. Die Botschaft zu vermitteln, dass unproduktive Diskussionen erlaubt oder sogar gefördert werden, könnte Leute zukünftig davon abgehalten werden, Probleme anzusprechen oder zu lösen. + +Bei jedem Diskussionsbeitrag ihrerseits, oder von Anderen, sollten Sie sich fragen _"Wie bringt uns dies einer Lösung näher?"_ + +Falls die Diskussion abdriftet, fragen Sie die Teilnehmer\*innen: _"Welche Schritte sollten wir als nächstes gehen?"_ um sie wieder zu fokussieren. + +Wenn eine Diskussion offensichtlich nirgendwo hinführt, es keine klaren Maßnahmen zu ergreifen gibt, oder schon welche ergriffen wurden, schließen Sie das Issue und erklären Sie, warum Sie es geschlossen haben. + + + +### Wählen Sie Auseinandersetzungen mit Bedacht + +Der Kontext ist wichtig: Überlegen Sie, wer an der Diskussion beteiligt ist und wie die Diskutanten den Rest der Gemeinschaft repräsentieren. + +Ist jeder in der Community verärgert oder gar mit diesem Thema beschäftigt? Oder ist er ein\*e einzelner Unruhestifter\*in? Berücksichtigen Sie nicht nur die Aktiven, sondern vergessen Sie Ihre stillen Community-Mitglieder nicht. + +Wenn das Thema nicht die breiteren Bedürfnisse Ihrer Gemeinschaft widerspiegelt, müssen Sie vielleicht nur die Sorgen einiger Weniger anerkennen. Wenn es sich um ein wiederkehrendes Problem ohne klare Lösung handelt, weisen Sie sie auf frühere Diskussionen hin und schließen Sie das Issue. + +### Identifizieren Sie einen Community-Tiebreaker + +Mit einer positiven Herangehensweise und klarer Kommunikation sind die schwierigsten Situationen lösbar. Aber auch in einem produktiven Gespräch kann es einfach zu Meinungsverschiedenheiten kommen. Identifizieren Sie dann eine Person oder Gruppe, die quasi als Schiedsrichter\*in fungieren kann. + +Ein\*e solche\*r Schiedsrichter\*in kann die oder der Hauptverantwortliche für das Projekt sein, oder eine kleine Gruppe von Leuten, die über eine Entscheidung abstimmen. Idealerweise haben Sie einen Tiebreaker und den damit verbundenen Prozess in einer GOVERNANCE-Datei identifiziert, bevor Sie diese verwenden müssen. + +Ihr\*e Schiedsrichter\*in sollte der letzte Ausweg sein, denn zunächst entzweiend wirkende Probleme sind eine Chance für Ihre Gemeinschaft, zu wachsen und zu lernen. Nutzen Sie diese Möglichkeiten, um in einem gemeinsamen Prozess zu einer Lösung zu kommen, wo immer dies möglich ist. + +## Das ❤️ von Open-Source sind Gemeinschaften + +Gesunde, blühende Gemeinschaften sorgen für den Antrieb für Tausende von Stunden, die jede Woche in Open-Source gesteckt werden. Viele Mitwirkende verweisen auf andere Menschen als Grund dafür, an Open-Source zu arbeiten (oder eben nicht). Indem Sie lernen, diese Kraft konstruktiv zu nutzen, werden Sie jemandem da draußen helfen, ein unvergessliches Open-Source-Erlebnis zu haben. diff --git a/_articles/de/code-of-conduct.md b/_articles/de/code-of-conduct.md new file mode 100644 index 0000000000000000000000000000000000000000..7a2c427c733d9907b4f0ac415ef810527eb789d1 --- /dev/null +++ b/_articles/de/code-of-conduct.md @@ -0,0 +1,124 @@ +--- +lang: de +title: Ihr Verhaltenskodex +description: Fördern Sie ein gesundes und konstruktives Miteinander durch die Festlegung und Durchsetzung eines Verhaltenskodex. +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## Warum brauche ich einen Verhaltenskodex? + +Ein Verhaltenskodex ist ein Dokument, das die Erwartungen an das Verhalten der Projektteilnehmer\*innen festlegt. Einen Verhaltenskodex festzulegen und durchzusetzen, kann dazu beitragen, eine positive soziale Atmosphäre für Ihre Community zu schaffen. + +Verhaltenskodizes schützen nicht nur Ihre Teilnehmer\*innen, sondern auch Sie selbst. Wenn Sie ein Projekt pflegen, werden Sie vielleicht feststellen, dass unproduktive Einstellungen von anderen dazu führen können, dass Sie sich im Laufe der Zeit ausgelaugt oder unglücklich über Ihre Arbeit fühlen. + +Ein Verhaltenskodex bevollmächtigt Sie, ein gesundes, konstruktives Miteinander zu fördern. Proaktiv zu sein, verringert die Wahrscheinlichkeit, dass Sie oder andere projektmüde werden, und hilft Ihnen, Maßnahmen gegen unerwünschtes Verhalten zu ergreifen. + +## Einen Verhaltenskodex festlegen + +Versuchen Sie, so früh wie möglich einen Verhaltenskodex festzulegen: idealerweise, sobald Sie Ihr Projekt starten. + +Neben der Klarstellung Ihrer Erwartungen beschreibt ein Verhaltenskodex Folgendes: + +* Wo er gilt _(nur für Issue und Pull Requests oder auch bei Community-Veranstaltungen?)_ +* Für wen er gilt _(Community-Mitglieder und Maintainer\*innen; Aber was ist mit den Sponsor\*innen?)_ +* Was passiert, wenn jemand gegen ihn verstößt +* Wie jemand Verstöße melden kann + +Wo immer Sie können, nutzen Sie Vorhandenes. Der [Contributor Covenant](https://contributor-covenant.org/) ist ein Verhaltenskodex, der von über 40.000 Open-Source-Projekten wie Kubernetes, Rails und Swift verwendet wird. + +Der [Django-Verhaltenskodex](https://www.djangoproject.com/conduct/) und der [Citizen Code of Conduct](http://citizencodeofconduct.org/) sind ebenfalls zwei gute Beispiele. + +Legen Sie eine CODE_OF_CONDUCT-Datei in das Stammverzeichnis Ihres Projekts und machen Sie sie für Ihre Community sichtbar, indem Sie sie von Ihrer CONTRIBUTING- oder README-Datei verlinken. + +## Entscheiden, wie Sie Ihren Verhaltenskodex durchsetzen. + + + +Sie sollten erklären, wie Ihr Verhaltenskodex durchgesetzt wird, **_bevor_** es zu einem Verstoß kommt. Dafür gibt es mehrere Gründe: + +* Es zeigt, dass Sie es mit Maßnahmen ernst meinen, wenn sie gebraucht werden. + +* Ihre Community wird sich sicherer fühlen, dass Beschwerden tatsächlich geprüft werden. + +* Sie vergewissern Ihre Community, dass der Überprüfungsprozess fair und transparent ist, sollte es jemals zu einem Verstoß kommen. + +Sie sollten Leuten einen privaten Weg (z.B. eine E-Mail-Adresse) geben, um einen Verstoß gegen den Verhaltenskodex zu melden und erklären, wer diesen Bericht erhält. Es kann ein\*e Maintainer\*in, eine Gruppe von Maintainer\*innen oder eine Verhaltenskodex-Arbeitsgruppe sein. + +Vergessen Sie nicht, dass jemand einen Verstoß über eine Person melden können möchte, die diese Berichte erhält. Bieten Sie in diesem Fall die Möglichkeit, Verstöße an eine andere Person zu melden. @ctb und @mr-c zum Beispiel [erklären zu ihrem Projekt](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): + +> Fälle von missbräuchlichem, belästigendem oder anderweitig inakzeptablem Verhalten können per E-Mail an **khmer-project@idyll.org** gemeldet werden, die nur an C. Titus Brown und Michael R. Crusoe geht. Um ein Problem zu melden, das einen von ihnen betrifft, senden Sie bitte eine E-Mail an **Judi Brown Clarke, Ph.D.** den Diversity Director am BEACON Center for the Study of Evolution in Action, einem NSF Center for Science and Technology.* +> +> Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.* + +Django's [Enforcement Manual](https://www.djangoproject.com/conduct/enforcement-manual/) dürfte für Sie eine gute Vorlage liefern, auch wenn Sie für ein kleineres Projekt vielleicht weniger umfassende Regeln benötigen. + +## Durchsetzung Ihres Verhaltenskodexes + +Manchmal wird jemand trotz Ihrer Bemühungen etwas tun, das gegen diesen Kodex verstößt. Es gibt mehrere Möglichkeiten, negatives oder schädliches Verhalten zu bekämpfen, wenn es auftritt. + +### Sammeln Sie Informationen über die Situation. + +Nehmen Sie jede Stimme aus der Community so wichtig wie Ihre eigene. Wenn Sie einen Bericht erhalten, dass jemand gegen den Verhaltenskodex verstoßen hat, nehmen Sie ihn oder sie ernst und untersuchen Sie die Angelegenheit, auch wenn sie nicht Ihren eigenen Erfahrungen mit dieser Person entspricht. Damit signalisieren Sie Ihrer Gemeinschaft, dass Sie ihre Perspektive schätzen und ihrem Urteilsvermögen vertrauen. + +Das betroffene Community-Mitglied kann ein\*e Wiederholungstäter\*in sein, der oder die anderen immer wieder Ärger bereitet, oder es hat nur einmal etwas gesagt oder getan. Beides kann je nach Kontext Anlass zum Handeln sein. + +Bevor Sie antworten, geben Sie sich Zeit, um zu verstehen, was passiert ist. Lesen Sie die bisherigen Kommentare und Gespräche der Person durch, um besser zu verstehen, wer es ist und warum sie oder er so gehandelt haben könnten. Versuchen Sie, andere Perspektiven als Ihre eigenen über diese Person und ihr Verhalten zu sammeln. + + + +### Ergreifen Sie geeignete Maßnahmen + +Nachdem Sie genügend Informationen gesammelt und verstanden haben, müssen Sie entscheiden, was zu tun ist. Denken Sie bei Ihren nächsten Schritten daran, dass es Ihr Ziel als Moderator\*in ist, eine sichere, respektvolle und kollaborative Umgebung zu fördern. Überlegen Sie nicht nur, wie Sie mit dieser Situation umgehen, sondern auch, wie sich Ihre Reaktion auf das Verhalten und die Erwartungen Ihrer Community auswirken könnte. + +Wenn jemand einen Verstoß gegen einen Verhaltenskodex meldet, sind Sie gefragt, nicht die Community. Manchmal enthüllt die oder der Meldende Informationen, die eine große Gefahr für Karriere, Ruf oder körperliche Unversehrtheit darstellen. Sie oder ihn zu zwingen, den Gemeldeten zu konfrontieren, könnte eine kompromittierende Situation erzeugen. Sie sollten die direkte Kommunikation mit der gemeldeten Person übernehmen, es sei denn, die oder der Meldende verlangt ausdrücklich etwas anderes. + +Es gibt einige Möglichkeiten, wie Sie auf einen Verstoß gegen den Verhaltenskodex reagieren können: + +* **Geben Sie der betreffenden Person eine öffentliche Warnung** und erklären Sie, wie sich sein oder ihr Verhalten negativ auf andere ausgewirkt hat. Nutzen Sie dafür vorzugsweise den Kommunikationskanal, auf dem das schädliche Verhalten aufgetreten ist. Öffentliche Kommunikation zeigt dem Rest der Gemeinschaft, dass Sie den Verhaltenskodex ernst nehmen. Seien Sie freundlich, aber bestimmt. + +* **Privat auf die betreffende Person zugehen**, um zu erklären, wie sich ihr oder sein Verhalten negativ auf andere ausgewirkt hat. Sie können einen privaten Kommunikationskanal verwenden, wenn es sich um sensible persönliche Daten handelt. Wenn Sie mit jemandem privat kommunizieren, setzen Sie die meldende Person darüber in Kenntnis. Aber setzen Sie sie bei E-Mails nicht ohne Erlaubnis in CC. + +Manchmal kann keine Lösung erreicht werden. Die gemeldete Person kann aggressiv oder feindselig werden, wenn er oder sie damit konfrontiert wird oder das Verhalten nicht ändert. In dieser Situation sollten Sie vielleicht stärkere Maßnahmen in Betracht ziehen. Zum Beispiel: + +* **zeitweise Suspendierung** in Form eines vorübergehenden Verbots, sich an den Aspekten des Projekts zu beteiligen. + +* Die Person **dauerhaft aus dem Projekt verbannen**. + +Projektteilnehmer\*innen auszuschließen, sollte nicht auf die leichte Schulter genommen werden, da es eine permanente und unvereinbare Meinungsverschiedenheit darstellt. Sie sollten diese Maßnahmen nur ergreifen, wenn klar ist, dass eine Lösung nicht möglich ist. + +## Ihre Verantwortung als Maintainerin + +Ein Verhaltenskodex sollte nicht willkürlich durchgesetzt werden. Sie sind der oder die Vollstrecker\*in des Verhaltenskodexes und es ist Ihre Verantwortung, diese Regeln auch zu befolgen. + +Als Maintainer\*in legen Sie die Richtlinien für Ihre Community fest und setzen diese durch. Dies bedeutet, dass jeder Bericht über einen Verstoß gegen den Verhaltenskodex ernst genommen wird. Dem oder der Beschwerdeführer\*in ist eine gründliche und faire Prüfung geschuldet. Wenn Sie feststellen, dass das gemeldete Verhalten kein Verstoß ist, stellen Sie dies klar und erklären Sie, warum Sie nichts dagegen unternehmen werden. Die Reaktion der meldenden Person ist eine andere Sache: das nur persönlich als problematisch empfundene Verhalten zu tolerieren oder die Projekt-Community zu verlassen. + +Ein gemeldetes Verhalten, das _genau genommen nicht_ gegen den Verhaltenskodex verstößt, kann dennoch auf ein Problem in Ihrer Gemeinschaft hinweisen. Sie sollten dieses potenzielle Problem untersuchen und entsprechend handeln. Dies kann die Überarbeitung Ihres Verhaltenskodex umfassen, um akzeptables Verhalten zu klären und/oder mit der Person zu sprechen, deren Verhalten gemeldet wurde. In diesem Falle stellen Sie klar, dass sie oder er vielleicht nicht konkret gegen den Verhaltenskodex verstoßen hat, aber den Rand des Akzeptablen erreicht haben, und andere Teilnehmer\*innen sich unwohl fühlen. + +Letztendlich setzen Sie als Maintainer\*in die Standards für akzeptables Verhalten (durch). Sie haben die Fähigkeit, die Gemeinschaftswerte des Projekts zu gestalten. Die Teilnehmer\*innen erwarten, dass Sie diese Werte auf faire und ausgewogene Weise durchsetzen. + +## Fördern Sie das Verhalten, das Sie in der Welt sehen wollen 🌎 + +Wenn ein Projekt feindselig oder unwillkommen erscheint, und wenn auch nur durch das von Anderen tolerierte Verhalten einer einzelnen Person, riskieren Sie den Verlust vieler weiterer Mitwirkender. Es ist nicht immer einfach, einen Verhaltenskodex anzunehmen oder durchzusetzen, aber die Förderung einer einladenden Umgebung wird Ihrer Gemeinschaft helfen, zu wachsen. diff --git a/_articles/de/finding-users.md b/_articles/de/finding-users.md new file mode 100644 index 0000000000000000000000000000000000000000..f0279bdc3801ddf1eadebb2953e6a13f5260d204 --- /dev/null +++ b/_articles/de/finding-users.md @@ -0,0 +1,188 @@ +--- +lang: de +title: Finden Sie Nutzer*innen für Ihr Projekt +description: Ziehen Sie Ihr Open-Source-Projekt groß, indem Sie es in die Hände zufriedener Anwender*innen legen. +class: finding +order: 3 +image: /assets/images/cards/finding.png +related: + - beginners + - building +--- + +## Tue Gutes und rede darüber! + +Es gibt keine Regel, die besagt, dass man den Start eines Open-Source-Projektes verkünden _muss_. Viele erfüllende Beweggründe für Open-Source-Arbeit haben nichts mit Popularität zu tun. Aber anstatt _zu hoffen_, dass Ihr Open-Source-Projekt gefunden und genutzt wird, sollten Sie über Ihre harte Arbeit reden. + +## Klären Sie Ihre Botschaft + +Bevor Sie mit der eigentlichen Arbeit an einem Projekt beginnen, sollten Sie (er)klären, was es tut und warum es wichtig ist. + +Was macht Ihr Projekt anders oder interessant und warum haben Sie es begonnen? Die Beantwortung dieser Fragen hilft Ihnen dabei, die Bedeutung Ihres Projekts zu kommunizieren. + +Denken Sie daran, dass Menschen sich als Nutzer\*innen engagieren und letztendlich zu Mitwirkenden werden, weil Ihr Projekt ein Problem für sie löst. Wenn Sie über die Botschaft und den Wert Ihres Projekts nachdenken, versuchen Sie durch die Brille der _Benutzer\*innen und Mitwirkenden_ zu blicken. Was könnten jene sich wünschen? + +Code-Beispiele wie @robb sie verwendet, können klar kommunizieren, warum sein Projekt "[Cartography](https://github.com/robb/Cartography)" nützlich ist: + + + +Tiefere Einblicke in das Thema "Botschaften", finden Sie in Mozillas ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/)-Übung zur Entwicklung von Personas. + +## Helfen Sie Menschen dabei, Ihr Projekt zu finden und zu beobachten + + + +Helfen Sie Leuten dabei, Ihr Projekt zu finden und es sich zu merken, indem Sie sie auf einen einzigen Namensraum verweisen. + +**Preisen Sie Ihre Arbeit an unter _einem_ Nutzernamen an.** Twitter-Name, GitHub-URL oder IRC-Kanal sind einfache Möglichkeiten, Leute auf Ihr Projekt aufmerksam zu machen. Diese "Marktstände" bieten auch der wachsenden Gemeinschaft Ihres Projekts einen Ort, an dem sie sich treffen können. + +Wenn Sie noch keine "Marktstände" für Ihr Projekt einrichten möchten, bewerben Sie immer Ihren eigenen Twitter- oder GitHub-Namen. Werben Sie für Ihren Twitter- oder GitHub-Namen, damit die Leute wissen, wie Sie zu erreichen sind oder wo Ihre Arbeit beobachtet werden kann. Wenn Sie bei einem Meeting oder einer Veranstaltung sprechen, stellen Sie sicher, dass Sie Ihre Kontaktinformationen erwähnen oder in Ihren Folien nennen. + + + +**Ziehen Sie eine Website für Ihr Projekt in Betracht.** Eine Website macht Ihr Projekt freundlicher und einfacher zu navigieren. Vor allem, wenn die Seite klare Dokumentation und Tutorials enthält. Außerdem zeigt eine Website auch, dass Ihr Projekt aktiv ist, was wiederum Ihrem Publikum Vertrauen in den Nutzen Ihres Projektes gibt. + +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689) (Mitbegründer von Django) sagte, dass eine Website _"mit Abstand das Beste, das wir in der Frühphase von Django gemacht haben"_. + +Wenn Ihr Projekt auf GitHub gehostet ist, können Sie mithilfe der [Pages-Funktion](https://pages.github.com/) einfach eine Webseite erstellen. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), und [Middleman](https://middlemanapp.com/) sind [einige Beispiele](https://github.com/showcases/github-pages-examples) für exzellente, reichhaltige Seiten. + + + +Nun, da Sie die Botschaft Ihres Projekt klargestellt haben, und seine einfache Auffindbarkeit gewährleistet haben, lassen Sie uns rausgehen und mit Ihrem Publikum sprechen! + +## Gehen Sie auf die Zielgruppe Ihres Projekts zu (online) + +Internetkommunikation ist ein großartiger Weg, um die Botschaft Ihres Projektes schnell zu verbreiten und verteilen zu lassen: Online-Kanälen bieten das Potenzial, ein sehr breites Publikum zu erreichen. + +Nutzen Sie die Vorteile bestehender Online-Communities und -Plattformen, um Ihr Publikum zu erreichen. Wenn es sich bei Ihrem Open Source Projekt um ein Softwareprojekt handelt, erreichen Sie Ihr Publikum wahrscheinlich auf [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), oder [Quora](https://www.quora.com/). Finden Sie die Kanäle, von denen Sie denken, dass die Menschen am meisten von Ihrer Arbeit profitieren werden, oder sich begeistern lassen. + + + +Finden Sie Wege, um Ihr Projekt auf relevante Art und Weise mit anderen zu teilen: + +* **Lernen Sie relevante Open Source Projekte und Communities kennen.** Manchmal müssen Sie nicht direkt für Ihr Projekt werben. Wenn Ihr Projekt perfekt für Datenwissenschaftler geeignet ist, die Python nutzen, lernen Sie die Python Data Science Community kennen. Wenn die Leute Sie kennenlernen, ergeben sich natürliche Gelegenheiten, über Ihre Arbeit zu sprechen und sie mit anderen zu teilen. +* **Finden Sie Personen, die mit dem Problem konfrontiert sind, das Ihr Projekt löst.** Suchen Sie in verwandten Foren nach Personen, die in die Zielgruppe Ihres Projekts fallen, beantworten Sie deren Fragen und finden Sie einen taktvollen Weg, um Ihr Projekt als Lösung vorzuschlagen. +* **Bitten Sie um Feedback.** Stellen Sie sich und Ihre Arbeit einem Publikum vor, das Sie für relevant und interessant hält, und geben Sie an, wer Ihrer Meinung nach von Ihrem Projekt profitieren könnte. Versuchen Sie, diesen Satz zu vervollständigen: _"Ich denke, dass mein Projekt wirklich den X helfen würde, die versuchen, Y zu tun."_. Hören Sie zu und reagieren Sie auf das Feedback anderer, anstatt einfach nur Ihre Arbeit anzupreisen. + +Generell gilt: Konzentrieren Sie sich darauf, anderen zu helfen, bevor Sie um Gegenleistungen bitten. Da jeder leicht ein Projekt online bewerben kann, wird es eine Menge Rauschen geben: Um sich von der Masse abzuheben, machen Sie den Leuten Ihren persönlichen Kontext klar, und nicht nur Ihre Wünsche. + +Wenn niemand auf Ihre anfängliche Kommunikation achtet oder darauf reagiert, lassen Sie sich nicht entmutigen! Die meisten Projektstarts sind ein iterativer Prozess, der Monate oder Jahre dauern kann. Wenn Sie beim ersten Mal keine Antwort erhalten, versuchen Sie es mit einer anderen Taktik oder suchen Sie nach Wegen, wie Sie die Arbeit anderer zuerst aufwerten können. Ein Projekt zu starten und zu bewerben, erfordert Zeit und Engagement. + +## Gehen Sie auf die Zielgruppe Ihres Projekts zu (offline) + + + +Offline-Veranstaltungen helfen Ihnen dabei, neue Projekte beim Publikum bekannt zu machen und engagierte Leute zu erreichen. Insbesondere können Sie mit Entwickler\*innen direkt in Kontakt treten und Interesse an Ihrem Projekt wecken. + +Wenn Sie gerade erst anfangen, [Vorträge zu halten](http://speaking.io/), tun Sie das am besten auf einem lokalen Treffen ("Meetup"), bei dem es um die Sprache oder die Programmierumgebung geht, in der Ihr Projekt angesiedelt ist. + + + +Wenn Sie noch nie auf einer Veranstaltung gesprochen haben, sind Gefühle der Nervosität völlig normal: Denken Sie daran, dass Ihr Publikum da ist, weil es wirklich von Ihrer Arbeit hören möchte. + +Während Sie Ihren Vortrag ausarbeiten, konzentrieren Sie sich auf das für Ihr Publikum Interessante, das ihm einen Mehrwert bietet. Gestalten Sie Ihren Vortrag in einem freundlichen, zugänglichen Tonfall. Lächeln, atmen und Spaß haben. + + + +Wenn Sie sich gut vorbereitet fühlen, sollten Sie sich überlegen, mit einem Konferenzvortrag für Ihr Projekt zu werben. Das kann Ihnen helfen, mehr Menschen zu erreichen; Manchmal aus der ganzen Welt. + +Suchen Sie nach Konferenzen, die speziell auf Ihre Sprache oder Ihre Programmierumgebung zugeschnitten sind. Bevor Sie Ihren Vortrag einreichen, recherchieren Sie die Konferenz, um Ihren Vortrag auf die Teilnehmer\*innen zuzuschneiden und Ihre Chancen zu erhöhen, auf der Konferenz als Redner\*in akzeptiert zu werden. Sie können oft ein Gefühl für Ihr Publikum bekommen, wenn Sie frühere Redner\*innen der Konferenz recherchieren. + + + +## Reputation aufbauen + +Zusätzlich zu den oben skizzierten Strategien ist der beste Weg, Menschen für Beiträge in Ihrem Projekt zu gewinnen, deren Projekte zu teilen und zu unterstützen. + +Wenn Sie Neuankömmlingen helfen, Ressourcen gemeinsam nutzen und durchdachte Beiträge zu anderen Projekten leisten, können Sie einen guten Ruf aufbauen. Ein aktives Mitglied in der Open-Source-Gemeinschaft zu sein, hilft Leuten dabei, den Kontext Ihrer Arbeit zu verstehen. Es wird zudem wahrscheinlicher, dass Leute Ihr Projekt aufmerksam verfolgen und teilen. Die Entwicklungsbeziehungen zu anderen Open-Source-Projekten können sogar zu offiziellen Kooperationen führen. + + + +Es ist nie zu früh oder zu spät, um mit dem Aufbau eines guten Rufs zu beginnen. Auch wenn Sie bereits ein eigenes Projekt gestartet haben, suchen Sie weiterhin nach Möglichkeiten, anderen zu helfen. + +Ein Publikum aufzubauen, schafft man nicht über Nacht. Das Vertrauens und den Respekt anderer zu gewinnen, nimmt Zeit in Anspruch, und der Aufbau Ihres Rufes endet nie. + + + +## Weitermachen! + +Es kann lange dauern, bis Leute Ihr Open-Source-Projekt bemerken. Das ist in Ordnung! Einige der populärsten Projekte erreichten erst nach Jahren ein hohes Aktivitätsniveau. Konzentrieren Sie sich darauf, Kontakte aufzubauen, anstatt zu hoffen, dass Ihr Projekt spontan an Popularität gewinnt. Seien Sie geduldig und teilen Sie Ihre Arbeit mit denen, die sie zu schätzen wissen. diff --git a/_articles/de/getting-paid.md b/_articles/de/getting-paid.md new file mode 100644 index 0000000000000000000000000000000000000000..aa061f71f057dc17f1792cb6860e8b023cac39b7 --- /dev/null +++ b/_articles/de/getting-paid.md @@ -0,0 +1,212 @@ +--- +lang: de +title: Für Open-Source-Arbeit bezahlt werden +description: Verstetigen Sie Ihre Open-Source-Arbeit, indem Sie finanzielle Unterstützung für Ihre Zeit oder Ihr Projekt erhalten. +class: getting-paid +order: 7 +image: /assets/images/cards/getting-paid.png +related: + - best-practices + - leadership +--- + +## Warum manche Menschen finanzielle Unterstützung suchen + +Ein Großteil der Open-Source-Arbeit wird ehrenamtlich geleistet, z.B. wenn jemand in einem Projekt, das er benutzt, auf einen Fehler stößt und eine schnelle Lösung vorschlägt. Außerdem basteln viele Leute einfach in ihrer Freizeit an einem Open-Source-Projekt. + + + +Es gibt viele Gründe, warum eine Person _nicht_ für ihre Open-Source-Arbeit bezahlt werden möchte. + +* **Sie haben vielleicht schon einen Vollzeitjob, den sie lieben,** und der ihnen ermöglicht, in ihrer Freizeit einen Beitrag zu Open-Source-Software zu leisten. +* **Sie mögen Open Source als Hobby,** oder als kreative Flucht und wollen sich finanziell nicht verpflichtet fühlen, an ihren Projekten arbeiten zu müssen. +* **Sie ziehen andere Vorteile aus ihren Open-Source-Beiträgen,** wie z.B. den Aufbau ihres Rufs oder Portfolios, das Erlernen neuer Fertigkeiten oder das Gefühl, in einer Gemeinschaft eingebettet zu sein. + + + +Für andere kann eine Bezahlung die einzige Möglichkeit sein, sich an Open Source zu beteiligen. Sei es, weil das Projekt ständige oder zeitintensive Mitarbeit erfordert, oder seien es persönliche Gründe. + +Populäre Projekte aufrecht zu erhalten, kann eine große Verantwortung sein, die 10 oder 20 Stunden pro Woche in Anspruch nimmt, statt nur ein paar Stunden pro Monat. + + + +Bezahlte Arbeit ermöglicht Leuten aus verschiedenen Lebenssituationen heraus, sinnvolle Beiträge zu leisten. Manche Menschen können es sich eben nicht leisten, unbezahlte Zeit für Open-Source-Projekte aufzuwenden, z.B. weil ihre finanzielle Situation, Schulden, Familien- oder anderen Betreuungspflichten dies nicht zulassen. Das heißt, die möglichen Beiträge von talentierten Menschen, die es sich ehrenamtliche Arbeitszeit nicht leisten können, würden nie das Licht der Welt erblicken. Dies hat ethische Implikationen, wie @ashedryden [beschreibt](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), da die Beiträge, die das Licht der Welt erblicken, eher zu Gunsten derjenigen tendieren, die bereits Vorteile im Leben haben. Und sie diese aufgrund ihrer freiwilligen Beiträge weiter ausbauen können, während Andere, die nicht zu freiwilligem Engagement in der Lage sind, auch daraus keine Vorteile ziehen können. Dies wiederum verstärkt den derzeitigen Mangel an Vielfalt in der Open-Source-Welt. + + + +Wenn Sie auf der Suche nach finanzieller Unterstützung sind, gibt es zwei Möglichkeiten: Sie können Ihre eigene Arbeitszeit finanzieren, oder Sie können eine organisatorische Finanzierung für das Projekt finden. + +## Die eigene Arbeitszeit finanzieren + +Heutzutage werden viele Leute für Open-Source in Teil- oder Vollzeit bezahlt. Der häufigste Weg dahin ist, mit Ihrem Arbeitgeber darüber zu sprechen. + +Es ist einfacher, sich für Open-Source-Arbeiten zu entscheiden, wenn Ihr Arbeitgeber das Projekt tatsächlich nutzt. Wenn nicht, werden Sie kreativ: Vielleicht nutzt Ihr Arbeitgeber nicht das Projekt, aber Python, und die Pflege eines beliebten Python-Projekts hilft dabei, neue Python-Entwickler\*innen anzuziehen. Vielleicht sieht Ihr Arbeitgeber dadurch generell entwicklerfreundlicher aus. + + + +Wenn Sie kein existierendes Open-Source-Projekt haben, an dem Sie gerne arbeiten würden, sondern lieber Ihre aktuellen Arbeitsergebnisse quell-offen hätten, sollten Sie Ihren Arbeitgeber bitten, einen Teil seiner internen Software zu öffnen. + +Viele Unternehmen entwickeln Open-Source-Programme, um ihre Marke aufzubauen und Talente zu rekrutieren. + +@hueniverse z.B., fand heraus, dass es finanzielle Gründe gab, die [Investition von Walmart in Open Source zu rechtfertigten.](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). Und @jamesgpearce fand heraus, dass Facebooks Open-Source-Program [den Unterschied in der Personalakquise](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) machte: + +> Es ist eng mit unserer Hackerkultur und der Wahrnehmung unseres Unternehmens verbunden. Wir fragten unsere Angestellten: "Kanntet ihr das Open-Source-Programm von Facebook?". Zwei Drittel sagten "Ja". Die Hälfte sagte, dass das Programm positiv zu ihrer Entscheidung beigetragen hat, für uns zu arbeiten. Das sind keine marginalen Zahlen, und ein sich hoffentlich fortsetzender Trend. +> +> It is closely aligned with our hacker culture, and how our organization was perceived. We asked our employees, "Were you aware of the open source software program at Facebook?". Two-thirds said "Yes". One-half said that the program positively contributed to their decision to work for us. These are not marginal numbers, and I hope, a trend that continues. + +Wenn Ihr Unternehmen diesen Weg einschlägt, ist es wichtig, die Grenzen zwischen Gemeinschafts- und Unternehmenstätigkeit klar zu halten, denn Open Source erhält sich letztlich durch Beiträge von Menschen auf der ganzen Welt. Und das ist größer als jedes einzelne Unternehmen oder jeder einzelne Standort. + + + +Wenn Sie Ihren derzeitigen Arbeitgeber nicht davon überzeugen können, Open-Source-Arbeit zu priorisieren, sollten Sie sich überlegen, einen neuen Arbeitgeber zu finden, der Mitarbeit an Open Source fördert. Zum Beispiel: + +* Manche Firmen, wie [Netflix](https://netflix.github.io/) oder [PayPal](https://paypal.github.io/), zeigen ihr Open-Source-Engagement auf ihren Webseiten +* [Zalando](https://opensource.zalando.com) veröffentlicht seine [Open-Source-Beitragsrichtlinie](https://opensource.zalando.com/docs/using/contributing/) für Angestellte + +Aus einer großen Firma stammende Projekte, wie z.B. [Go](https://github.com/golang) oder [React](https://github.com/facebook/react), stellen vermutlich auch weiterhin Leute für Open-Source-Arbeit an. + +Außerdem können Sie versuchen, abhängig von Ihren persönlichen Umständen, selbstständig Geld zu sammeln, um Ihre Open-Source-Arbeit zu finanzieren, zum Beispiel: + +* @gaearon finanzierte seine Arbeit an [Redux](https://github.com/reactjs/redux) mittels einer [Patreon-Crowdfunding-Kampagne](https://redux.js.org/) +* @andrewgodwin finanzierte Arbeit an Djangos Schemamigrations [mittels einer Kickstarter-Kampagne](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) + +## Geldquellen für Ihr Projekt auftun + +Abgesehen von Vereinbarungen für einzelne Projektteilnehmer\*innen, sammeln Projekte manchmal Geld von Unternehmen, Einzelpersonen oder anderen ein, um die laufende Arbeit zu finanzieren. + +Geld von einer Organisation kann verwendet werden, aktuelle Projektteilnehmer\*innen zu bezahlen, die Kosten für den Betrieb des Projekts zu decken (z.B. Hosting-Gebühren) oder in neue Funktionen oder Ideen zu investieren. + +Da Open Source populärer wird, ist die Finanzierung von Projekten immer noch experimentell, aber es gibt einige allgemeine Optionen. + +### Geld mittels Crowdfunding-Kampagnen oder Sponsoren einsammeln + +Sponsoren lassen sich einfacher finden, wenn Sie bereits ein starkes Publikum oder einen guten Ruf haben, oder Ihr Projekt sehr beliebt ist. + +Hier einige Beispiele für gesponsorte Projekte: + +* **[webpack](https://github.com/webpack)** sammelt Geld von Firmen und Einzelpersonen [mittels OpenCollective](https://opencollective.com/webpack) +* **[Vue](https://github.com/vuejs/vue)** wird [mittels Patreon finanziert](https://github.com/open-source/stories/yyx990803) +* **[Ruby Together](https://rubytogether.org/),** eine nicht-Gewinn-orientierte Organisation zahlt für die Arbeit an [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), und anderen Ruby-Infrastrukturprojekten + +### Eine Einnahmequelle schaffen + +Abhängig von Ihrem Projekt können Sie kommerziellen Support, gehostete Optionen oder zusätzliche Funktionen in Rechnung stellen. Wie beispielsweise: + +* **[Sidekiq](https://github.com/mperham/sidekiq)** bietet Bezahlversionen mit zusätzlichem Support +* **[Travis CI](https://github.com/travis-ci)** bietet Bezahlversionen ihres Dienstes +* **[Ghost](https://github.com/TryGhost/Ghost)** ist ein Non-Profit mit Bezahldiensten + +Einige populäre Projekte, wie z.B. [npm](https://github.com/npm/npm) und [Docker](https://github.com/docker/docker), sammeln sogar Wagniskapital ein, um ihr Wachstum zu unterstützen. + +### Fördermittel beantragen + +Einige Softwarestiftungen und Unternehmen bieten Zuschüsse für Open-Source-Arbeiten an. Manchmal können Zuschüsse an Einzelpersonen ausgezahlt werden, ohne eine juristische Person für das Projekt zu gründen. + +* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** erhielt eine Förderung des [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/) +* Arbeiten an **[OpenMRS](https://github.com/openmrs)** wurden von [Stripes Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) gefördert +* **[Libraries.io](https://github.com/librariesio)** erhielt Fördermittel der [Sloan Foundation](https://sloan.org/programs/digital-technology) +* Die **[Python Software Foundation](https://www.python.org/psf/grants/)** fördert Python-relvante Arbeiten + +Weitere, detaillierter erklärte Möglichkeiten, um für Open-Source-Arbeit bezahlt zu werden, finden Sie in [der Anleitung "Lemonade Stand"](https://github.com/nayafia/lemonade-stand) von @nayafia. Die verschiedenen Finanzierungsarten erfordern unterschiedliche Fähigkeiten, die Sie Ihren Stärken entsprechend in Erwägung ziehen sollten. + +## Eine Argumentationslinie für finanzielle Unterstützung aufbauen + +Egal ob Ihr Projekt eine neue Idee umsetzt, oder schon seit Jahren besteht: Sie sollten sich Gedanken über passende Finanzierung machen, Geldquellen identifizieren, und diesen ein überzeugendes Argument liefern können. + +Egal, ob Sie für Ihre eigene Zeit oder für ein Projekt Geld sammeln möchten, Sie sollten in der Lage sein, die folgenden Fragen zu beantworten. + +### Einfluss + +Warum ist dieses Projekt nützlich? Warum gefällt es Ihren (potenziellen) Nutzer\*innen so gut? Wo wird es in fünf Jahren sein? + +### Wichtigkeit + +Versuchen Sie Beweise für die Wichtigkeit Ihres Projektes zu sammeln: Metriken, Anekdoten oder Referenzen. Gibt es Unternehmen oder bemerkenswerte Personen, die Ihr Projekt gerade nutzen? Falls nicht, hat es jemand Bekanntes empfohlen? + +### Nutzen für die Geldgeber + +Geldgeber (sei es Ihr\*e Arbeitgeber\*in oder eine Förderstiftung) werden von vielen Anderen angesprochen: Warum sollte gerade Ihr Projekt unterstützt werden? Wie profitiert der Geldgeber selbst davon? + +### Nutzung der Gelder + +Was genau werden Sie mit der vorgeschlagenen Finanzierung erreichen? Konzentrieren Sie sich auf Projektmeilensteine oder -ergebnisse, anstatt ein Gehalt zu zahlen. + +### Wie empfangen Sie das Geld + +Hat der Geldgeber irgendwelche Anforderungen an die Auszahlung? Müssen Sie beispielsweise eine gemeinnützige Organisation sein, oder einen gemeinnützigen finanziellen Sponsor haben? Oder werden die Mittel an eine\*n einzelne\*n Auftragnehmer\*in anstatt an eine Organisation vergeben? Diese Anforderungen variieren zwischen den Geldgebern, also sollten Sie dies im Vorhinein in Erfahrung bringen. + + + +## Experimentieren und nicht aufgeben + +Es ist nicht einfach, Geld zu sammeln. Egal ob Sie ein Open-Source-Projekt, einen gemeinnützigen Verein oder ein Software-Startup betreiben. In den meisten Fällen müssen Sie kreativ werden. Identifizieren Sie den Modus der Bezahlung, stellen Sie Recherchen an und versetzen Sie sich selbst in die Rolle der Geldgeber\*innen. Dies wird Ihnen beim Finden eines überzeugenden Argumentes für die Finanzierung helfen. diff --git a/_articles/de/how-to-contribute.md b/_articles/de/how-to-contribute.md new file mode 100644 index 0000000000000000000000000000000000000000..b94b7043554c349a7b535477fb5c64c514d21047 --- /dev/null +++ b/_articles/de/how-to-contribute.md @@ -0,0 +1,634 @@ +--- +lang: de +title: Wie zu Open Source beitragen? +description: Möchten Sie zu Open Source beitragen? Hier finden Sie einen Leitfaden für Einsteiger und Fortgeschrittene. +class: contribute +order: 1 +image: /assets/images/cards/contribute.png +related: + - beginners + - building +--- + +## Warum eigentlich zu Open-Source-Projekten beitragen? + + + +Zu Open Source beizutragen, kann ein lohnender Weg sein, um nahezu alle erdenklichen Fertigkeiten zu erlernen, zu lehren und Erfahrungen zu sammeln. + +Warum tragen Menschen zu Open Source bei? Es gibt viele Gründe! + +### Software verbessern, auf die Sie sich verlassen. + +Viele Open-Source-Beitragende waren vorher Nutzer\*innen der Software, zu der sie beitragen. Wenn Sie einen Fehler in einer von Ihnen verwendeten Open-Source-Software finden, sollten Sie sich im Quellcode umsehen, ob Sie den Fehler evtl. selbst patchen können. Wenn ja, ist einen Patch einzureichen der beste Weg sicherzustellen, dass Ihre Kolleg\*innen (und Sie selbst, wenn Sie auf die nächste Version aktualisieren) davon profitieren können. + +### Bestehende Fähigkeiten verbessern + +Ob Programmierung, User Interface Design, Grafikdesign, Schreiben oder Organisieren: Wenn Sie auf der Suche nach Praxiserfahrung sind, werden Sie dafür passende Aufgaben in einem Open-Source-Projekt finden. + +### Treffen Sie Menschen, die an ähnlichen Dingen interessiert sind + +Open-Source-Projekte mit warmherzigen, einladenden Communities schaffen langfristige Hobbys für viele Leute. Lebenslange Freundschaften können durch ihre Teilnahme an Open Source entstehen, sei es bei Konferenzen oder bei nächtlichen Online-Chats über Lahmacuns. + +### Mentoren finden und andere unterrichten + +Wenn Sie mit anderen an einem gemeinsamen Projekt arbeiten, müssen Sie erklären, wie Sie dabei vorgehen und gleichzeitig andere Menschen um Hilfe bitten. Das Lernen und Lehren kann eine erfüllende Tätigkeit für alle Beteiligten sein. + +### Öffentliche Ergebnisse zeugen von Ihrer Arbeit und fördern Ihren Ruf (und Ihre Karriere) + +Per Definition ist Ihre gesamte Open-Source-Arbeit öffentlich. Sie erstellen automatisch ein Portfolio. So können Sie überall vorzeigen, was Sie zu leisten im Stande sind. + +### Sozialkompetenzen erlernen + +Softwareentwicklung ist eine soziale Tätigkeit, und Open-Source-Projekte bieten Führungserfahrungen, denn es müssen z.B. Konflikte gelöst, Teams organisiert und Aufgaben priorisiert werden. + +### Es ist ermutigend, auch kleine Änderungen vornehmen zu können. + +Sie müssen nicht lebenslang an Open Source mithelfen. Haben Sie schon einmal einen Tippfehler auf einer Website gesehen und sich gewünscht, dass ihn jemand beheben würde? Bei einem Open-Source-Projekt können Sie genau das tun. Open Source hilft Leuten, selbst in die Hand zu nehmen, wie sie die Welt erleben, und das ist an sich schon befriedigend. + +## Was "einen Beitrag leisten" bedeutet + +Wenn Sie gerade erst anfangen, Open-Source-Arbeit zu leisten, kann der Prozess einschüchternd wirken. Wie finden Sie das richtige Projekt? Was, wenn Sie nicht wissen, wie man programmiert? Was, wenn etwas schief geht? + +Keine Sorge! Es gibt viele Möglichkeiten, zu einem Open-Source-Projekt beizutragen. Die folgenden paar Tipps helfen Ihnen, dabei gute Erfahrungen zu machen. + +### Sie müssen keinen Code beisteuern + +Ein weit verbreiteter Irrtum! Aber in Wirklichkeit sind es oft andere Projektaspekte, die am [meisten Unterstützung benötigen](https://github.com/blog/2195-the-shape-of-open-source). Sie tun dem Projekt einen _großen_ Gefallen, indem Sie anbieten, bei nicht-Code-Aspekten mitzuwirken! + + + +Auch wenn Sie gerne Code schreiben, sind andere Beitragsarten eine gute Möglichkeit, sich an einem Projekt zu beteiligen und andere Leute aus der Community zu treffen. Solche Beziehungen aufzubauen, ebnet Ihnen den Weg zur Mitarbeit an anderen Projektaspekten. + + + +### Planen Sie gerne Veranstaltungen? + +* Veranstalten Sie Workshops oder Meetups über das Projekt, wie @fzamperin [für NodeSchool](https://github.com/nodeschool/organizers/issues/406) +* Organisieren Sie die Projektkonferenz (falls vorhanden) +* Unterstützen Sie die Community-Mitglieder dabei, die richtigen Konferenzen zu finden und dort Vortragsideen einzureichen. + +### Mögen Sie Design-Arbeit? + +* Verbessern Sie Layouts, um das Projekt benutzerfreundlicher zu machen +* Führen Sie Nutzerstudien durch, um Navigation oder Menüs der Software zu verfeinern ([wie z.B. Drupal es vorschlägt](https://www.drupal.org/community-initiatives/drupal-core/usability)) +* Erstellen Sie einen Designleitfaden, um dem Projekt zu einem einheitlichen visuellen Design zu verhelfen +* Erstellen Sie Kunst für T-Shirts oder ein neues Logo, [wie z.B. die Mitwirkenden von hapi.js](https://github.com/hapijs/contrib/issues/68) + +### Schreiben Sie gerne? + +* Erstellen und verbessern Sie die Projektdokumentation +* Erstellen Sie eine Übersicht von Anwendungsbeispielen, welche die Verwendungsmöglichkeiten der Software zeigen +* Starten Sie einen Newsletter für das Projekt oder kuratieren Sie Highlights aus der Mailingliste +* Schreiben Sie Tutorials für das Projekt, so [wie die Mitwirkenden von PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194) +* Übersetzen Sie die Projektdokumentation + + + +### Organisieren Sie gerne? + +* Verlinken Sie doppelte Issues und schlagen Sie neue Labels vor, um den Issue Tracker in Ordnung zu halten +* Gehen Sie offene Issues durch und schlagen Sie alte zur Schließung vor, wie @nzakas [in ESLint](https://github.com/eslint/eslint/issues/6765) +* Stellen Sie konstruktive Fragen zu kürzlich eingereichten Issues, um Diskussionen voranzubringen + +### Mögen Sie das Programmieren? + +* Finden Sie ein offenes Issue, das Sie bearbeiten können, wie @dianjin [in Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) +* Bieten Sie die Implementierung neuer Funktionen an +* Automatisieren Sie etwas, z.B. die Softwareinstallation +* Verbessern Sie Werkzeuge oder Tests + +### Helfen Sie gerne anderen Leuten? + +* Beantworten Sie Fragen zum Projekt, z.B. auf Stack Overflow ([wie dieses Postgres-Beispiel zeigt](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) oder auf Reddit +* Beantworten Sie Fragen in offenen Issues +* Helfen Sie bei der Moderation von Diskussionsforen oder anderen Kommunikationskanälen + +### Helfen Sie gerne Anderen beim Programmieren? + +* Überprüfen Sie den Code in Pull Requests +* Schreiben Sie Tutorials, wie ein Projekt verwendet werden kann +* Bieten Sie einem Anderen Mentoring an, wie @ereichert für @bronzdoc [in Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) + +### Es muss nicht immer ein Softwareprojekt sein! + +Während sich "Open Source" oft auf Software bezieht, kann man an fast allen anderen Arten von Projekten zusammenarbeiten: Bücher, Rezepte, Listen, Kurse, uvm. werden als Open-Source-Projekte entwickelt. + +Zum Beispiel: + +* @sindresorhus kuratiert eine [Liste von "awesome"-Listen](https://github.com/sindresorhus/awesome) +* @h5bp unterhält eine [Liste möglicher Bewerbungsfragen](https://github.com/h5bp/Front-end-Developer-Interview-Questions) für Frontend-Entwickler\*innen +* @stuartlynn und @nicole-a-tesla [sammeln lustige Fakten über Papageitaucher](https://github.com/stuartlynn/puffin_facts) + +Auch wenn Sie ein\*e Software-Entwickler\*in sind, kann Ihnen die Arbeit an einem Dokumentationsprojekt den Einstieg in Open Source erleichtern. Es ist oft weniger einschüchternd, an Projekten zu arbeiten, die keinen Code beinhalten, um Vertrauen und Erfahrung in den Zusammenarbeitsprozess als solchen zu stärken. + +## Sich in einem neuen Projekt orientieren + + + +Für alles über eine Tippfehlerkorrektur hinaus ist ein Beitrag zu Open Source, als würde man sich zu einer Gruppe von Fremden auf einer Party gesellen. Wenn Sie anfangen, über Lamas zu reden, während die Anderen tief in einer Diskussion über Goldfische stecken, werden diese Sie wahrscheinlich ein wenig seltsam ansehen. + +Bevor Sie blindlings mit Ihren eigenen Vorschlägen daherkommen, lernen Sie zunächst, die Situation einzuschätzen. Dies erhöht die Chancen, dass später Ihre Ideen wahrgenommen und gehört werden. + +### Anatomie eines Open-Source-Projekts + +Jede Open-Source-Community ist anders. + +Jahrelanges Arbeiten an einem Open-Source-Projekt bedeutet, dass Sie dieses eine kennengelernt haben. Wechseln Sie zu einem anderen Projekt, werden Sie feststellen, dass das Vokabular, die Normen und die Kommunikationsstile völlig unterschiedlich sein können. + +Allerdings folgen viele Open-Source-Projekte einer ähnlichen Organisationsstruktur. Das Verständnis der verschiedenen Rollen in der Community und des Gesamtprozesses wird Ihnen helfen, sich schnell auf jedes neue Projekt einzustellen. + +Ein typisches Open-Source-Projekt beinhaltet die folgenden Typen von Personen: + +* **Autor\*in:** Die Person/en oder Organisation, die das Projekt erstellt hat/haben +* **Owners:** Die Person/en, die administrativen Zugang zu der Organisation oder dem Repository hat/haben (nicht immer derselbe wie der/die ursprüngliche Autor*in). +* **Maintainers:** Mitwirkende, die für die Umsetzung der Vision verantwortlich sind und für die organisatorischen Aspekte des Projekts. (Dies können auch Autoren oder Eigentümerinnen des Projekts sein.) +* **Contributors:** Alle, die etwas zum Projekt beigetragen haben. +* **Community-Mitglieder:** Personen, die das Projekt nutzen. Sie können in Diskussionen aktiv sein oder ihre Meinung über die Richtung des Projekts äußern. + +Größere Projekte können auch Gremien oder Arbeitsgruppen haben, die sich auf verschiedene Aufgaben konzentrieren, wie z.B. Tooling, Triage, Community-Moderation und Eventorganisation. Suchen Sie auf der Website eines Projekts nach einer "Team"-Seite oder im Repository nach "Governance"-Dokumentation, um diese Informationen zu finden. + +Ein Projekt hat auch eine Dokumentation. Diese Dateien werden in der Regel im Hauptverzeichnis eines Repositories aufgelistet. + +* **LICENSE:** Per Definition muss jedes Open-Source-Projekt eine [Open-Source-Lizenz](https://choosealicense.com) haben. Wenn das Projekt keine Lizenz hat, ist es nicht Open Source. +* **README:** Die README ist die Bedienungsanleitung, die neue Community-Mitglieder im Projekt willkommen heißt. Sie erklärt, warum das Projekt nützlich ist, und wie man beginnen kann, es zu nutzen. +* **CONTRIBUTING:** Während READMEs den Menschen helfen, das Ergebnis des Projektes _zu nutzen_, hilft die Kontributionsdokumentation dabei, zum Projekt beizutragen. Sie erklärt, welche Arten von Beiträgen benötigt werden und wie der Prozess funktioniert. Obwohl nicht jedes Projekt eine CONTRIBUTING-Datei hat, signalisiert ihre Präsenz, dass dieses Projekt offen für Beiträge ist. +* **CODE_OF_CONDUCT:** Der Verhaltenskodex legt die Grundregeln für das Verhalten der Teilnehmer\*innen fest und trägt dazu bei, ein freundliches und einladendes Umfeld zu schaffen. Obwohl nicht jedes Projekt eine CODE_OF_CONDUCT-Datei hat, signalisiert ihre Präsenz, dass dieses Projekt offen für Beiträge ist. +* **Andere Dokumentation:** Es kann zusätzliche Tutorials, Walkthroughs oder Governance-Richtlinien geben, vor allem bei größeren Projekten. + +Schließlich verwenden Open-Source-Projekte die folgenden Werkzeuge, um Diskussionen zu organisieren. Wenn Sie die Archive durchlesen, erhalten Sie ein gutes Bild davon, wie die Gemeinschaft denkt und arbeitet. + +* **Issue Tracker:** Hier diskutieren Personen über Themen, die im Zusammenhang mit dem Projekt stehen. +* **Pull Requests:** Hier diskutieren und überprüfen Personen anstehende Änderungen. +* **Diskussionsforen oder Mailinglisten:** Einige Projekte nutzen solche Kanäle für Konversationen (z.B. _"Wie kann ich..."_ oder _"Was denkt ihr über..."_) anstelle von Fehlerberichten oder Feature Requests. Andere verwenden den Issue Tracker für alle Konversationen. +* **Synchroner Chat-Kanal:** Einige Projekte verwenden Kanäle wie z.B. Slack oder IRC für gelegentliche Gespräche, Zusammenarbeit und schnellen Austausch. + +## So finden Sie ein Projekt, zu dem Sie beitragen können + +Sie haben gelernt, wie Open-Source-Projekte funktionieren. Jetzt ist es an der Zeit, ein Projekt zum Beitragen zu finden! + +Wenn Sie noch nie zu Open Source beigetragen haben, nehmen Sie einen Ratschlag von US-Präsident John F. Kennedy an, der einmal sagte: _"Fragen Sie nicht, was Ihr Land für Sie tun kann - fragen Sie, was Sie für Ihr Land tun können". + +Zu Open Source können Sie auf allen möglichen Ebenen beitragen, in allen möglichen Projekten. Sie müssen nicht darüber nachdenken, was genau Ihr erster Beitrag sein wird oder wie er aussehen wird. + +Denken Sie stattdessen zunächst über die Projekte nach, die Sie bereits verwenden oder verwenden möchten. Nach dieser Logik könnten dies die Projekte werden, zu denen Sie aktiv beitragen werden. + +Innerhalb dieser Projekte, wann immer Sie sich denken, dass etwas besser oder anders sein könnte, handeln Sie nach Ihrem Instinkt. + +Open Source ist kein exklusiver Club, sondern besteht auf Leuten wie Ihnen. "Open Source" ist nur ein schicker Begriff, um die Probleme der Welt als behebbar zu begreifen. + +Sie können eine README überfliegen und einen defekten Link oder einen Tippfehler finden. Oder Sie sind ein\*e neue\*r Benutzer\*in und haben bemerkt, dass etwas kaputt ist, oder ein Problem, das Ihrer Meinung nach wirklich dokumentiert sein sollte. Anstatt es zu ignorieren und weiterzuziehen oder jemand zu bitten, es zu reparieren, können Sie vielleicht selbst mitmachen und mithelfen. Das ist des Pudels Kern bei Open Source! + +> [28% der Gelegenheitsbeiträge](https://www.igor.pro.br/publica/papers/saner2016.pdf) zu Open Source betreffen die Dokumentation (z.B. eine Korrektur der Rechtschreibung oder Formatierung, oder das Schreiben einer Übersetzung). +> +> [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as a typo fix, reformatting, or writing a translation. + +Wenn Sie Issues suchen, die Sie beheben könnten, hat jedes Open-Source-Projekt eine Seite, die Neuling-freundliche Issues aufzeigt. Navigieren Sie zur Repository-Hauptseite auf GitHub und fügen Sie `/contribute` der URL hinzu (z.B.[`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)). + +Weiterhin, können Sie auf folgenden Seiten neue Projekte zum Beitragen entdecken (alle englischsprachig): + +* [GitHub Explore](https://github.com/explore/) +* [Open Source Friday](https://opensourcefriday.com) +* [First Timers Only](https://www.firsttimersonly.com/) +* [CodeTriage](https://www.codetriage.com/) +* [24 Pull Requests](https://24pullrequests.com/) +* [Up For Grabs](https://up-for-grabs.net/) +* [Contributor-ninja](https://contributor.ninja) +* [First Contributions](https://firstcontributions.github.io) +* [SourceSort](https://www.sourcesort.com/) + +### Eine Checkliste, bevor Sie einen Beitrag leisten + +Wenn Sie ein Projekt gefunden haben, zu dem Sie beitragen möchten, prüfen Sie kurz, ob das Projekt Ihren Beitrag wahrscheinlich annehmen wird oder nicht. Sonst wird Ihre harte Arbeit vielleicht nicht fruchten. + +Hier ist eine praktische Checkliste, um zu beurteilen, ob ein Projekt für neue Mitwirkende geeignet ist. + +**Erfüllt die Definition von Open Source** + +
Creo que las pruebas son necesarias para todo código en el que la gente trabaja. Si el código era totalmente y perfectamente correcto, no necesitaría cambios - sólo escribimos código cuando algo está mal, ya sea "Se bloquea" o "Falta tal o cual característica". Independientemente de los cambios que estés haciendo, las pruebas son esenciales para capturar cualquier regresión que pueda introducir accidentalmente.
-— @edunham, ["Automatización de la comunidad de Rust"](http://edunham.net/2016/09/27/rust_s_community_automation.html) +— @edunham, ["Automatización de la comunidad de Rust"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
diff --git a/_articles/es/building-community.md b/_articles/es/building-community.md index d91ec7c555ab9cd2933fc764f03f8ae6a67fdb0f..92e4d643ff7d9cdd9dec138b5592124129f710ac 100644 --- a/_articles/es/building-community.md +++ b/_articles/es/building-community.md @@ -3,10 +3,6 @@ lang: es title: Construyendo Comunidades de Bienvenida description: Construyendo una comunidad que anime a al gente a usar, contribuir y educar con su proyecto class: building -toc: - configurando-tu-proyecto-para-el-éxito: "Configurando tu proyecto para el éxito" - haciendo-crecer-tu-comunidad: "Haciendo crecer tu comunidad" - resolviendo-conflictos: "Resolviendo conflictos" order: 4 image: /assets/images/cards/building.png related: @@ -22,7 +18,7 @@ Una comunidad de bienvenida es una inversión a futuro a tu proyecto y a t ### Haz que la gente se sienta bienvenida -Una manera de pensar acerca de la comunidad del proyecto es a través de lo que @MikeMcQuaid llama [contributor funnel](https://speakerdeck.com/mikemcquaid/the-open-source-contributor-funnel): +Una manera de pensar acerca de la comunidad del proyecto es a través de lo que @MikeMcQuaid llama [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):  @@ -58,7 +54,7 @@ Animar a otros colaboradores es también invertir en tí mismo . Cua
¿Alguna vez viste un evento (técnico) en donde no conozcas a nadie, pero todos los demás parece que se encuentran en grupos y conversan como viejos amigos? (...) Ahora imagínate queriendo contribuir con un proyecto de código abierto, pero no distingues porqué o cómo esto está sucediendo.
-— @janl, ["Código abierto sostenible"](http://writing.jan.io/2015/11/20/sustainable-open-source.html) +— @janl, ["Código abierto sostenible"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
@@ -117,10 +113,10 @@ Cualquier proyecto popular inevitablemente atraerá a personas que perjudi Haz todo lo posible para adoptar una política de tolerancia cero hacia este tipo de personas. Si no se controla, las personas negativas harán que otras personas de tu comunidad se sientan incómodas. Incluso pueden irse. @@ -136,24 +132,24 @@ En tu archivo CONTRIBUTING, indica de manera explícita a los nuevos colab  -En tu cola de asuntos, etiqueta errores que son convenientes para diferentes tipos de colaboradores: por ejemplo, [_"solo principiantes"_](https://medium.com/@kentcdodds/first-timers-only-78281ea47455#.g1k01jy05), "conveniente para quienes resuelven su primer bug", o "documentación". [Estas etiquetas](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) hacen que sea más fácil buscar problemas a resolver para alguien nuevo en el proyecto y así poder comenzar. +En tu cola de asuntos, etiqueta errores que son convenientes para diferentes tipos de colaboradores: por ejemplo, [_"solo principiantes"_](https://kentcdodds.com/blog/first-timers-only), "conveniente para quienes resuelven su primer bug", o "documentación". [Estas etiquetas](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) hacen que sea más fácil buscar problemas a resolver para alguien nuevo en el proyecto y así poder comenzar. Finalmente, utiliza tu documentación para hacer que las personas se sientan bienvenidas en cada etapa del camino. Nunca vas a interactuar con la mayoría de las personas que se acercan a tu proyecto. Puede haber colaboradores que no recibiste porque álguien se sintió intimidado o no supo cómo comenzar. Incluso algunas palabras amables pueden evitar que esas personas abandonen tu proyecto por verse frustradas -Por ejemplo, así es como [Rubinius](https://github.com/rubinius/rubinius/) comienza su [guía de contribuciones](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md):/ +Por ejemplo, así es como [Rubinius](https://github.com/rubinius/rubinius/) comienza su [guía de contribuciones](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):/ > Queremos comenzar agradeciendo por utilizar Rubinius. Este proyecto es un trabajo de amor, y apreciamos a todos los usuarios que detectan errores, hacen mejoras al rendimiento, y ayudan con su documentación. Cada contribución es significativa, así que gracias por participar. Dicho esto, aquí dejamos algunas pautas que pedimos que sigan para que podamos abordar con éxito su problema. ### Comparte la propiedad de tu proyecto @@ -165,11 +161,11 @@ Observa si puedes encontrar maneras de compartir la propiedad de tu comunidad ta  -* **Inicia un archivo de COLABORADORES o AUTORES en tu proyecto** que liste a todos los que colaboraron con tu proyecto, como lo hace [Sinatra](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md). +* **Inicia un archivo de COLABORADORES o AUTORES en tu proyecto** que liste a todos los que colaboraron con tu proyecto, como lo hace [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md). * Si tienes una comunidad considerable, **envía un boletín o escribe un post en un blog** agradeciendo a los colaboradores. Rust's [This Week in Rust](https://this-week-in-rust.org/) y Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) son dos buenos ejemplos. -* **Da a cada colaborador permiso para hacer commit.** @felixge encontró con esto que las personas [se entusiasmaran por pulir sus parches](http://felixge.de/2013/03/11/the-pull-request-hack.html), e incluso encontró nuevas personas para mantener proyectos en los que no había trabajado hace tiempo. +* **Da a cada colaborador permiso para hacer commit.** @felixge encontró con esto que las personas [se entusiasmaran por pulir sus parches](https://felixge.de/2013/03/11/the-pull-request-hack.html), e incluso encontró nuevas personas para mantener proyectos en los que no había trabajado hace tiempo. * Si tu proyecto está alojado en GitHub, **mueve tu proyecto desde tu cuenta personal hacia una [Organización](https://help.github.com/articles/creating-a-new-organization-account/)** y agrega al menos un administrador de respaldo. Las Organizaciones hacen que sea más fácil trabajar en proyectos con colaboradores externos. @@ -221,7 +217,7 @@ Tu README es [más que un conjunto de instrucciones](../starting-a-project Algunos proyectos utilizan un proceso de votación para tomar decisiones importantes. Si bien parece sensato a primera vista, la votación pone hincapié en una "respuesta", más que en escuchar y tratar las preocupaciones de cada uno. -La votación se puede volver política, cuando los miembros de la comunidad se sienten presionados para hacerse favores entre ellos o a votar de determinada manera. No todos votan, si existe una [mayoría silenciosa](http://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) en tu comunidad, o existen usuarios que no se enteraron que se estaba llevando a cabo una votación. +La votación se puede volver política, cuando los miembros de la comunidad se sienten presionados para hacerse favores entre ellos o a votar de determinada manera. No todos votan, si existe una [mayoría silenciosa](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) en tu comunidad, o existen usuarios que no se enteraron que se estaba llevando a cabo una votación. Algunas veces, la votación se vuelve un desempate necesario. La mayoría de las veces, sin embargo, pone énfasis en la ["búsqueda de concenso"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) más que en concensuar. @@ -257,7 +253,7 @@ Si la conversación claramente no va a ningún lado, no existen acci
Guiar un tópico hacia algo útil sin ser agresivo es un arte. No funcionará simplemente con llamar la atención a las personas para impedir que continúen perdiendo tiempo, ni pedirles que no publiquen a menos que tengan algo constructivo que decir. (...) En su lugar, debes sugerir condiciones para continuar progresando: brinda a las personas una ruta, un camino a seguir que los lleve al resultado que quieres, pero sin aparentar que les estás dictando una conducta.
-— @kfogel, [_Producing OSS_](http://producingoss.com/en/producingoss.html#common-pitfalls) +— @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
diff --git a/_articles/es/code-of-conduct.md b/_articles/es/code-of-conduct.md index a654054cfaf8db81caace045d825c5f25796a011..291cdbe2e1d105c8bdc128d27648305a2d0abc69 100644 --- a/_articles/es/code-of-conduct.md +++ b/_articles/es/code-of-conduct.md @@ -3,11 +3,6 @@ lang: es title: Tu Código de Conducta description: Facilita el comportamiento sano y constructivo, adoptando y aplicando un código de conducta. class: coc -toc: - por-qué-es-necesario-un-código-de-conducta: "Por qué es necesario un código de conducta" - estableciendo-un-código-de-conducta: "Estableciendo un código de conducta" - decidiendo-de-qué-manera-vas-a-aplicar-tu-código-de-conducta: "Decidiendo de qué manera vas a aplicar tu código de conducta" - aplicando-tu-código-de-conducta: "Aplicando tu código de conducta" order: 8 image: /assets/images/cards/coc.png related: @@ -34,7 +29,7 @@ Además de comunicar tus expectativas, un código de conducta descri * Que sucede si alguien viola el código de conducta * De qué manera alguien puede reportar una violación -Siempre que sea posible, haga uso del art. El [Contributor Covenant](http://contributor-covenant.org/) es un código de conducta usado por más de 40,000 proyectos de software libre, incluyendo Kubernetes, Rails, and Swift. +Siempre que sea posible, haga uso del art. El [Contributor Covenant](https://www.contributor-covenant.org/) es un código de conducta usado por más de 40,000 proyectos de software libre, incluyendo Kubernetes, Rails, and Swift. El [Django Code of Conduct](https://www.djangoproject.com/conduct/) y el [Citizen Code of Conduct](http://citizencodeofconduct.org/) son también dos ejemplos de buenos códigos de conducta. @@ -59,7 +54,7 @@ Deberías explicar de qué manera tu código de conducta va a Deberías brindar a las personas, una manera privada (por ejemplo, mediante una dirección de email) de reportar una violación al código de conducta y explicar quién recibe dicho reporte. Puede ser un responsable de mantenimiento, un grupo de tales responsables, o un grupo de trabajo de código de conducta. -Recuerda que alguien puede que desee reportar una violación acerca de la persona que recibe dichos reportes. En tal caso, bríndales la posibilidad de que dichos reportes, sean revisados por alguien más. Por ejemplo, @ctb y @mr-c [explican en su proyecto](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): +Recuerda que alguien puede que desee reportar una violación acerca de la persona que recibe dichos reportes. En tal caso, bríndales la posibilidad de que dichos reportes, sean revisados por alguien más. Por ejemplo, @ctb y @mr-c [explican en su proyecto](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): > Instancias de abuso, acoso o similares comportamientos inaceptables pueden ser reportados mandando un email a **khmer-project@idyll.org** el cual solamente se dirigirá a C. Titus Brown and Michael R. Crusoe. Para reportar una cuestión que involucra a ambos, por favor envía un email a **Judi Brown Clarke, Ph.D.** el Director de Diversidad en el BEACON Center for the Study of Evolution in Action, un centro de la Fundación de Ciencia Nacional para la Ciencia y Tecnologia.* diff --git a/_articles/es/finding-users.md b/_articles/es/finding-users.md index 5bdecddeef51c6fb6400bf5b34222eae769042d1..ceda208fa3bc88f81e06de2061dad25fadddb545 100644 --- a/_articles/es/finding-users.md +++ b/_articles/es/finding-users.md @@ -3,13 +3,6 @@ lang: es title: Encontrando Usuarios Para Tu Proyecto description: Ayuda a tu proyecto de código abierto a crecer ponióndolo en manos de usuarios satisfechos. class: finding -toc: - pasando-la-voz: "Pasando la voz" - pensando-tu-mensaje: "Pensando tu mensaje" - ayuda-a-las-personas-a-encontrar-y-seguir-tu-proyecto: "Ayuda a las personas a encontrar y seguir tu proyecto" - ve-donde-está-la-audiencia-de-tu-proyecto-en-línea: "Ve donde está la audiencia de tu proyecto (en línea)" - ve-donde-está-la-audiencia-de-tu-proyecto-fuera-de-línea: "Ve donde está la audiencia de tu proyecto (fuera de línea)" - construye-una-reputación: "Construye una reputación" order: 3 image: /assets/images/cards/finding.png related: @@ -33,7 +26,7 @@ Por ejemplo, @robb utiliza códigos de ejemplo para comunicar claramente porqué  -Para una vista más profunda sobre cómo comunicar tu mensaje, puedes ver el ejercicio en Mozilla ["Personas and Pathways"](http://mozillascience.github.io/working-open-workshop/personas_pathways/) para el desarrollo de personas usuario. +Para una vista más profunda sobre cómo comunicar tu mensaje, puedes ver el ejercicio en Mozilla ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) para el desarrollo de personas usuario. ## Ayuda a las personas a encontrar y seguir tu proyecto @@ -71,13 +64,13 @@ Ahora que ya tienes un mensaje para tu proyecto, y una manera sencilla para que El alcance en línea es una gran manera de compartir y diseminar la palabra rápidamente -Saca ventaja de las comunidades en línea existentes y sus plataformas para alcanzar tu audiencia. Si tu proyecto es de codigo abierto es un proyecto de software, probablemente puedas encontrar tu audiencia en [Stack Overflow](http://stackoverflow.com/), [reddit](http://www.reddit.com), [Hacker News](https://news.ycombinator.com/), o [Quora](https://www.quora.com/). Encuentra los canales donde pienses que las personas obtendrán los mayores beneficios o se sentirán más entusiasmadas acerca de tu trabajo. +Saca ventaja de las comunidades en línea existentes y sus plataformas para alcanzar tu audiencia. Si tu proyecto es de codigo abierto es un proyecto de software, probablemente puedas encontrar tu audiencia en [Stack Overflow](https://stackoverflow.com/), [reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), o [Quora](https://www.quora.com/). Encuentra los canales donde pienses que las personas obtendrán los mayores beneficios o se sentirán más entusiasmadas acerca de tu trabajo. @@ -97,7 +90,7 @@ Si nadie presta atención o responde a tu alcance inicial, ¡no te desanim Los eventos fuera de línea son una manera popular de promocionar nuevos proyectos. Es una gran manera de alcanzar una audiencia comprometida y de construir conexiones personales más profundas, especialmente si estás interesado en llegar a los desarrolladores. -Si no tienes [experiencia para hablar en público](http://speaking.io/), comienza por encontrar una comunidad local de personas que estén relacionados con el lenguaje o ecosistema de tu proyecto. +Si no tienes [experiencia para hablar en público](https://speaking.io/), comienza por encontrar una comunidad local de personas que estén relacionados con el lenguaje o ecosistema de tu proyecto. diff --git a/_articles/es/getting-paid.md b/_articles/es/getting-paid.md index a98b00a0483367dc3dbef2d15e86f92c572b5a4b..74dd16a930f2fe5a3216277f19161ae760ecc73d 100644 --- a/_articles/es/getting-paid.md +++ b/_articles/es/getting-paid.md @@ -1,13 +1,8 @@ --- lang: es title: Recibir Pagos por Trabajos en Código Abierto -description: Manten tu trabajo de código abierto al encontrar apoyo financiero por tu tiempo o tu proyecto. +description: Mantén tu trabajo de código abierto al encontrar apoyo financiero por tu tiempo o tu proyecto. class: getting-paid -toc: - porqué-algunas-personas-buscan-apoyo-financiero: "¿Porqué algunas personas buscan apoyo financiero?" - financiando-tu-propio-tiempo: "Financiando tu propio tiempo" - encontrando-financiación-para-tu-proyecto: "Encontrando financiación para tu proyecto" - creando-un-caso-de-apoyo-financiero: "Creando un caso de apoyo financiero" order: 7 image: /assets/images/cards/getting-paid.png related: @@ -15,13 +10,13 @@ related: - leadership --- -## ¿Porqué algunas personas buscan apoyo financiero? +## ¿Por qué algunas personas buscan apoyo financiero? La mayor parte del trabajo realizado en proyectos de código abierto es voluntario. Por ejemplo, alguien puede encontrarse con un error en un proyecto que usan y aplican una corrección rápida, o simplemente les puede gustar corregir proyectos de código abierto en su tiempo libre. @@ -47,19 +42,19 @@ Mantener proyectos populares puede ser una responsabilidad significativa, tomand -El trabajo pago también habilita a todo tipo de personas a aportar significativamente. Algunas no pueden afrontar un trabajo ad-honorem (trabajo gratis) en proyectos de código abierto, ya sea por su posición financiera, deudas, familia u otras responsabilidades. Eso significa que el mundo nunca ve contribuciones de personas talentosas que no pueden donar horas de trabajo. Estas implicaciones éticas como @ashedryden [ha descripto](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), desde que el trabajo hecho es parcialmente en favor de las personas que tienen ventajas en su vida, quienes de vuelta ganan ventajas adicionales basadas en sus contribuciones voluntarias, mientras que otros que no pueden ofrecerse voluntariamente no obtiene nuevas oportunidades, lo cual refuerza la actual falta de diversidad en la comunidad de código abierto. +El trabajo pagado también habilita a todo tipo de personas a aportar significativamente. Algunas no pueden afrontar un trabajo ad-honorem (trabajo gratis) en proyectos de código abierto, ya sea por su posición financiera, deudas, familia u otras responsabilidades. Eso significa que el mundo nunca ve contribuciones de personas talentosas que no pueden donar horas de trabajo. Estas implicaciones éticas como @ashedryden [ha descrito](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), desde que el trabajo hecho es parcialmente en favor de las personas que tienen ventajas en su vida, quienes de vuelta ganan ventajas adicionales basadas en sus contribuciones voluntarias, mientras que otros que no pueden ofrecerse voluntariamente no obtiene nuevas oportunidades, lo cual refuerza la actual falta de diversidad en la comunidad de código abierto. @@ -67,13 +62,13 @@ Si tu estas buscando apoyo financiero, hay dos posibles caminos a seguir: puedes ## Financiando tu propio tiempo -Hoy en dia, muchas personas reciben pagos por trabajos part-time o full-time en código abierto. El modo mas común de recibir una paga por tu tiempo es hablar con tu empleador. +Hoy en día, muchas personas reciben pagos por trabajos a tiempo parcial o tiempo completo en código abierto. El modo mas común de recibir una paga por tu tiempo es hablar con tu empleador. -Es mas fácil establecer un trabajo en código abierto si tu empleador usa el proyecto, pero ponte creativo. Puede que tu empleador no use el proyecto, pero usan Python, y mantener un proyecto popular de Python puede atraer nuevos desarrolladores de Python. También puede que haga que tu empleador se vea más desarrollador-amigable en general. +Es mas fácil establecer un trabajo en código abierto si tu empleador usa el proyecto, pero ponte creativo. Puede que tu empleador no use el proyecto, pero usa Python, y mantener un proyecto popular de Python puede atraer nuevos desarrolladores de Python. También puede que haga que tu empleador se vea más desarrollador-amigable en general. @@ -179,7 +172,7 @@ Un proyecto de código abierto tiene los siguientes tipos de personas: * **Colaboradores:** Cualquiera que haya contribuido con algo al proyecto. * **Miembros de la comunidad:** Las personas que utilizan al proyecto. Pueden tener un rol activo en las conversaciones o expresar su opinión sobre la dirección que toma el proyecto. -Los proyectos más grandes pueden tener también subcomisiones o grupos de trabajo enfocados en tareas diferentes, como herramientas, priorización de urgencias, moderación de la comunidad, y organización de eventos. Busca en el sitio web del proyecto una página del "equipo", o en su repositorio para encontrar la documentación política de gobierno, para encontrar ésta documentación. +Los proyectos más grandes pueden tener también subcomisiones o grupos de trabajo enfocados en tareas diferentes, como herramientas, priorización de urgencias, moderación de la comunidad, y organización de eventos. Busca en el sitio web del proyecto una página del "equipo", o en su repositorio para encontrar la documentación política de gobierno, para encontrar esta documentación. Un proyecto también tiene documentación. Estos archivos están normalmente listados en un nivel alto del repositorio. @@ -212,18 +205,19 @@ El código abierto no es un club exclusivo; está hecho de personas Puedes recorrer un archivo README y encontrar un vínculo roto o un error tipográfico. O tal vez eres un nuevo usuario y te diste cuenta de que algo está roto, o hay un problema que crees que realmente debería estar en la documentación. En lugar de ignorarlo y continuar, o solicitar que álguien lo solucione, observa si puedes ayudar lanzándote sobre él. ¡De eso se trata el código abierto! -> [El 28% de las contribuciones casuales](http://www.igor.pro.br/publica/papers/saner2016.pdf) a la documentación del código abierto se trata de documentación, como correcciones tipográficas, reformateos o redacción de una traducción. +> [El 28% de las contribuciones casuales](https://www.igor.pro.br/publica/papers/saner2016.pdf) a la documentación del código abierto se trata de documentación, como correcciones tipográficas, reformateos o redacción de una traducción. Puedes también utilizar algunos de los siguientes recursos para ayudarte a descubrir nuevos proyectos: * [GitHub Explore](https://github.com/explore/) * [Open Source Friday](https://opensourcefriday.com) -* [First Timers Only](http://www.firsttimersonly.com/) -* [Your First PR](https://yourfirstpr.github.io/) +* [First Timers Only](https://www.firsttimersonly.com/) * [CodeTriage](https://www.codetriage.com/) * [24 Pull Requests](https://24pullrequests.com/) -* [Up For Grabs](http://up-for-grabs.net/) +* [Up For Grabs](https://up-for-grabs.net/) * [Contributor-ninja](https://contributor.ninja) +* [First Contributions](https://firstcontributions.github.io) +* [SourceSort](https://www.sourcesort.com/) ### Una lista de verificación antes de que contribuyas @@ -335,7 +329,7 @@ Ahora haz lo mismo para los pull requests del proyecto.
Siempre que veas un hilo largo, comprueba las respuestas de los principales desarrolladores que llegan más tarde al hilo. ¿Están resumiendo de forma constructiva y tomando medidas para llevar el hilo hacia una decisión y al mismo tiempo continúan siendo educados? Si ves que se agitan banderas de guerra pasando en frente, frecuentemente indica que la energía se está encaminando a discutir más que en desarrollar.
-— @kfogel, [_Produciendo Software de código abierto_](http://producingoss.com/en/evaluating-oss-projects.html) +— @kfogel, [_Produciendo Software de código abierto_](https://producingoss.com/en/evaluating-oss-projects.html)
## Cómo enviar una contribución -Ya encontraste un proyecto que te gustaba, y estás listo para hacer una contribución. ¡Por fin! A continuación de mostramos cómo hacer que tu contribución siga por el buen camino. +Ya encontraste un proyecto que te gustaba, y estás listo para hacer una contribución. ¡Por fin! A continuación te mostramos cómo hacer que tu contribución siga por el buen camino. ### Comunicándote de manera efectiva @@ -391,7 +385,7 @@ Sin importar si eres un colaborador para una sola vez o estás intentando
\[Como un nuevo colaborador,\] me di cuenta rápidamente que necesitaba hacer preguntas si quería poder cerrar el problema. Recorrí el código base. Una vez que comprendí lo que estaba ocurriendo, pregunté que me orientaran. ¡Y voilà! Pude resolver el problema luego de conseguir todos los detalles relevantes que necesitaba.
-— @shubheksha, [El Muy Accidentado Viaje de un Principiante a través del Mundo del Código Abierto](https://medium.freecodecamp.com/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39#.pcswr2e78) +— @shubheksha, [El Muy Accidentado Viaje de un Principiante a través del Mundo del Código Abierto](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
@@ -441,9 +435,9 @@ Antes de hacer nada, haz una rápida verificación para asegurarte q Si no puedes encontrar tu idea en ningún otro lado, estás listo para dar el paso. Si el proyecto está en GitHub, es probable que lo comuniques abriendo un problema o un pull request: -* **Problemas (Issues)** son como comenzar una conversación o discusión -* **Pull requests** son para comenzar a trabajar en una solución -* **Para una comunicación ligera,** como una explicación o una pregunta de "cómo", trata preguntando en Stack Overflow, IRC, Slack u otro canal de chat, si el proyecto tiene alguno +* **Problemas (Issues)** son como comenzar una conversación o discusión. +* **Pull requests** son para comenzar a trabajar en una solución. +* **Para una comunicación ligera,** como una explicación o una pregunta de "cómo", trata preguntando en Stack Overflow, IRC, Slack u otro canal de chat, si el proyecto tiene alguno. Antes de abrir un problema o un pull request, verifica los documentos de verificación del proyecto (comúnmente es un archivo que se llama CONTRIBUTING), para ver si se necesitan incluir algo específico, puede ser que soliciten que respetes un modelo, o requerir que utilices pruebas. @@ -461,9 +455,9 @@ Si quieres hacer una contribución sustancial, abre un problema para pregu Frecuentemente deberías abrir un problema en las siguientes situaciones: -* Reportar un error que tú no puedes resolver -* Discutir un tópico o idea de alto nivel (por ejemplo sobre la comunidad, la visión o políticas) -* Proponer una nueva característica u otra idea del proyecto +* Reportar un error que tú no puedes resolver. +* Discutir un tópico o idea de alto nivel (por ejemplo sobre la comunidad, la visión o políticas). +* Proponer una nueva característica u otra idea del proyecto. Consejos para comunicar los problemas: @@ -475,8 +469,8 @@ Consejos para comunicar los problemas: Usualmente deberías abrir un pull request en las siguientes situaciones: -* Enviar arreglos triviales (por ejemplo una corrección tipográfica, un link caído o un error obvio) -* Comenzar a trabajar en una contribución que ya fue solicitada, o que ya discutiste en un problema +* Enviar arreglos triviales (por ejemplo una corrección tipográfica, un link caído o un error obvio). +* Comenzar a trabajar en una contribución que ya fue solicitada, o que ya discutiste en un problema. Un pull request no representa trabajo terminado. Usualmente es mejor abrir un pull request de forma temprana, de manera que otros puedan observar o dar retroalimentación a tu progreso. Solo márcalo como "trabajo en proceso" (WIP por sus siglas en inglés, work in progress) en la línea del tema. Siempre puedes agregar más commits después. @@ -505,7 +499,7 @@ Si no tuviste una respuesta en más de una semana, es justo responder en e **No contactes a esa persona** de manera privada; recuerda que las comunicaciones públicas son vitales para los proyectos de código abierto. -Si haces una llamada educada y todavía nadie responde, es posible que nadie te responda jamás. No es un sentimiento agradable, pero no dejes que de desanime. ¡Les pasa a todos! Existen muchas razones posibles por las que no tuviste tu respuesta, incluyendo circunstancias personales que pueden estar fuera de control. Trata de encontrar otro proyecto u otra forma de contribuir. En todo caso, ésta es una buena razón para no invertir mucho tiempo en hacer contribuciones antes de ver que existen otros miembros en la comunidad que están comprometidos y responden. +Si haces una llamada educada y todavía nadie responde, es posible que nadie te responda jamás. No es un sentimiento agradable, pero no dejes que te desanime. ¡Les pasa a todos! Existen muchas razones posibles por las que no tuviste tu respuesta, incluyendo circunstancias personales que pueden estar fuera de control. Trata de encontrar otro proyecto u otra forma de contribuir. En todo caso, ésta es una buena razón para no invertir mucho tiempo en hacer contribuciones antes de ver que existen otros miembros en la comunidad que están comprometidos y responden. ### 🚧 Alguien pide cambios a tu colaboración. diff --git a/es.html b/_articles/es/index.html similarity index 38% rename from es.html rename to _articles/es/index.html index 88fc218101ac551047edae1e138e06beab64aba4..627d4f8ebb04386da9adacbf6d3a1c33d2812336 100644 --- a/es.html +++ b/_articles/es/index.html @@ -1,4 +1,6 @@ --- layout: index +title: Guías de código abierto lang: es +permalink: /es/ --- diff --git a/_articles/es/leadership-and-governance.md b/_articles/es/leadership-and-governance.md index 0c7403a9ba5d4a1a8463d6cdebfdf276a9049930..851bdb87850e988b397c46a02ddd990170b691c4 100644 --- a/_articles/es/leadership-and-governance.md +++ b/_articles/es/leadership-and-governance.md @@ -3,13 +3,6 @@ lang: es title: Liderazgo y Gobierno description: Los proyectos de código abierto crecientes pueden beneficiarse de reglas formales para tomar decisiones. class: leadership -toc: - cuáles-son-ejemplos-de-roles-formales-utilizados-en-proyectos-de-código-abierto: "¿Cuáles son ejemplos de roles formales utilizados en proyectos de código abierto?" - cómo-formalizo-los-roles-de-liderazgo: "¿Cómo formalizo los roles de liderazgo?" - cuando-le-puedo-dar-acceso-a-hacer-commits-a-alguien: "¿Cuando le puedo dar acceso a hacer commits a alguien?" - cuáles-son-algunas-de-las-estructuras-de-gobierno-comunes-para-los-proyectos-de-código-abierto: "¿Cuáles son algunas de las estructuras de gobierno comunes para los proyectos de código abierto?" - necesito-documentación-de-gobierno-cuando-lanzo-mi-proyecto: "¿Necesito documentación de gobierno cuando lanzo mi proyecto?" - qué-pasa-cuando-los-empleados-de-corporaciones-comienzan-a-enviar-contribuciones: "¿Qué pasa cuando los empleados de corporaciones comienzan a enviar contribuciones?" order: 6 image: /assets/images/cards/leadership.png related: @@ -70,11 +63,11 @@ Si tu proyecto tiene una comunidad de contribuidores muy activa, puede formar un -Los equipos de liderazgo pueden querer crear un canal designado (como en IRC) o reunirse regularmente para discutir el proyecto (como en Gitter o Google Hangout). Incluso puedes hacer públicas esas reuniones para que otras personas puedan escucharlas. [Cucumber-rubí](https://github.com/cucumber/cucumber-ruby), por ejemplo, [hospeda las horas de oficina cada semana](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talk-with-other-devs). +Los equipos de liderazgo pueden querer crear un canal designado (como en IRC) o reunirse regularmente para discutir el proyecto (como en Gitter o Google Hangout). Incluso puedes hacer públicas esas reuniones para que otras personas puedan escucharlas. [Cucumber-rubí](https://github.com/cucumber/cucumber-ruby), por ejemplo, [hospeda las horas de oficina cada semana](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talk-with-other-devs). Una vez que haya establecido roles de liderazgo, ¡no olvides documentar cómo la gente puede alcanzarlos! Establece un proceso claro para que alguien pueda convertirse en un mantenedor o unirse a un subcomité en su proyecto y escribirlo en su GOVERNANCE.md. @@ -94,7 +87,7 @@ Si tu proyecto está en GitHub, podés utilizar [ramas protegidas](h
Cada vez que alguien te envía un pull request, dales acceso de commit a tu proyecto. Si bien puede sonar increíblemente tonto al principio, el uso de esta estrategia te permitirá liberar el verdadero poder de GitHub. (...) Una vez que las personas tienen acceso de commit, ya no están preocupados de que su parche pudiese quedar fuera de merge... haciendo que coloquen mucho más trabajo en él.
-— @felixge, ["The Pull Request Hack"](http://felixge.de/2013/03/11/the-pull-request-hack.html) +— @felixge, ["The Pull Request Hack"](https://felixge.de/2013/03/11/the-pull-request-hack.html)
@@ -104,15 +97,15 @@ Hay tres estructuras de gobierno comunes asociadas a los proyectos de cód * **BDFL:** BDFL significa "Benevolent Dictator for Life" (en español, "Dictador benevolente para la vida"). Bajo esta estructura, una persona (generalmente el autor inicial del proyecto) tiene la palabra final en todas las decisiones importantes del proyecto. [Python](https://github.com/python) es un ejemplo clásico. Los proyectos más pequeños son probablemente BDFL por defecto, porque sólo hay uno o dos mantenedores. Un proyecto que se originó en una empresa también podría caer en la categoría BDFL. -* **Meritocracia:** **(Nota: el término "meritocracia" tiene connotaciones negativas para algunas comunidades y tiene un [historia social y político compleja](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Bajo una meritocracia, a los contribuyentes activos del proyecto (Aquellos que demuestran "mérito") se les da un papel formal de toma de decisiones. Las decisiones se toman generalmente en base a un consenso de voto puro. El concepto de meritocracia fue iniciado por la [Fundación Apache](http://www.apache.org/); [Todos los proyectos de Apache](http://www.apache.org/index.html#projects-list) son meritocracias. Las contribuciones sólo pueden ser hechas por individuos que representan a sí mismos, no por una empresa. +* **Meritocracia:** **(Nota: el término "meritocracia" tiene connotaciones negativas para algunas comunidades y tiene un [historia social y político compleja](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Bajo una meritocracia, a los contribuyentes activos del proyecto (Aquellos que demuestran "mérito") se les da un papel formal de toma de decisiones. Las decisiones se toman generalmente en base a un consenso de voto puro. El concepto de meritocracia fue iniciado por la [Fundación Apache](https://www.apache.org/); [Todos los proyectos de Apache](https://www.apache.org/index.html#projects-list) son meritocracias. Las contribuciones sólo pueden ser hechas por individuos que representan a sí mismos, no por una empresa. -* **Contribución liberal:** Bajo un modelo de contribución liberal, las personas que hacen más trabajo son reconocidas como las más influyentes, pero esto se basa en el trabajo actual y no en contribuciones históricas. Las decisiones importantes del proyecto se toman sobre la base de un proceso de búsqueda de consenso (discutir quejas mayores) en lugar de voto puro, y tratar de incluir tantas perspectivas de la comunidad como sea posible. Ejemplos populares de proyectos que utilizan un modelo de contribución liberal incluyen [Node.js](https://nodejs.org/en/foundation/) y [Rust](https://www.rust-lang.org/en-US/). +* **Contribución liberal:** Bajo un modelo de contribución liberal, las personas que hacen más trabajo son reconocidas como las más influyentes, pero esto se basa en el trabajo actual y no en contribuciones históricas. Las decisiones importantes del proyecto se toman sobre la base de un proceso de búsqueda de consenso (discutir quejas mayores) en lugar de voto puro, y tratar de incluir tantas perspectivas de la comunidad como sea posible. Ejemplos populares de proyectos que utilizan un modelo de contribución liberal incluyen [Node.js](https://foundation.nodejs.org/) y [Rust](https://www.rust-lang.org/). ¿Cuál deberías usar? ¡Tú decides! Cada modelo tiene ventajas y compensaciones. Y aunque pueden parecer muy diferentes al principio, los tres modelos tienen más en común de lo que parece. Si estás interesado en adoptar uno de estos modelos, consulta estas plantillas: * [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) * [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) -* [Node.js's liberal contribution policy](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951#.m9ht26e79) +* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) ## ¿Necesito documentación de gobierno cuando lanzo mi proyecto? @@ -124,7 +117,7 @@ Si usted es parte de una empresa lanzando un proyecto de código abierto, @@ -73,7 +65,7 @@ Por otro lado, si cualquiera de las licencias de tus dependencias son copyleft " Deberías considerar también a las **comunidades** qué esperas que usaran y contribuirán a tu proyecto: -* **¿Quieres que tu proyecto sea usado como dependencia por otros proyectos?** Probablemente, la mejor opción sea usar la licencia más popular en tu comunidad. Por ejemplo, [MIT](https://choosealicense.com/licenses/mit/) es la licencia más popular para [npm libraries](https://libraries.io/npm). +* **¿Quieres que tu proyecto sea usado como dependencia por otros proyectos?** Probablemente, la mejor opción sea usar la licencia más popular en tu comunidad. Por ejemplo, [MIT](https://choosealicense.com/licenses/mit/) es la licencia más popular para [npm libraries](https://libraries.io/search?platforms=NPM). * **¿Quieres que tu proyecto atraiga a grandes empresas?** Una gran empresa seguramente querrá una licencia de patente expresa por parte de todos los contribuyentes. En este caso, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) te tiene a ti (y a ellos) cubiertos. * **¿Quieres que tu proyecto atraiga a colaboradores los cuales no quieren que sus contribuciones sean usado en software de código cerrado?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) o (si tampoco quieren contribuir a servicios de código cerrado) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) Seria el más apropiado. @@ -97,7 +89,7 @@ De manera alternativa, puedes tener colaboradores que estén de acuerdo po ## ¿Necesita mi proyecto un acuerdo adicional de colaboradores? -Probablemente no. En la mayoría de los proyectos de código abierto, una licencia de código abierto sirve implícitamente de licencia tanto para el interior (colaboradores) como para el exterior (a otros colaboradores y usuarios). Si tu proyecto se encuentra en GitHub, los Términos de Servicio de GitHub al hacen "entrante=saliente" la [explícita por defecto](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license). +Probablemente no. En la mayoría de los proyectos de código abierto, una licencia de código abierto sirve implícitamente de licencia tanto para el interior (colaboradores) como para el exterior (a otros colaboradores y usuarios). Si tu proyecto se encuentra en GitHub, los Términos de Servicio de GitHub al hacen "entrante=saliente" la [explícita por defecto](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license). Un acuerdo adicional de colaboradores – a menudo llamado Acuerdo de Licencia de colaboradores (en inglés, CLA) – puede crear trabajo administrativo para mantenedores de proyecto. La cantidad de trabajo que suma un acuerdo depende del proyecto y su implementación. Un acuerdo simple puede requerir que los colaboradores confirmen, con un click, que tienen los derechos necesarios para contribuir bajo la licencia de condigo abierto del proyecto. Un acuerdo más complicado, requerirá revisión legal y la aprobación de los empleadores del contribuyente. @@ -159,7 +151,7 @@ A largo plazo, tu equipo legal puede hacer más para ayudar a la empresa a * **Qué liberar:** [¿(casi) todo?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Si tu equipo legal entiende e invierte en la estrategia de código abierto de su empresa, serán más capaces de ayudar en lugar de dificultar tus esfuerzos. -* **Conformidad:** Incluso si tu empresa no libera ningún proyecto de código abierto, utiliza otro software de código abierto. La [conciencia y el proceso](https://www.linux.com/blog/why-companies-use-open-source-need-compliance-program) puede prevenir dolores de cabeza, retrasos del producto, y demandas. +* **Conformidad:** Incluso si tu empresa no libera ningún proyecto de código abierto, utiliza otro software de código abierto. La [conciencia y el proceso](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) puede prevenir dolores de cabeza, retrasos del producto, y demandas. -[Hay muchas razones](http://ben.balter.com/2015/11/23/why-open-source/) por las cuales una persona u organización querrían involucrarse en un proyecto de código abierto. Algunos ejemplos son: +[Hay muchas razones](https://ben.balter.com/2015/11/23/why-open-source/) por las cuales una persona u organización querrían involucrarse en un proyecto de código abierto. Algunos ejemplos son: * **Colaboración:** Los proyectos de código abierto pueden aceptar cambios efectuados por cualquier persona alrededor del mundo. [Exercism](https://github.com/exercism/), por ejemplo, una plataforma para ejercicios de programación con más de 350 colaboradores. -* **Adopción y remezcla:** Los proyectos de código abierto puedne ser usados por cualquiera para casi cualquier própósito. Las personas pueden usarlos hasta para construir otras cosas. [WordPress](https://github.com/WordPress), por ejemplo, comenzaron como un "fork" de un proyecto existente llamado [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md). +* **Adopción y remezcla:** Los proyectos de código abierto puedne ser usados por cualquiera para casi cualquier própósito. Las personas pueden usarlos hasta para construir otras cosas. [WordPress](https://github.com/WordPress), por ejemplo, comenzaron como un "fork" de un proyecto existente llamado [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md). * **Transparencia:** Cualquiera puede inspeccionar un proyecto de este tipo, ya sea para encontrar errores como inconsistencias. La transparencia es de importancia para gobiernos como el de [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) o [United States](https://sourcecode.cio.gov/), para industrias reguladas como la bancaria o la del cuidado de la salud, y para la seguridad del software como [Let's Encrypt](https://github.com/letsencrypt). @@ -83,9 +77,9 @@ Si tu único objetivo es mostrar al mundo tu trabajo, quizás no nec @@ -101,7 +95,7 @@ Si necesitas un presupuesto dedicado o personal para la promoción, operac
A medida que abres el código de tu proyecto, es importante que puedas asegurarte de que los procesos de administración tengan en cuenta a las contribuciones y a las habilidades de la comunidad alrededor de tu proyecto. No hay que asustarse al involucrar contribuyentes, que no estén empleados en tu empresa, en aspectos claves del proyecto (especialmente si son contribuyentes frecuentes).
-— @captainsafia, ["So you wanna open source a project, eh?"](https://writing.safia.rocks/2016/12/06/so-you-wanna-open-source-a-project-eh/) +— @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
@@ -156,10 +150,10 @@ Trata de que tu README responda a las siguientes preguntas: Puedes usarlo para responder otras preguntas: cómo manejo las contribuciones, cuáles son las metas del proyecto, e información acerca de licencias y atribuciones. Si no quieres aceptar contribuciones, o tu proyecto no está listo para producción, lo escribes. @@ -185,7 +179,7 @@ Además de detalles técnicos, este archivo es una oportunidad para Usando un tono cálido y amigable, y ofreciendo sugerencias específicas para contribuciones puede ayudar a los iniciados a sentirse bienvenidos y ansiosos de participar. -Por ejemplo, [Active Admin](https://github.com/activeadmin/activeadmin/) comienza [su guía de contribuciones](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) con: +Por ejemplo, [Active Admin](https://github.com/activeadmin/activeadmin/) comienza [su guía de contribuciones](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) con: > Primero, muchas gracias por considerar contribuir a Active Admin. Son personas como ustedes las que la hacen una gran herramienta. @@ -193,7 +187,7 @@ En las primeras etapas del proyecto, tu archivo CONTRIBUITNG puede ser simple. S Con el tiempo, quizás debas agregar otras "preguntas frecuentes" a tu archivo. Escribir ésta información significa que menos personas te preguntarán nuevamente la misma pregunta. -Para más información sobre este tema, puedes acceder a @nayafia's [contributing guide template](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) o @mozilla's ["How to Build a CONTRIBUTING.md"](http://mozillascience.github.io/working-open-workshop/contributing/). +Para más información sobre este tema, puedes acceder a @nayafia's [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) o @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/). Vincula tu CONTRIBUTING desde tu README, así más personas pueden verlo.Si tu [colocas el archivo en tu repositorio](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub automáticamente lo vinculará cuando un contribuyente cree un issue o abra un pull request. @@ -205,7 +199,7 @@ Vincula tu CONTRIBUTING desde tu README, así más personas pueden v
Todos hemos experimentado cierta sensación de abuso cuando nos han tratado de explicar por qué algo tiene que ser de determinada forma, o como usuarios al hacer una pregunta simple. (...) Un código de conducta se vuelve una forma sencilla (referenciable y vinculable) de documento que nos indica que un equipo toma las críticas constructivas seriamente.
-— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f#.v4qhl7t7v) +— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
@@ -215,7 +209,7 @@ Para más información, entra a [Guía del Código de Co Además de comunicar _cómo_ esperas que se comporten los participantes, un código de conducta tiende a describir a quién se aplican las expectativas, cuando apliquen, y qué hacer si una violación a las mismas ocurre. -Como muchas licencias de código abierto, existen estándares emergentes para códigos de conducta para que no debas escribir uno propio. El [Contributor Covenant](http://contributor-covenant.org/) es un código de conducta usado por [más de 40000 proyectos de código abierto](http://contributor-covenant.org/adopters/), incluyendo Kubernetes, Rails, and Swift. Debes estar preparado para redefinir el tuyo cuando sea necesario. +Como muchas licencias de código abierto, existen estándares emergentes para códigos de conducta para que no debas escribir uno propio. El [Contributor Covenant](https://www.contributor-covenant.org/) es un código de conducta usado por [más de 40000 proyectos de código abierto](https://www.contributor-covenant.org/adopters), incluyendo Kubernetes, Rails, and Swift. Debes estar preparado para redefinir el tuyo cuando sea necesario. Copia el texto directamente en el archivo CODE_OF_CONDUCT dentro de tu repositorio, en el directorio raíz, y vinculalo desde tu README. @@ -256,13 +250,13 @@ Ya sea documentación oficial como casual (un email), tu estilo de redacci
He tratado de involucrarme con cada hilo del listado de emails, y mostrando un comportamiento ejemplar, siendo agradable con las personas, tomando sus issues seriamente y tratando de ser de ayuda por sobre todo. Después de un tiempo las personas no solo me buscaban para hacerme preguntas si no para ayudarme a responderlas, y, para mi sorpresa, imitaban mi estilo.
-— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](http://writing.jan.io/2015/11/20/sustainable-open-source.html) +— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
Usando un lenguaje inclusivo, puede ir lejos haciendo que tus proyectos reciban de forma más cálida a los nuevos participantes. Mantén un lenguaje simple. -Luego de cómo expresarte, tu estilo a la hora de codificar puede ser importante también. [Angular](https://github.com/johnpapa/angular-styleguide) y [jQuery](http://contribute.jquery.org/style-guide/js/) son ejemplos de proyectos con un riguroso trato en este sentido. +Luego de cómo expresarte, tu estilo a la hora de codificar puede ser importante también. [Angular](https://github.com/johnpapa/angular-styleguide) y [jQuery](https://contribute.jquery.org/style-guide/js/) son ejemplos de proyectos con un riguroso trato en este sentido. No es necesario escribir una "guía de estilo" para tus proyectos cuando recién estás comenzando, y quizás hasta descubras que disfrutas al incorporar distintos estilos de codificación en tu proyecto. Pero deberías anticiparte y definir cómo tu redacción y estilo de codificación puede atraer o no a distintos tipos de personas. Define esto al comienzo. diff --git a/_articles/finding-users.md b/_articles/finding-users.md index b52ff2e9d8edb7863da55369d7b12bdf96923f43..84ec4c6e7caf1fa111e9bc92932c9cae116a31a7 100644 --- a/_articles/finding-users.md +++ b/_articles/finding-users.md @@ -78,7 +78,7 @@ Take advantage of existing online communities and platforms to reach your audien
Each program has very specific functions that only a fraction of users will find useful. Don't spam as many people as possible. Instead, target your efforts to communities that will benefit from knowing about your project.
-— @pazdera, ["Marketing for open source projects"](http://radek.io/2015/09/28/marketing-for-open-source-projects-3/) +— @pazdera, ["Marketing for open source projects"](https://radek.io/2015/09/28/marketing-for-open-source-projects-3/)
@@ -98,7 +98,7 @@ If nobody pays attention or responds to your initial outreach, don't get discour Offline events are a popular way to promote new projects to audiences. They're a great way to reach an engaged audience and build deeper human connections, especially if you are interested in reaching developers. -If you're [new to public speaking](http://speaking.io/), start by finding a local meetup that's related to the language or ecosystem of your project. +If you're [new to public speaking](https://speaking.io/), start by finding a local meetup that's related to the language or ecosystem of your project. diff --git a/_articles/fr/best-practices.md b/_articles/fr/best-practices.md new file mode 100644 index 0000000000000000000000000000000000000000..3e5e4c64eae75680a83b1f5cbced824d24da9916 --- /dev/null +++ b/_articles/fr/best-practices.md @@ -0,0 +1,276 @@ +--- +lang: fr +title: Bonnes Pratiques pour les Responsables +description: Facilitez vous la vie en tant que responsable open source, de la documentation des processus à l'exploitation de votre communauté. +class: best-practices +order: 5 +image: /assets/images/cards/best-practices.png +related: + - metrics + - leadership +--- + +## Que signifie être un responsable + +Si vous gérez un projet Open Source que beaucoup de personnes utilisent, vous avez peut-être remarqué que vous codez moins et que vous répondez à d'autres problèmes. + +Au début d'un projet, vous expérimentez de nouvelles idées et prenez des décisions en fonction de ce que vous voulez. Au fur et à mesure que votre projet gagne en popularité, vous travaillerez de plus en plus avec vos utilisateurs et vos contributeurs. + +Maintenir un projet nécessite plus que du code. Ces tâches sont souvent inattendues, mais elles sont tout aussi importantes pour un projet en croissance. Nous avons rassemblé quelques moyens pour vous faciliter la vie, de la documentation des processus à l'exploitation de votre communauté. + +## Documentez vos processus + +Écrire des choses est l'une des choses les plus importantes que vous pouvez faire en tant que responsable. + +La documentation clarifie non seulement votre propre pensée, mais elle aide les autres à comprendre ce dont vous avez besoin ou ce que vous attendez, avant même de le demander. + +Rédaction des choses rend plus facile de dire non quand quelque chose ne rentre pas dans votre champ d'application. Cela facilite également la tâche des gens. Vous ne savez jamais qui pourrait lire ou utiliser votre projet. + +Même si vous n'utilisez pas de paragraphes entiers, des listes de point sont mieux que de ne pas écrire du tout. + +N'oubliez pas de garder votre documentation à jour. Si vous n'êtes pas toujours en mesure le faire, supprimez votre documentation obsolète ou indiquez qu'elle est obsolète afin que les contributeurs sachent que les mises à jour sont les bienvenues. + +### Décrivez la vision de votre projet + +Commencez par écrire les objectifs de votre projet. Ajoutez-les à votre fichier README ou créez un fichier distinct appelé VISION. S'il y a d'autres artefacts qui pourraient aider, comme une feuille de route de projet, laissez-les publics aussi. + +Avoir une vision claire et documentée vous permet de rester concentré et vous aide à éviter le «glissement de portée» des contributions des autres. + +Par exemple, @lord a découvert que le fait d'avoir une vision de projet l'aidait à déterminer les demandes pour lesquelles il devait passer du temps. En tant que nouveau responsable, il a regretté de ne pas s'en tenir à la portée de son projet quand il a obtenu sa première demande de fonctionnalité pour [Slate](https://github.com/lord/slate). + + + +### Communiquez vos attentes + +Les règles peuvent être angoissantes à écrire. Parfois, vous pourriez avoir l'impression de surveiller le comportement des autres ou de tuer tout le plaisir. + +Écrit et appliqué équitablement, cependant, de bonnes règles habilitent les responsables. Ils vous empêchent d'être entraînés à faire des choses que vous ne voulez pas faire. + +La plupart des personnes qui rencontrent votre projet ne savent rien de vous ou de votre situation. Ils peuvent supposer que vous êtes payé pour travailler dessus, surtout si c'est quelque chose qu'ils utilisent régulièrement et dont ils dépendent. Peut-être qu'à un moment donné, vous avez consacré beaucoup de temps à votre projet, mais maintenant vous êtes occupé avec un nouvel emploi ou un membre de votre famille. + +Tout cela est parfaitement correct ! Assurez-vous simplement que les autres personnes le savent. + +Si le maintien de votre projet est à temps partiel ou purement volontaire, soyez honnête quant au temps dont vous disposez. Ce n'est pas la même chose que le temps que vous estimez nécessaire au projet ou combien de temps les autres vous demandent. + +Voici quelques règles qui méritent d'être notées : + +* Comment une contribution est-elle examinée et acceptée (_A-t-elle besoin de tests ? Un modèle de question ?_) +* Les types de contributions que vous acceptez (_Vous voulez seulement de l'aide pour une partie de votre code ?_) +* Lorsqu'il est approprié de faire un suivi (_par exemple, "Vous pouvez vous attendre à recevoir une réponse d'un responsable dans les 7 jours. Dès lors Si vous n'avez pas encore de retour, n'hésitez pas à faire un ping."_) +* Combien de temps vous consacrez au projet (_par exemple, "Nous ne consacrons que 5 heures par semaine à ce projet"_) + +[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), et [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) sont plusieurs exemples de projets avec des règles de base pour les responsables et les contributeurs. + +### Maintenez la communication publique + +N'oubliez pas de documenter vos interactions, aussi. Partout où vous pouvez, gardez la communication sur votre projet public. Si quelqu'un tente de vous contacter en privé pour discuter d'une demande de fonctionnalité ou d'un besoin de support, dirigez-les poliment vers un canal de communication public, tel qu'une liste de diffusion ou un outil de suivi des problèmes. + +Si vous rencontrez d'autres responsables, ou prenez une décision importante en privé, documentez ces conversations en public, même si cela ne concerne que la publication de vos notes. + +De cette façon, toute personne qui rejoint votre communauté aura accès à la même information que quelqu'un qui a été là pendant des années. + +## Apprendre à dire non + +Vous avez écrit des choses. Idéalement, tout le monde lira votre documentation, mais en réalité, vous devrez rappeler aux autres que cette connaissance existe. + +Cependant, tout noter contribue à dépersonnaliser les situations lorsque vous devez appliquer vos règles. + +Dire non n'est pas amusant, mais _"Votre contribution ne correspond pas aux critères de ce projet"_ est moins personnelle que _"Je n'aime pas votre contribution"_. + +Dire non s'applique à de nombreuses situations que vous rencontrerez en tant que responsable : des demandes de fonctionnalités qui ne correspondent pas à la portée, quelqu'un qui déraille dans une discussion, qui fait un travail inutile pour les autres. + +### Gardez la conversation amicale + +L'un des endroits les plus importants que vous pratiquez en disant non est sur votre isue et la file d'attente des pull requests. En tant que responsable du projet, vous recevrez inévitablement des suggestions que vous ne souhaitez pas accepter. + +Peut-être que la contribution modifie la portée de votre projet ou ne correspond pas à votre vision. Peut-être que l'idée est bonne, mais la mise en œuvre est mauvaise. + +Peu importe la raison, il est possible de gérer avec tact les contributions qui ne répondent pas aux normes de votre projet. + +Si vous recevez une contribution que vous ne voulez pas accepter, votre première réaction pourrait être de l'ignorer ou de prétendre que vous ne l'avez pas vue. Cela pourrait nuire aux sentiments de l'autre et même démotiver d'autres contributeurs potentiels dans votre communauté. + + + +Ne laissez pas une contribution indésirable ouverte parce que vous avez un sentiment de culpabilité ou que vous voulez être gentil. Au fil du temps, vos issues sans réponse et les PRs rendront le travail sur votre projet beaucoup plus stressant et intimidant. + +Il est préférable de fermer immédiatement les contributions que vous ne voulez pas accepter. Si votre projet souffre déjà d'un important retard, @steveklabnik propose des suggestions pour [comment trier efficacement les issues](https://words.steveklabnik.com/how-to-be-an-open-source-gardener). + +Deuxièmement, ignorer les contributions envoie un signal négatif à votre communauté. Contribuer à un projet peut être intimidant, surtout s'il s'agit de la première fois. Même si vous n'acceptez pas leur contribution, remerciez la personne derrière et remerciez-la de son intérêt. C'est un gros compliment! + +Si vous ne voulez pas accepter une contribution: + +* **Remercier la** pour sa contribution +* **Expliquez pourquoi cela ne rentre pas** dans la portée du projet et proposez des suggestions d'amélioration claires, si vous le pouvez. Soyez gentil, mais ferme. +* **Lien vers la documentation pertinente**, si vous l'avez. Si vous remarquez des demandes répétées pour des choses que vous ne voulez pas accepter, ajoutez-les dans votre documentation pour éviter de vous répéter. +* **Fermez la demande** + +Vous ne devriez pas avoir besoin de plus de 1-2 phrases pour répondre. Par exemple, lorsqu'un utilisateur de [celery](https://github.com/celery/celery/) a signalé une erreur liée à Windows, @berkerpeksag [a répondu ainsi](https://github.com/celery/celery/issues/3383): + + + +Si la pensée de dire non vous terrifie, vous n'êtes pas seul. Comme @jessfraz [le met](https://blog.jessfraz.com/post/the-art-of-closing/): + +> J'ai parlé à des responsables de plusieurs projets open source différents, Mesos, Kubernetes, Chromium, et ils sont tous d'accord que l'un des aspects les plus difficiles d'un responsable est de dire "Non" aux correctifs que vous ne voulez pas. + +Ne vous sentez pas coupable de ne pas vouloir accepter la contribution de quelqu'un. La première règle de l'open source, [selon](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"Non est temporaire, oui est pour toujours."_. Alors que l'empathie avec l'enthousiasme d'une autre personne est une bonne chose, rejeter une contribution n'est pas la même chose que rejeter la personne derrière elle. + +En fin de compte, si une contribution n'est pas suffisante, vous n'êtes pas obligé de l'accepter. Soyez gentil et réactif lorsque les gens contribuent à votre projet, mais n'acceptez que les changements qui, selon vous, amélioreront votre projet. Le plus souvent vous pratiquez en disant non, plus cela devient facile. Promis. + +### Soyez pro-actif + +Pour réduire le volume des contributions non désirées, expliquez le processus de soumission et d'acceptation des contributions de votre projet dans votre guide. + +Si vous recevez trop de contributions de faible qualité, demandez aux contributeurs de faire un peu de travail à l'avance, par exemple: + +* Remplir une issue ou un modèle de PR / checklist +* Ouvrir une issue avant de soumettre une PR + +S'ils ne respectent pas vos règles, fermez immédiatement l'issue et référez a votre documentation. + +Bien que cette approche puisse sembler méchante au début, être proactif est réellement bon pour les deux parties. Cela réduit le risque que quelqu'un consacre beaucoup d'heures de travail perdues à une pull request que vous n'allez pas accepter. Et cela rend votre charge de travail plus facile à gérer. + + + +Parfois, quand vous dites non, votre contributeur potentiel peut se fâcher ou critiquer votre décision. Si leur comportement devient hostile, [prenez des mesures pour désamorcer la situation](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) ou même supprimez-le de votre communauté s'il ne souhaite pas collaborer de manière constructive. + +### Embrasser le mentorat + +Peut-être que quelqu'un dans votre communauté soumet régulièrement des contributions qui ne répondent pas aux normes de votre projet. Il peut être frustrant pour les deux parties de passer à plusieurs reprises par des rejets. + +Si vous voyez que quelqu'un est enthousiaste à propos de votre projet, mais qu'il a besoin d'un peu de polish, soyez patient. Expliquer clairement dans chaque situation pourquoi les contributions ne répondent pas aux attentes du projet. Essayez de le diriger vers une tâche plus facile ou moins ambiguë, comme une question marquée _"bonne premiere issue"_, pour se faire les pieds. Si vous avez le temps, envisagez de l'encadrer à travers sa première contribution, ou de trouver quelqu'un d'autre dans votre communauté qui pourrait être disposé à le faire. + +## Tirez parti de votre communauté + +Vous n'avez pas à tout faire vous-même. La communauté de votre projet existe pour une raison ! Même si vous n'avez pas encore de communauté de contributeurs actifs, si vous avez beaucoup d'utilisateurs, mettez-les au travail. + +### Partager la charge de travail + +Si vous cherchez d'autres personnes, commencez par demander. + +Lorsque vous voyez de nouveaux contributeurs faire des contributions répétées, reconnaissez leur travail en offrant plus de responsabilités. Documentez comment les autres peuvent devenir des leaders s'ils le souhaitent. + +Encourager les autres à [partager la propriété du projet](../building-community/#partager-la-propriété-de-votre-projet) peut réduire considérablement votre charge de travail, comme l'a découvert @lmccart sur son projet, [p5.js](https://github.com/processing/p5.js). + + + +Si vous avez besoin de quitter votre projet, que ce soit en pause ou en permanence, il n'y a pas de honte à demander à quelqu'un d'autre de vous remplacer. + +Si d'autres personnes sont enthousiastes à l'égard de sa direction, donnez-leur l'autorisation de s'engager ou remettez officiellement le contrôle à quelqu'un d'autre. Si quelqu'un a forké votre projet et le maintient activement ailleurs, envisagez de créer un lien vers le fork de votre projet d'origine. C'est génial que tant de gens veulent que votre projet continue à vivre ! + +@progrium [a trouvé que](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) documentant la vision de son projet, [Dokku](https://github.com/dokku/dokku), a aidé à atteindre ces objectifs même après s'être retiré du projet: + +> J'ai écrit une page wiki décrivant ce que je voulais et pourquoi je le voulais. Pour une raison ou une autre, j'ai été surpris de constater que les responsables ont commencé à faire avancer le projet dans cette direction ! Est-ce arrivé exactement comment je le ferais ? Pas toujours. Mais cela rapprochait encore le projet de ce que j'avais écrit. + +### Laissez les autres construire les solutions dont ils ont besoin + +Si un contributeur potentiel a une opinion différente sur ce que votre projet devrait faire, vous pouvez l'encourager doucement à travailler sur son propre fork. + +Forker un projet ne doit pas être une mauvaise chose. Etre capable de copier et de modifier des projets est l'une des meilleures choses à propos de l'open source. Encourager les membres de votre communauté à travailler sur leur propre fork peut fournir le débouché créatif dont ils ont besoin, sans entrer en conflit avec la vision de votre projet. + + + +La même chose s'applique à un utilisateur qui veut vraiment une solution que vous n'avez tout simplement pas la bande passante pour la faire. L'offre d'API et de hooks de personnalisation peut aider les autres à répondre à leurs propres besoins, sans avoir à modifier directement la source. @orta [a trouvé que](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) encourager les plugins pour CocoaPods a conduit à "quelques-unes des idées les plus intéressantes": + +> Il est presque inévitable qu'une fois qu'un projet prend de l'ampleur, les responsables doivent être beaucoup plus conservateurs quant à la façon dont ils introduisent un nouveau code. Vous devenez bon à dire «non», mais beaucoup de gens ont des besoins légitimes. Ainsi, vous finissez par convertir votre outil en plate-forme. + +## Donnez le aux robots + +Tout comme il existe des tâches que d'autres personnes peuvent vous aider, il y a aussi des tâches que personne ne devrait jamais avoir à faire. Les robots sont vos amis. Utilisez-les pour rendre votre vie de responsable plus facile. + +### Exiger des tests et autres vérifications pour améliorer la qualité de votre code + +L'un des moyens les plus importants pour automatiser votre projet consiste à ajouter des tests. + +Les tests aident les contributeurs à croire qu'ils ne casseront rien. Ils facilitent également la consultation et l'acceptation des contributions rapidement. Plus vous êtes réactif, plus votre communauté peut être engagée. + +Configurez des tests automatiques qui s'exécuteront sur toutes les contributions entrantes, et assurez-vous que vos tests peuvent être facilement exécutés localement par les contributeurs. Exiger que toutes les contributions de code passent vos tests avant de pouvoir être soumis. Vous aiderez à définir une norme de qualité minimale pour toutes les soumissions. La [vérifications du status requis](https://help.github.com/articles/about-required-status-checks/) sur GitHub peut vous aider à vous assurer qu'aucune modification ne sera mergée sans que vos tests ne passent. + +Si vous ajoutez des tests, assurez-vous d'expliquer comment ils fonctionnent dans votre fichier CONTRIBUTING. + + + +### Utiliser des outils pour automatiser les tâches de maintenance de base + +Les bonnes nouvelles à propos du maintien d'un projet populaire sont que d'autres responsables ont probablement deja fait face à des problèmes similaires et ont construit une solution pour cela. + +Il y a une [variété d'outils disponibles](https://github.com/showcases/tools-for-open-source) pour aider à automatiser certains aspects du travail de maintenance. Quelques exemples: + +* [semantic-release](https://github.com/semantic-release/semantic-release) automatise vos releases +* [mention-bot](https://github.com/facebook/mention-bot) mentionne les reviewers potentiels pour les pull requests +* [Danger](https://github.com/danger/danger) permet d'automatiser les revues de code + +Pour les rapports de bogues et autres contributions communes, GitHub a des [Modèles d'issues et modèles de pull requests](https://github.com/blog/2111-issue-and-pull-request-templates), que vous pouvez créer pour rationaliser la communication que vous recevez. @TalAter a fait un guide [Choisissez Votre Propre Aventure] (https://www.talater.com/open-source-templates/#/) pour vous aider à rédiger vos issues et vos modèles de PR. + +Pour gérer vos notifications par e-mail, vous pouvez configurer [des filtres e-mail](https://github.com/blog/2203-email-updates-about-your-own-activity) pour organiser par priorité. + +Si vous souhaitez être un peu plus avancé, les guides de style et les linters peuvent standardiser les contributions de projet et les rendre plus faciles à consulter et à accepter. + +Cependant, si vos normes sont trop compliquées, elles peuvent augmenter les obstacles à la contribution. Assurez-vous d'ajouter suffisamment de règles pour faciliter la vie de tous. + +Si vous n'êtes pas sûr des outils à utiliser, regardez ce que font les autres projets populaires, en particulier ceux de votre écosystème. Par exemple, à quoi ressemble le processus de contribution pour les autres modules Node ? L'utilisation d'outils et d'approches similaires rendra votre processus plus familier à vos contributeurs cibles. + +## Il est normal de faire pause + +Le travail open source vous a déjà apporté de la joie. Peut-être que maintenant ça commence à vous faire sentir fuyant ou coupable. + +Peut-être vous sentez-vous débordé ou un sentiment croissant d'effroi quand vous pensez à vos projets. Et pendant ce temps, les issues et les pull requests s'accumulent. + +Le burnout est un problème réel et omniprésent dans le travail open source, en particulier chez les responsables. En tant que responsable, votre bonheur est une exigence non négociable pour la survie de tout projet open source. + +Bien que cela devrait aller de soi, faites une pause ! Vous ne devriez pas avoir à attendre de vous sentir usé pour prendre des vacances. @brettcannon, un développeur de base Python, a décidé de prendre [un mois de vacances](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) après 14 années de bénévolat de travail sur les logiciels open source. + +Tout comme n'importe quel autre type de travail, prendre des pauses régulières vous gardera frais, heureux et excité par votre travail. + + + +Parfois, il peut être difficile de faire une pause dans le travail open source quand on a l'impression que tout le monde a besoin de vous. Les gens peuvent même essayer de vous faire sentir coupable d'avoir abandonné. + +Faites de votre mieux pour trouver du support pour vos utilisateurs et votre communauté pendant votre absence sur un projet. Si vous ne trouvez pas le soutien dont vous avez besoin, faites une pause quand même. Assurez-vous de communiquer lorsque vous n'êtes pas disponible, afin que les gens ne soient pas perturbés par votre manque de réactivité. + +Prendre des pauses s'applique à plus que de simples vacances, aussi. Si vous ne voulez pas faire du travail open source le week-end, ou pendant les heures de travail, communiquez ces attentes aux autres, afin qu'ils sachent ne pas vous déranger. + +## Prennez soin de vous d'abord ! + +Maintenir un projet populaire nécessite des compétences différentes des étapes précédentes de la croissance, mais ce n'est pas moins gratifiant. En tant que responsable, vous pratiquerez le leadership et les compétences personnelles à un niveau que peu de gens connaissent. Bien que ce ne soit pas toujours facile à gérer, définir des limites claires et ne prendre que ce que vous êtes à l'aise vous aidera à rester heureux, frais et productif. diff --git a/_articles/fr/building-community.md b/_articles/fr/building-community.md new file mode 100644 index 0000000000000000000000000000000000000000..929419b9e3b40c976f5708da85c3eac492af4f65 --- /dev/null +++ b/_articles/fr/building-community.md @@ -0,0 +1,275 @@ +--- +lang: fr +title: Construire des communautés accueillantes +description: Construire une communauté qui encourage les gens à utiliser, contribuer et évangéliser votre projet. +class: building +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +--- + +## Mise en place de votre projet pour le succès + +Vous avez lancé votre projet, vous passez le mot, et les gens le vérifient. Impressionnant ! Maintenant, comment les faites-vous rester ? + +Une communauté accueillante est un investissement dans l'avenir et la réputation de votre projet. Si votre projet commence à peine à voir ses premières contributions, commencez par donner aux premiers contributeurs une expérience positive et facilitez-les pour qu'ils reviennent. + +### Faites que les gens se sentent les bienvenus + +Une façon de penser à la communauté de votre projet est ce que @MikeMcQuaid appelle l'[entonnoir du contributeur](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/): + + + +Au fur et à mesure que vous construisez votre communauté, réfléchissez à la façon dont une personne en haut de l'entonnoir (un utilisateur potentiel) pourrait théoriquement se frayer un chemin vers le bas (un responsable actif). Votre but est de réduire la friction à chaque étape de l'expérience du contributeur. Quand les gens ont des victoires faciles, ils se sentent incités à faire plus. + +Commencez avec votre documentation: + +* **Facilitez l'utilisation de votre projet par quelqu'un.** [Un fichier README amical](../starting-a-project/#ecrire-un-fichier-readme) et des exemples de code clair faciliteront la tâche à tous ceux qui atterriront votre projet pour commencer. +* **Expliquez clairement comment contribuer**, en utilisant [votre fichier CONTRIBUTING](../starting-a-project/#rédaction-de-vos-directives-de-contribution) et en gardant vos issues à jour. + +[L'enquête open source 2017 de GitHub](http://opensourcesurvey.org/2017/) a montrée que la documentation incomplète ou confuse est le plus gros problème pour les utilisateurs open source. Une bonne documentation invite les gens à interagir avec votre projet. Finalement, quelqu'un va ouvrir une issue ou faire une pull request. Utilisez ces interactions comme des opportunités pour les déplacer dans l'entonnoir. + +* **Quand quelqu'un arrive sur votre projet, remerciez-le de son intérêt !** Il suffit d'une expérience négative pour que quelqu'un ne veuille pas revenir. +* **Soyez réactif.** Si vous ne répondez pas à leur problème pendant un mois, les chances sont, ils ont déjà oublié votre projet. +* **Soyez ouvert sur les types de contributions que vous accepterez.** De nombreux contributeurs commencent par un rapport de bug ou une petite correction. Il y a [plusieurs façons de contribuer](../how-to-contribute/#que-signifie-contribuer) à un projet. Laissez les gens aider comment ils veulent aider. +* **S'il y a une contribution avec laquelle vous n'êtes pas d'accord,** remerciez-les pour leur idée et [expliquez pourquoi](../best-practices/#apprendre-à-dire-non) cela ne rentre pas dans le cadre de la projet, en reliant à la documentation pertinente si vous l'avez. + + + +La majorité des contributeurs open source sont des "contributeurs occasionnels": des personnes qui contribuent à un projet uniquement à l'occasion. Un contributeur occasionnel n'a peut-être pas le temps de se familiariser avec votre projet, alors votre travail consiste à rendre la contribution plus facile. + +Encourager les autres contributeurs est un investissement en vous aussi. Lorsque vous permettez à vos plus grands fans de courir avec le travail qui les intéresse, il y a moins de pression pour tout faire vous-même. + +### Documentez tout + + + +Lorsque vous démarrez un nouveau projet, il peut sembler naturel de garder votre travail privé. Mais les projets Open Source prospèrent lorsque vous documentez votre processus en public. + +Quand vous écrivez les choses, plus de gens peuvent participer à chaque étape du chemin. Vous pourriez obtenir de l'aide sur quelque chose dont vous ne saviez même pas que vous en aviez besoin. + +Ecrire des choses signifie plus que de la documentation technique. Chaque fois que vous ressentez le besoin d'écrire quelque chose ou de discuter en privé de votre projet, demandez-vous si vous pouvez le rendre public. + +Soyez transparent au sujet de la feuille de route de votre projet, des types de contributions que vous recherchez, de la façon dont les contributions sont examinées ou des raisons pour lesquelles vous avez pris certaines décisions. + +Si vous remarquez que plusieurs utilisateurs rencontrent le même problème, documentez les réponses dans le fichier README. + +Pour les réunions, pensez à publier vos notes ou vos plats à emporter dans un numéro pertinent. Les commentaires que vous obtiendrez de ce niveau de transparence pourraient vous surprendre. + +Documenter tout s'applique au travail que vous faites aussi. Si vous travaillez sur une mise à jour substantielle de votre projet, placez-la dans une pull request et marquez-la comme un travail en cours (WIP). De cette façon, d'autres personnes peuvent se sentir impliqués dans le processus dès le début. + +### Soyez réactif + +Comme vous [faites la promotion de votre projet](../finding-users), les gens auront des commentaires pour vous. Ils peuvent avoir des questions sur la façon dont les choses fonctionnent, ou ont besoin d'aide pour commencer. + +Essayez d'être réactif lorsque quelqu'un soumet une issue, une pull request ou une question à propos de votre projet. Lorsque vous répondez rapidement, les gens ont l'impression de participer à un dialogue, et ils seront plus enthousiastes à l'idée de participer. + +Même si vous ne pouvez pas examiner la demande immédiatement, le reconnaître au début permet d'augmenter l'engagement. Voici comment @tdreyno a répondu à une pull request sur [Middleman](https://github.com/middleman/middleman/pull/1466): + + + +[Une étude de Mozilla a trouvé que](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) les contributeurs qui ont reçu des avis de code dans les 48 heures avaient un taux de rendement beaucoup plus élevé et recommencaient a contriber. + +Des conversations sur votre projet pourraient également avoir lieu dans d'autres endroits sur Internet, tels que Stack Overflow, Twitter ou Reddit. Vous pouvez configurer des notifications dans certains de ces endroits afin d'être averti lorsque quelqu'un mentionne votre projet. + +### Donnez à votre communauté point de rassemblement + +Il y a deux raisons de donner à votre communauté un point de rassemblement. + +La première raison est pour eux. Aidez les gens à se connaître. Les personnes ayant des intérêts communs voudront inévitablement un endroit pour en parler. Et quand la communication est publique et accessible, n'importe qui peut lire les archives passées pour se mettre au courant et participer. + +La deuxième raison est pour vous. Si vous ne donnez pas aux gens un lieu public pour parler de votre projet, ils vous contacteront probablement directement. Au début, il peut sembler assez facile de répondre aux messages privés "juste une fois". Mais au fil du temps, surtout si votre projet devient populaire, vous serez épuisé. Résistez à la tentation de communiquer avec des personnes au sujet de votre projet en privé. Au lieu de cela, dirigez-les vers un canal public désigné. + +La communication publique peut être aussi simple que de diriger les gens à ouvrir une issue au lieu de vous envoyer directement un e-mail ou de commenter votre blog. Vous pouvez également créer une liste de diffusion ou créer un compte Twitter, Slack ou un canal IRC pour que les gens puissent parler de votre projet. Ou essayez tout ce qui précède ! + +[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) réserve des heures de bureau toutes les deux semaines pour aider les membres de la communauté: + +> Kops a également du temps mis de côté toutes les deux semaines pour offrir de l'aide et des conseils à la communauté. Les mainteneurs de Kops ont convenu de consacrer du temps spécifiquement dédié au travail avec les nouveaux arrivants, en aidant sur les PR, et en discutant de nouvelles fonctionnalités. + +Les exceptions notables à la communication publique sont: 1) les problèmes de sécurité et 2) les violations de code de conduite sensibles. Vous devriez toujours avoir un moyen pour les gens de signaler ces problèmes en privé. Si vous ne souhaitez pas utiliser votre adresse e-mail personnelle, configurez une adresse e-mail dédiée. + +## Cultiver votre communauté + +Les communautés sont extrêmement puissantes. Ce pouvoir peut être une bénédiction ou une malédiction, selon la façon dont vous l'utilisez. Au fur et à mesure que la communauté de votre projet grandit, il existe des moyens de l'aider à devenir une force de construction, pas de destruction. + +### Ne tolèrez pas les mauvais acteurs + +Tout projet populaire attirera inévitablement des gens qui nuisent à votre communauté plutôt que de l'aider. Ils peuvent lancer des débats inutiles, ergoter sur des fonctionnalités triviales, ou intimider les autres. + +Faites de votre mieux pour adopter une politique de tolérance zéro envers ces types de personnes. Si rien n'est fait, les personnes négatives mettront mal à l'aise les autres membres de votre communauté. Ils peuvent même partir. + + + +Des débats réguliers sur des aspects triviaux de votre projet distraient les autres, y compris vous, de se concentrer sur des tâches importantes. Les nouvelles personnes qui arrivent à votre projet peuvent voir ces conversations et ne veulent pas participer. + +Lorsque vous voyez un comportement négatif se produire sur votre projet, appelez-le publiquement. Expliquez, d'un ton ferme mais ferme, pourquoi leur comportement n'est pas acceptable. Si le problème persiste, vous devrez peut-être [leur demander de partir](../code-of-conduct/#appliquer-votre-code-de-conduite). Votre [code de conduite](../code-of-conduct/) peut être un guide constructif pour ces conversations. + +### Rencontrez les contributeurs là où ils sont + +Une bonne documentation devient seulement plus importante au fur et à mesure que votre communauté se développe. Les contributeurs occasionnels, qui ne connaissent peut-être pas votre projet, lisent votre documentation pour obtenir rapidement le contexte dont ils ont besoin. + +Dans votre fichier CONTRIBUTING, expliquez explicitement aux nouveaux contributeurs comment démarrer. Vous pouvez même créer une section dédiée à cet effet. [Django](https://github.com/django/django), par exemple, a une page de destination spéciale pour accueillir de nouveaux contributeurs. + + + +Dans votre liste d'issue en attente, étiquetez les bogues qui conviennent à différents types de contributeurs : par exemple, [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, ou _"documentation"_. [Ces étiquettes](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) facilitent l'analyse rapide de vos issues par une personne nouvelle dans votre projet de commencer. + +Enfin, utilisez votre documentation pour que les gens se sentent les bienvenus à chaque étape du processus. + +Vous n'interagirez jamais avec la plupart des personnes qui atterrissent sur votre projet. Il se peut que vous ayez reçu des contributions parce que quelqu'un se sentait intimidé ou ne savait pas par où commencer. Même quelques mots gentils peuvent empêcher quelqu'un de quitter votre projet avec de la frustration. + +Par exemple, voici comment [Rubinius](https://github.com/rubinius/rubinius/) commence [son guide de contribution] (https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md) : + +> Nous voulons commencer par vous dire merci d'utiliser Rubinius. Ce projet est un travail d'amour, et nous apprécions tous les utilisateurs qui détectent les bogues, améliorent les performances et aident à la documentation. Chaque contribution est significative, alors merci de votre participation. Cela étant dit, voici quelques lignes directrices que nous vous demandons de suivre afin que nous puissions résoudre votre problème avec succès. + +### Partager la propriété de votre projet + + + +Les gens sont enthousiastes à l'idée de contribuer à des projets lorsqu'ils éprouvent un sentiment d'appartenance. Cela ne signifie pas que vous devez retourner la vision de votre projet ou accepter des contributions que vous ne voulez pas. Mais plus vous donnez du crédit aux autres, plus ils resteront. + +Voyez si vous pouvez trouver le moyen de partager la propriété avec votre communauté autant que possible. Voici quelques idées: + +* **Résistez à corriger les bogues faciles (non critiques).** Utilisez-les plutôt comme des opportunités de recruter de nouveaux contributeurs, ou d'encadrer quelqu'un qui aimerait contribuer. Cela peut sembler anormal au début, mais votre investissement sera rentable au fil du temps. Par exemple, @michaeljoseph a demandé à un contributeur de soumettre une pull request sur une issue [Cookiecutter](https://github.com/audreyr/cookiecutter) ci-dessous, plutôt que de le réparer lui-même. + + + +* **Démarrez un fichier CONTRIBUTORS ou AUTHORS dans votre projet** qui répertorie tous ceux qui ont contribué à votre projet, comme [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md). + +* Si vous avez une communauté importante **, envoyez un bulletin d'information ou rédigez un article** remerciant les contributeurs. [La semaine de Rust](https://this-week-in-rust.org/) et celle de Hoodie [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) sont deux bons exemples. + +* **Donnez à chaque contributeur un droit de commit.** @felixge a trouvé que cela rendait les gens [plus excités de fignoler leurs patches](https://felixge.de/2013/03/11/the-pull-request-hack.html ), et il a même trouvé de nouveaux responsables pour des projets sur lesquels il n'avait pas travaillé depuis longtemps. + +* Si votre projet est sur GitHub, **déplacez votre projet de votre compte personnel vers un [compte Organisation](https://help.github.com/articles/creating-a-new-organization-account/)** et ajoutez au moins un administrateur de sauvegarde. Les organisations facilitent le travail sur des projets avec des collaborateurs externes. + +La réalité est que [la plupart des projets ont seulement](https://peerj.com/preprints/1233.pdf) un ou deux mainteneurs qui font la plupart du travail. Plus votre projet est important et plus votre communauté est grande, plus il est facile de trouver de l'aide. + +Même s'il se peut que vous ne trouviez pas toujours quelqu'un pour répondre à l'appel, envoyer un signal augmente les chances que d'autres personnes interviennent. Plus tôt vous commencerez, plus tôt les gens pourront vous aider. + + + +## Résoudre les conflits + +Au début de votre projet, prendre des décisions importantes est facile. Quand vous voulez faire quelque chose, vous le faites simplement. + +Au fur et à mesure que votre projet gagne en popularité, de plus en plus de gens s'intéresseront aux décisions que vous prendrez. Même si vous n'avez pas une grande communauté de contributeurs, si votre projet compte beaucoup d'utilisateurs, vous trouverez des personnes qui pèsent sur les décisions ou qui soulèvent des problèmes. + +Pour la plupart, si vous avez cultivé une communauté amicale et respectueuse et documenté vos processus ouvertement, votre communauté devrait être capable de trouver une solution. Mais parfois, vous rencontrez un problème qui est un peu plus difficile à résoudre. + +### Mettre la barre pour la gentillesse + +Lorsque votre communauté est aux prises avec un problème difficile, la colère peut monter. Les gens peuvent devenir fâchés ou frustrés et s'en prendre à un autre ou à vous. + +Votre travail en tant que mainteneur consiste à éviter l'escalade de ces situations. Même si vous avez une opinion forte sur le sujet, essayez de prendre la position d'un modérateur ou d'un facilitateur, plutôt que de vous jeter dans la bagarre et de faire valoir vos points de vue. Si quelqu'un est méchant ou accapare la conversation, [agissez immédiatement](../building-community/#ne-tolèrez-pas-les-mauvais-acteurs) pour garder les discussions civiles et productives. + + + +D'autres personnes se tournent vers vous pour obtenir des conseils. Donner le bon exemple. Vous pouvez toujours exprimer votre déception, votre tristesse ou votre inquiétude, mais faites-le calmement. + +Garder son calme n'est pas facile, mais faire preuve de leadership améliore la santé de votre communauté. L'internet vous remercie. + +### Traitez votre fichier README en tant que constitution + +Votre fichier README est [plus qu'un simple jeu d'instructions](../starting-a-project/#ecrire-un-fichier-readme). C'est aussi un endroit où parler de vos objectifs, de votre vision du produit et de votre feuille de route. Si les gens sont trop concentrés sur le débat sur le mérite d'une fonctionnalité particulière, il peut être utile de revoir votre fichier README et de parler de la vision plus élevée de votre projet. En vous concentrant sur votre fichier README, vous dépersonnalisez la conversation, ce qui vous permet d'avoir une discussion constructive. + +### Focus sur le voyage, pas la destination + +Certains projets utilisent un processus de vote pour prendre des décisions importantes. Bien que raisonnable à première vue, le vote met l'accent sur le fait d'arriver à une "réponse", plutôt que d'écouter et de répondre aux préoccupations de l'autre. + +Le vote peut devenir politique, où les membres de la communauté se sentent poussés à se faire des faveurs ou à voter d'une certaine manière. Pas tout le monde vote, que ce soit la [majorité silencieuse](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) dans votre communauté, ou les utilisateurs actuels qui ne savaient pas qu'un vote avait lieu. + +Parfois, le vote est un arbitre nécessaire. Cependant, autant que vous le pouvez, insistez sur ["recherche de consensus"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) plutôt que sur un consensus. + +Dans le cadre d'un processus de recherche de consensus, les membres de la communauté discutent des préoccupations majeures jusqu'à ce qu'ils sentent qu'ils ont été suffisamment entendus. Lorsque seules des préoccupations mineures subsistent, la communauté va de l'avant. La recherche d'un consensus reconnaît qu'une communauté peut ne pas être capable d'atteindre une réponse parfaite. Au lieu de cela, il donne la priorité à l'écoute et à la discussion. + + + +Même si vous n'adoptez pas un processus de recherche de consensus, en tant que responsable de projet, il est important que les gens sachent que vous écoutez. Faire en sorte que les autres se sentent entendus, et s'engager à résoudre leurs problèmes, contribue grandement à la diffusion des situations sensibles. Ensuite, suivez vos mots avec des actions. + +Ne vous précipitez pas dans une décision pour avoir une résolution. Assurez-vous que tout le monde se sent entendu et que toutes les informations ont été rendues publiques avant de passer à une résolution. + +### Maintenir la conversation centrée sur l'action + +La discussion est importante, mais il y a une différence entre les conversations productives et improductives. + +Encouragez la discussion tant qu'elle avance activement vers la résolution. S'il est clair que la conversation est en train de languir ou de sortir du sujet, les jabs deviennent personnels, ou les gens ergotent sur des détails mineurs, il est temps de les fermer. + +Permettre ces conversations de continuer n'est pas seulement mauvais pour le problème en question, mais mauvais pour la santé de votre communauté. Il envoie un message que ces types de conversations sont autorisés ou même encouragés, et cela peut décourager les gens de relever ou de résoudre des futures issues. + +Avec chaque point que vous ou d'autres avez fait valoir, demandez-vous:_"Comment cela nous rapproche-t-il d'une résolution ?"_ + +Si la conversation commence à se dérouler, demandez au groupe: _"Quelles étapes devrions-nous prendre ensuite ?"_ Pour recentrer la conversation. + +Si une conversation ne va clairement nulle part, il n'y a pas de mesures claires à prendre, ou les mesures appropriées ont déjà été prises, fermez l'issue et expliquez pourquoi vous l'avez fermé. + + + +### Choisissez vos batailles avec sagesse + +Le contexte est important. Considérez qui est impliqué dans la discussion et comment il représente le reste de la communauté. + +Est-ce que tout le monde dans la communauté est mécontent, voir même concerné par ce problème ? Ou est ce un fauteur de troubles solitaire ? N'oubliez pas de considérer vos membres de la communauté silencieuse, pas seulement les voix actives. + +Si le problème ne représente pas les besoins plus larges de votre communauté, vous devrez peut-être simplement prendre en compte les préoccupations de quelques personnes. S'il s'agit d'un problème récurrent sans résolution claire, indiquez-le aux discussions précédentes sur le sujet et fermez le fil. + +### Identifier un arbitre communautaire + +Avec une bonne attitude et une communication claire, la plupart des situations difficiles peuvent être résolues. Cependant, même dans une conversation productive, il peut simplement y avoir une différence d'opinion sur la façon de procéder. Dans ces cas, identifiez un individu ou un groupe de personnes pouvant servir d'arbitre d'égalité. + +Un arbitre pourrait être le principal responsable du projet, ou il pourrait s'agir d'un petit groupe de personnes qui prendrait une décision en fonction du vote. Idéalement, vous avez identifié une condition de départage et le processus associé dans un fichier GOVERNANCE avant de devoir l'utiliser. + +Votre bris d'égalité devrait être un dernier recours. Les problèmes diviseurs sont une opportunité pour votre communauté de grandir et d'apprendre. Adoptez ces opportunités et utilisez un processus collaboratif pour passer à une résolution dans la mesure du possible. + +## La communauté est le ❤️ de l'open source + +Des communautés saines et prospères alimentent les milliers d'heures consacrées à l'open source chaque semaine. Beaucoup de contributeurs pointent vers d'autres personnes comme la raison de travailler - ou ne pas travailler - sur l'open source. En apprenant comment exploiter ce pouvoir de manière constructive, vous aiderez quelqu'un à vivre une expérience open source inoubliable. diff --git a/_articles/fr/code-of-conduct.md b/_articles/fr/code-of-conduct.md new file mode 100644 index 0000000000000000000000000000000000000000..5dc103fd4888716f69af39bb659758bb3e48f98a --- /dev/null +++ b/_articles/fr/code-of-conduct.md @@ -0,0 +1,114 @@ +--- +lang: fr +title: Votre Code de Conduite +description: Faciliter un comportement communautaire sain et constructif en adoptant et en appliquant un code de conduite. +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## Pourquoi un code de conduite + +Un code de conduite est un document qui établit des attentes de comportement pour les participants de votre projet. Adopter et appliquer un code de conduite peut aider à créer une atmosphère sociale positive pour votre communauté. + +Les codes de conduite aident à protéger non seulement vos participants, mais vous-même. Si vous maintenez un projet, vous constaterez peut-être que les attitudes improductives des autres participants peuvent vous fatiguer ou vous faire sentir malheureux au sujet de votre travail au fil du temps. + +Un code de conduite vous permet de faciliter un comportement communautaire sain et constructif. Être proactif réduit la probabilité que vous, ou d'autres, soyez fatigué avec votre projet, et vous aide à agir lorsque quelqu'un fait quelque chose avec lequel vous n'êtes pas d'accord. + +## Etablir un code de conduite + +Essayez d'établir un code de conduite le plus tôt possible: idéalement, dès que vous créez votre projet. + +En plus de communiquer vos attentes, un code de conduite décrit ce qui suit: + +* Où le code de conduite prend effet _(uniquement sur les issues et les pull request, ou les activités communautaires comme les événements ?)_ +* Qui le code de conduite s'applique-t-il _(membres de la communauté et les mainteneurs, mais qu'en est-il des sponsors ?)_ +* Que se passe-t-il si quelqu'un enfreint le code de conduite +* Comment quelqu'un peut-il signaler les violations + +Quand vous le pouvez, utilisez l'existant. Le [Contributor Covenant](https://contributor-covenant.org/) est un code de conduite qui est utilisé par plus de 40 000 projets open source, y compris Kubernetes, Rails et Swift. + +Le [Django Code of Conduct](https://www.djangoproject.com/conduct/) et le [Citizen Code of Conduct](http://citizencodeofconduct.org/) sont également deux bons exemples de code de conduite. + +Placez un fichier CODE_OF_CONDUCT dans le répertoire racine de votre projet et rendez-le visible pour votre communauté en le liant à votre fichier CONTRIBUTING ou README. + +## Décider comment vous allez appliquer votre code de conduite + + + +Vous devrez expliquer comment votre code de conduite sera appliqué **_avant_** une qu'une violation se produise. Il y a plusieurs raisons de le faire: + +* Cela montre que vous êtes capable de prendre les mesures nécessaire quand il y a besoin. + +* Votre communauté se sentira plus rassurée que les plaintes soient réellement examinées. + +* Vous rassurez votre communauté sur le fait que le processus d'examen est juste et transparent, si jamais ils se retrouvaient à enquêter sur une violation. + +Vous devriez donner aux gens un moyen privé (comme une adresse e-mail) de signaler une violation du code de conduite et d'expliquer qui reçoit ce rapport. Il pourrait s'agir d'un responsable, d'un groupe de responsables ou d'un groupe de travail sur le code de conduite. + +N'oubliez pas que quelqu'un pourrait vouloir signaler une violation à propos d'une personne qui reçoit ces rapports. Dans ce cas, donnez-leur la possibilité de signaler les violations à quelqu'un d'autre. Par exemple, @ctb et @mr-c [expliquent sur leur projet](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer) : + +> Les cas de comportement abusif, harcelant ou autrement inacceptable peuvent être signalés en envoyant un courriel à **khmer-project@idyll.org**, ce qui ne concerne que C. Titus Brown et Michael R. Crusoe. Pour signaler un problème concernant l'un ou l'autre d'entre eux, veuillez envoyer un courriel à **Judi Brown Clarke, Ph. D.** Directrice de la diversité au Centre BEACON pour l'étude de l'évolution en action, un centre NSF pour la science et la technologie.* + +Pour l'inspiration, consultez le [manuel d'application](https://www.djangoproject.com/conduct/enforcement-manual/) de Django (bien que vous n'ayez pas besoin de quelque chose d'aussi complet, selon la taille de votre projet). + +## Appliquer votre code de conduite + +Parfois, malgré tous vos efforts, quelqu'un va faire quelque chose qui viole ce code. Il existe plusieurs façons d'aborder les comportements négatifs ou nuisibles quand ils surviennent. + +### Recueillir des informations sur la situation + +Traitez la voix de chaque membre de la communauté comme étant aussi importante que la vôtre. Si vous recevez un signalement de quelqu'un qui a enfreint le code de conduite, prenez-le au sérieux et faites une enquête, même si cela ne correspond pas à votre propre expérience avec cette personne. Cela indique à votre communauté que vous appréciez leur point de vue et faites confiance à leur jugement. + +Le membre de la communauté en question peut être un récidiviste qui incite constamment les autres à se sentir mal à l'aise, ou il se peut qu'ils aient seulement dit ou fait quelque chose une fois. Les deux peuvent être des motifs d'action, selon le contexte. + +Avant de répondre, donnez-vous le temps de comprendre ce qui s'est passé. Lisez les commentaires et les conversations passés de la personne pour mieux comprendre qui ils sont et pourquoi ils ont agis de cette façon. Essayez de recueillir des points de vues autres que le vôtre au sujet de cette personne et de son comportement. + + + +### Prendre les mesures appropriées + +Après avoir recueilli et traité suffisamment d'informations, vous devrez décider quoi faire. Lorsque vous considérez vos prochaines étapes, n'oubliez pas que votre objectif en tant que modérateur est de favoriser un environnement sûr, respectueux et collaboratif. Ne considérez pas seulement comment faire face à la situation en question, mais comment votre réponse affectera le reste du comportement et les attentes de votre communauté à aller de l'avant. + +Quand quelqu'un signale une violation du code de conduite, c'est votre travail, et non le leur, que de le gérer. Parfois, le déclarant divulgue des informations mettant en péril sa carrière, sa réputation ou sa sécurité physique. Les forcer à affronter son harceleur pourrait mettre le déclarant dans une position compromettante. Vous devez gérer la communication directe avec la personne en question, à moins que le déclarant ne demande explicitement le contraire. + +Il existe plusieurs façons de répondre à une violation du code de conduite: + +* **Donnez à la personne en question un avertissement public** et expliquez comment son comportement a eu un impact négatif sur les autres, de préférence dans le canal où il s'est produit. Dans la mesure du possible, la communication publique indique au reste de la communauté que vous prenez le code de conduite au sérieux. Soyez gentil, mais ferme dans votre communication. + +* **Communiquer en privé avec la personne** en question pour lui expliquer comment son comportement a eu un impact négatif sur les autres. Vous pouvez utiliser un canal de communication privé si la situation implique des informations personnelles sensibles. Si vous communiquez avec quelqu'un en privé, c'est une bonne idée de metre en copie ceux qui ont d'abord signalé la situation, alors ils savent que vous avez pris des mesures. Dans ce cas, demandez le consentement du déclarant avant. + +Parfois, une résolution ne peut pas être atteinte. La personne en question peut devenir agressive ou hostile lorsqu'elle est confrontée ou ne change pas son comportement. Dans cette situation, vous pouvez envisager de prendre des mesures plus énergiques. Par exemple: + +* **Suspendre la personne** en question du projet, imposée par une interdiction temporaire de participer à tout aspect du projet + +* **Interdire définitivement** la personne du projet + +Interdire les membres ne devrait pas être pris à la légère et représente une différence de perspective permanente et irréconciliable. Vous ne devriez prendre ces mesures que lorsqu'il est clair qu'une résolution ne peut pas être atteinte. + +## Vos responsabilités en tant que mainteneur + +Un code de conduite n'est pas une loi imposée arbitrairement. Vous êtes l'exécutant du code de conduite et il est de votre responsabilité de suivre les règles établies par le code de conduite. + +En tant que responsable, vous établissez les lignes directrices pour votre communauté et appliquez ces directives conformément aux règles énoncées dans votre code de conduite. Cela signifie prendre au sérieux tout rapport d'une violation du code de conduite. Les déclarants ont a droit a un examen approfondi et équitable de leur plaintes. Si vous déterminez que le comportement signalé n'est pas une violation, communiquez-le clairement et expliquez pourquoi vous n'allez pas agir. Ce qu'ils feront avec cela leur appartient: tolérer le comportement avec lequel ils ont un problème ou cesser de participer à la communauté. + +Un rapport de comportement qui ne viole pas _théoriquement_ le code de conduite peut toujours indiquer qu'il y a un problème dans votre communauté, et vous devriez étudier ce problème potentiel et agir en conséquence. Cela peut inclure la révision de votre code de conduite pour clarifier un comportement acceptable et/ou parler à la personne dont le comportement a été signalé et lui signaler que bien qu'il n'ai pas enfreint le code de conduite, il est en train de contourner ce qui en est attendu et que certain participants en sont mal à l'aise. + +En fin de compte, en tant que responsable, vous définissez et appliquez les normes pour un comportement acceptable. Vous avez la capacité de façonner les valeurs communautaires du projet, et les participants s'attendent à ce que vous appliquiez ces valeurs de manière juste et équitable. + +## Encouragez le comportement que vous voulez voir dans le monde 🌎 + +Quand un projet semble hostile ou peu accueillant, même si ce n'est qu'une personne dont le comportement est toléré par les autres, vous risquez de perdre beaucoup plus de contributeurs, dont certains ne se rencontreront peut-être jamais. Il n'est pas toujours facile d'adopter ou d'appliquer un code de conduite, mais favoriser un environnement accueillant aidera votre communauté à grandir. diff --git a/_articles/fr/finding-users.md b/_articles/fr/finding-users.md new file mode 100644 index 0000000000000000000000000000000000000000..d73972951f6655cd68a7858df99d4f82c744e275 --- /dev/null +++ b/_articles/fr/finding-users.md @@ -0,0 +1,156 @@ +--- +lang: fr +title: Trouver des utilisateurs pour votre projet +description: Aidez votre projet open source à se développer en le mettant entre les mains d'utilisateurs satisfaits. +class: finding +order: 3 +image: /assets/images/cards/finding.png +related: + - beginners + - building +--- + +## Passer le mot + +Il n'y a pas de règle qui stipule que vous devez promouvoir un projet open source lors de votre lancement. Il existe de nombreuses raisons satisfaisantes de travailler en open source qui n'ont rien à voir avec la popularité. Au lieu d'espérer que les autres trouveront et utiliseront votre projet open source, vous devez passer le mot au sujet de votre dur labeur ! + +## Bien concevoir votre message + +Avant de commencer le travail de promotion de votre projet, vous devriez être en mesure d'expliquer ce qu'il fait et pourquoi c'est important. + +Qu'est-ce qui rend votre projet différent ou intéressant ? Pourquoi l'avez-vous créé ? Répondre à ces questions par vous-même vous aidera à communiquer l'importance de votre projet. + +Rappelez-vous que les gens s'impliquent en tant qu'utilisateurs et deviennent éventuellement des contributeurs, car votre projet résout un problème pour eux. En réfléchissant au message et à la valeur de votre projet, essayez de les voir sous l'angle de ce que les _utilisateurs et les contributeurs_ pourraient vouloir. + +Par exemple, @robb utilise des exemples de code pour expliquer clairement pourquoi son projet, [Cartography](https://github.com/robb/Cartography), est utile: + + + +Pour plus d'information concernant la messagerie, consultez l'exercice de Mozilla ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) pour développer des utilisateurs. + +## Aidez les gens à trouver et à suivre votre projet + + + +Aidez les internautes à trouver et à retenir votre projet en les pointant vers un espace de nom unique. + +**Ayez une poignée claire pour promouvoir votre travail.** Un Twitter, une URL GitHub, ou un canal IRC est un moyen facile de diriger les gens vers votre projet. Ces points de vente permettent également à la communauté grandissante de votre projet de se réunir. + +Si vous ne souhaitez pas encore créer de points de vente pour votre projet, faites la promotion de votre propre compte Twitter ou GitHub dans tout ce que vous faites. La promotion de votre compte Twitter ou GitHub permettra aux gens de savoir comment vous contacter ou suivre votre travail. Si vous parlez lors d'une rencontre ou d'un événement, assurez-vous que vos coordonnées sont incluses dans votre bio ou vos diapositives. + + + +**Envisagez de créer un site Web pour votre projet.** Un site Web rend votre projet plus convivial et plus facile à parcourir, surtout lorsqu'il est associé à une documentation et à des tutoriels clairs. Avoir un site Web suggère également que votre projet est actif, ce qui rendra votre auditoire plus à l'aise pour l'utiliser. Donnez des exemples pour donner aux gens des idées sur la façon d'utiliser votre projet. + +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-créateur de Django, a déclaré qu'un site web était _"de loin la meilleure chose que nous ayons faite avec Django au début"_. + +Si votre projet est hébergé sur GitHub, vous pouvez utiliser [les Pages GitHub](https://pages.github.com/) pour créer facilement un site web. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), et [Middleman](https://middlemanapp.com/) sont [quelques exemples](https://github.com/showcases/github-pages-examples) d'excellents sites Web complets. + + + +Maintenant que vous avez un message pour votre projet et un moyen facile pour les gens de trouver votre projet, allez-y et parlez à votre auditoire ! + +## Allez là où se trouve le public de votre projet (en ligne) + +La sensibilisation en ligne est un excellent moyen de partager et de répandre le mot rapidement. En utilisant les canaux en ligne, vous avez le potentiel d'atteindre un très large public. + +Tirez parti des communautés et des plateformes en ligne existantes pour atteindre votre public. Si votre projet open source est un projet logiciel, vous pouvez probablement trouver votre public sur [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), ou [Quora](https://www.quora.com/). Trouvez les canaux dont vous pensez que les gens vont le plus tirer profit ou seront le plus enthousiasmés par votre travail. + + + +Voyez si vous pouvez trouver des moyens de partager votre projet de manière pertinente : + +* **Apprenez à connaître les projets open source pertinents et les communautés.** Parfois, vous n'avez pas à promouvoir directement votre projet. Si votre projet est parfait pour les scientifiques de données qui utilisent Python, familiarisez-vous avec la communauté de la science des données Python. Au fur et à mesure que les gens vous connaîtront, des occasions naturelles se présenteront pour parler et partager votre travail. +* **Trouvez des personnes rencontrant le problème que votre projet résout.** Recherchez dans les forums connexes pour les personnes qui tombent dans le public cible de votre projet. Répondez à leur question et trouvez avec tact un moyen de suggérer votre projet comme solution. +* **Demandez des commentaires.** Présentez-vous et votre travail à un public qui le trouverait pertinent et intéressant. Soyez précis au sujet de qui, selon vous, bénéficierait de votre projet. Essayez de finir la phrase: _"Je pense que mon projet aiderait vraiment X, qui essaye de faire Y"_. Écoutez et répondez aux commentaires des autres, plutôt que de simplement promouvoir votre travail. + +En général, concentrez-vous sur l'aide aux autres avant de demander des choses en retour. Parce que n'importe qui peut facilement promouvoir un projet en ligne, il y aura beaucoup de bruit. Pour se démarquer de la foule, donnez aux gens un contexte pour ce que vous êtes et pas seulement ce que vous voulez. + +Si personne ne fait attention ou répond à vos premiers contacts, ne vous découragez pas ! La plupart des lancements de projets sont un processus itératif qui peut prendre des mois ou des années. Si vous n'obtenez pas de réponse la première fois, essayez une tactique différente, ou cherchez d'abord des façons d'ajouter de la valeur au travail des autres. La promotion et le lancement de votre projet demandent du temps et du dévouement. + +## Allez là où se trouve le public de votre projet (hors ligne) + + + +Les événements hors ligne sont un moyen populaire de promouvoir de nouveaux projets auprès des publics. Ils constituent un excellent moyen d'atteindre un public engagé et de tisser des liens humains plus profonds, en particulier si vous souhaitez toucher les développeurs. + +Si vous êtes [nouveau sur la prise de parole en public](https://speaking.io/), commencez par trouver une rencontre locale liée à la langue ou à l'écosystème de votre projet. + + + +Si vous n'avez jamais parlé à un événement auparavant, il est tout à fait normal de vous sentir nerveux ! Rappelez-vous que votre auditoire est là parce qu'il veut vraiment entendre parler de votre travail. + +Au fur et à mesure que vous écrivez votre exposé, concentrez-vous sur ce que votre auditoire trouvera intéressant et dont vous tirerez profit. Gardez votre ton amicale et accessible. Souriez, respirez et amusez-vous. + + + +Lorsque vous êtes prêt, envisagez de prendre la parole lors d'une conférence pour promouvoir votre projet. Les conférences peuvent vous aider à atteindre plus de gens, parfois de partout dans le monde. + +Recherchez des conférences spécifiques à votre langue ou à votre écosystème. Avant de soumettre votre exposé, faites des recherches sur la conférence pour adapter votre discours aux participants et augmenter vos chances d'être accepté pour prendre la parole à la conférence. Vous pouvez souvent avoir une idée de votre auditoire en regardant les conférenciers d'une conférence. + + + +## Construire une réputation + +En plus des stratégies décrites ci-dessus, la meilleure façon d'inviter les gens à partager et à contribuer à votre projet est de partager et de contribuer à leurs projets. + +Aider les nouveaux arrivants, partager des ressources et apporter une contribution réfléchie aux projets des autres vous aidera à vous bâtir une réputation positive. Être un membre actif dans la communauté open source aidera les gens à avoir un contexte pour votre travail et sera plus susceptible de prêter attention et de partager votre projet. Développer des relations avec d'autres projets open source peut même conduire à des partenariats officiels. + + + +Il n'est jamais trop tôt ou trop tard pour commencer à bâtir votre réputation. Même si vous avez déjà lancé votre propre projet, continuez de chercher des moyens d'aider les autres. + +Il n'y a pas de solution du jour au lendemain pour créer un public. Gagner la confiance et le respect des autres prend du temps, et bâtir votre réputation ne s'arrête jamais. + + + +## Persévèrez ! + +Cela peut prendre beaucoup de temps avant que les gens remarquent votre projet open source. C'est bon ! Certains des projets les plus populaires aujourd'hui ont pris des années pour atteindre des niveaux d'activité élevés. Concentrez-vous sur l'établissement de relations au lieu d'espérer que votre projet gagnera spontanément en popularité. Soyez patient et continuez à partager votre travail avec ceux qui l'apprécient. diff --git a/_articles/fr/getting-paid.md b/_articles/fr/getting-paid.md new file mode 100644 index 0000000000000000000000000000000000000000..7775c34ed986b6134514a97bfeb37e8c0d4485d4 --- /dev/null +++ b/_articles/fr/getting-paid.md @@ -0,0 +1,181 @@ +--- +lang: fr +title: Etre payé pour faire de l'Open Source +description: Soutenez votre travail en open source en obtenant un soutien financier pour votre temps ou votre projet. +class: getting-paid +order: 7 +image: /assets/images/cards/getting-paid.png +related: + - best-practices + - leadership +--- + +## Pourquoi certaines personnes cherchent un soutien financier + +Une grande partie du travail open source est volontaire. Par exemple, une personne peut rencontrer un bogue dans un projet qu'elle utilise et soumettre une solution rapide, ou alors, elle peut s'amuser à bricoler un projet open source pendant son temps libre. + + + +Il y a plusieurs raisons pour lesquelles une personne ne voudrait pas être payée pour son travail open source. + +* **Ils ont peut-être déjà un emploi à temps plein qu'ils aiment**, ce qui leur permet de contribuer à l'open source pendant leur temps libre. +* **Ils aiment penser à l'open source comme un passe-temps** ou une évasion créative et ne veulent pas se sentir financièrement obligés de travailler sur leurs projets. +* **Ils ont d'autres avantages à contribuer à l'open source**, comme bâtir leur réputation ou leur portfolio, apprendre une nouvelle compétence ou se sentir plus proches d'une communauté. + + + +Pour d'autres, surtout lorsque les contributions sont en cours ou demandent beaucoup de temps, être payé pour contribuer à l'open source est la seule façon de participer, soit parce que le projet l'exige, soit pour des raisons personnelles. + +Maintenir des projets populaires peut être une responsabilité importante, en prenant 10 ou 20 heures par semaine au lieu de quelques heures par mois. + + + +Le travail rémunéré permet également aux personnes de différents horizons de faire des contributions significatives. Certaines personnes ne peuvent pas se permettre de consacrer du temps non rémunéré à des projets Open Source, en fonction de leur situation financière actuelle, de leur dette, de leur famille ou d'autres obligations. Cela signifie que le monde ne voit jamais les contributions de personnes talentueuses qui ne peuvent pas se permettre de faire du bénévolat. Cela a des implications éthiques, comme @ashedryden [a décrit](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), puisque le travail qui est fait est biaisés en faveur de ceux qui ont déjà des avantages dans la vie, qui obtiennent ensuite des avantages supplémentaires en fonction de leurs contributions bénévoles, tandis que d'autres qui ne peuvent pas faire de bénévolat n'obtiennent pas d'opportunités ultérieures, ce qui renforce le manque de diversité au sein de la communauté de l'open source. + + + +Si vous cherchez un soutien financier, il y a deux pistes à considérer. Vous pouvez financer votre propre temps en tant que contributeur, ou vous pouvez trouver un financement organisationnel pour le projet. + +## Financer votre temps + +Aujourd'hui, beaucoup de gens sont payés pour travailler à temps plein ou à temps partiel. La façon la plus courante d'être payé pour votre temps est de parler à votre employeur. + +Il est plus facile de plaider en faveur du travail open source si votre employeur utilise réellement le projet, mais soyez créatif avec votre argumentaire. Peut-être que votre employeur n'utilise pas le projet, mais ils utilisent Python, et le maintien d'un projet populaire Python aide à attirer de nouveaux développeurs Python. Peut-être que cela rend votre employeur plus convivial en général. + + + +Si vous n'avez pas de projet Open Source sur lequel vous souhaitez travailler, mais préférez que votre travail actuel soit ouvert, demandez à votre employeur d'ouvrir certains de ses logiciels internes. + +De nombreuses entreprises développent des programmes open source pour construire leur marque et recruter des talents de qualité. + +@hueniverse, par exemple, a trouvé qu'il y avait des raisons financières pour justifier [l'investissement de Walmart dans l'open source](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). Et @jamesgpearce a trouvé que le programme open source de Facebook [a fait une différence](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) dans le recrutement: + +> Il est étroitement lié à notre culture de hackers et à la perception de notre organisation. Nous avons demandé à nos employés: "Connaissiez-vous le logiciel Open Source sur Facebook ?" Les deux tiers ont dit "Oui". La moitié a déclaré que le programme a contribué positivement à leur décision de travailler pour nous. Ce ne sont pas des chiffres marginaux, et j'espère, une tendance qui se poursuit. + +Si votre entreprise suit cette voie, il est important de garder les limites entre les activités communautaires et corporatives. En fin de compte, l'open source s'appuie sur les contributions de personnes du monde entier, et c'est plus important que n'importe quelle entreprise ou emplacement. + + + +Si vous ne pouvez pas convaincre votre employeur actuel d'accorder la priorité au travail open source, envisagez de trouver un nouvel employeur qui encourage les contributions des employés à l'open source. Cherchez des entreprises qui rendent explicite leur dévouement au travail open source. Par exemple : + +* Certaines entreprises, comme [Netflix](https://netflix.github.io/) ou [PayPal](https://paypal.github.io/), ont des sites Web qui soulignent leur implication dans l'open source +* [Zalando](https://opensource.zalando.com) a publié sa [politique de contribution open source](https://opensource.zalando.com/docs/using/contributing/) pour les employés + +Les projets provenant d'une grande entreprise, tels que [Go](https://github.com/golang) ou [React](https://github.com/facebook/react), emploieront probablement des personnes pour travailler sur Open source. + +Enfin, en fonction de votre situation personnelle, vous pouvez essayer de collecter des fonds de manière indépendante pour financer votre travail open source. Par exemple : + +* @gaearon a fait financer son travail sur [Redux](https://github.com/reactjs/redux) via une [campagne de crowdfunding sur Patreon](https://redux.js.org/) +* @andrewgodwin a fait financer le travail sur les migrations de schémas Django [à travers une campagne Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) + +## Trouver du financement pour votre projet + +Au-delà des arrangements pour les contributeurs individuels, les projets recueillent parfois des fonds auprès d'entreprises, de particuliers ou d'autres pour financer des travaux en cours. + +Le financement organisationnel pourrait servir à payer les contributeurs actuels, à couvrir les coûts de gestion du projet (tels que les frais d'hébergement) ou à investir dans de nouvelles fonctionnalités ou idées. + +À mesure que la popularité de l'open source augmente, la recherche de financement pour des projets est encore expérimentale, mais il existe quelques options communes disponibles. + +### Gagnez de l'argent pour votre travail grâce à des campagnes de crowdfunding ou de parrainage + +Trouver des commandites fonctionne bien si vous avez déjà un public ou une réputation solide, ou si votre projet est très populaire. +Quelques exemples de projets sponsorisés incluent: + +* **[webpack](https://github.com/webpack)** collecte des fonds auprès des entreprises et des particuliers [via OpenCollective](https://opencollective.com/webpack) +* **[Vue](https://github.com/vuejs/vue)** est [financé par Patreon](https://github.com/open-source/stories/yyx990803) +* **[Ruby Together](https://rubytogether.org/),** une organisation à but non lucratif qui paie pour travailler sur [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), et d'autres projets d'infrastructure Ruby + +### Créer un flux de revenus + +En fonction de votre projet, vous pouvez facturer un support commercial, des options hébergées ou des fonctionnalités supplémentaires. Quelques exemples incluent: + +* **[Sidekiq](https://github.com/mperham/sidekiq)** propose des versions payantes pour un support supplémentaire +* **[Travis CI](https://github.com/travis-ci)** offre des versions payantes de son produit +* **[Ghost](https://github.com/TryGhost/Ghost)** est un organisme à but non lucratif avec un service géré payant + +Certains projets populaires, tels que [npm](https://github.com/npm/npm) et [Docker](https://github.com/docker/docker), permettent même de lever du capital-risque pour soutenir la croissance de leur entreprise. + +### Demande de financement + +Certaines fondations de logiciels et sociétés offrent des subventions pour le travail open source. Parfois, des subventions peuvent être versées à des personnes sans créer une entité juridique pour le projet. + +* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** a reçu une subvention de [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/) +* **[OpenMRS](https://github.com/openmrs)** le travail a été financé par [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) +* **[Libraries.io](https://github.com/librariesio)** a reçu une subvention de la [Sloan Foundation](https://sloan.org/programs/digital-technology) +* La **[Python Software Foundation](https://www.python.org/psf/grants/)** offre des subventions pour les travaux liés à Python + +Pour des options plus détaillées et des études de cas, @nayafia [a écrit un guide](https://github.com/nayafia/lemonade-stand) pour être payé pour le travail open source. Différents types de financement nécessitent des compétences différentes, alors considérez vos forces pour déterminer quelle option vous convient le mieux. + +## Bâtir un dossier pour un soutien financier + +Que votre projet soit une nouvelle idée, ou qu'il existe depuis des années, vous devriez vous attendre à réfléchir sérieusement à l'identification de votre bailleur de fonds cible et à présenter un cas convaincant. + +Que vous cherchiez à payer pour votre temps libre ou à collecter des fonds pour un projet, vous devriez être en mesure de répondre aux questions suivantes. + +### Impact + +Pourquoi ce projet est-il utile ? Pourquoi vos utilisateurs, ou les utilisateurs potentiels, l'apprécient-ils autant ? Où sera-ce dans cinq ans ? + +### Traction + +Essayez de recueillir des preuves que votre projet compte, que ce soit des mesures, des anecdotes ou des témoignages. Y a-t-il des entreprises ou des personnes remarquables qui utilisent votre projet en ce moment ? Si non, une personne en vue l'a-t-elle approuvée ? + +### Valeur au donateur + +Les bailleurs de fonds, que ce soit votre employeur ou une fondation subventionnaire, sont fréquemment approchés avec des opportunités. Pourquoi devraient-ils soutenir votre projet par rapport à toute autre opportunité ? Comment en bénéficient-ils personnellement ? + +### Utilisation des fonds + +Qu'allez-vous accomplir exactement avec le financement proposé ? Concentrez-vous sur les jalons ou les résultats du projet plutôt que de payer un salaire. + +### Comment vous recevrez les fonds + +Le bailleur de fonds a-t-il des exigences en matière de déboursement ? Par exemple, vous devrez peut-être être un but non lucratif ou avoir un sponsor fiscal à but non lucratif. Ou peut-être que les fonds doivent être donnés à un entrepreneur individuel plutôt qu'à une organisation. Ces exigences varient selon les bailleurs de fonds, alors assurez-vous de faire vos recherches à l'avance. + + + +## Expérimentez et n'abandonnez pas + +Il n'est pas facile de gagner de l'argent, qu'il s'agisse d'un projet open source, d'un but non lucratif ou d'un démarrage de logiciel, et dans la plupart des cas, vous devez être créatif. Identifier comment vous voulez être payé, faire votre recherche, et vous mettre dans la peau de votre bailleur de fonds vous aidera à construire un argument convaincant pour le financement. diff --git a/_articles/fr/how-to-contribute.md b/_articles/fr/how-to-contribute.md new file mode 100644 index 0000000000000000000000000000000000000000..7ec90a96ee5bee3f2caac52c3fc2cbda9f0df330 --- /dev/null +++ b/_articles/fr/how-to-contribute.md @@ -0,0 +1,526 @@ +--- +lang: fr +title: Comment contribuer à l'Open Source +description: Vous voulez contribuer à l'open source ? Un guide pour faire des contributions open source, pour les débutants et pour les vétérans. +class: contribute +order: 1 +image: /assets/images/cards/contribute.png +related: + - beginners + - building +--- + +## Pourquoi contribuer à l'open source + + + +Contribuer à l'open source peut être une manière enrichissante d'apprendre, d'enseigner et de construire une expérience dans presque toutes les compétences que vous pouvez imaginer. + +Pourquoi les gens contribuent-ils à l'open source ? Beaucoup de raisons ! + +### Améliorer les compétences existantes + +Que ce soit le codage, la conception de l'interface utilisateur, la conception graphique, la rédaction ou l'organisation, si vous cherchez de la pratique, il y a une tâche pour vous sur un projet open source. + +### Rencontrez des gens qui s'intéressent à des choses similaires + +Les projets Open Source avec des communautés chaleureuses et accueillantes font que les gens reviennent pendant des années. Beaucoup de gens forment des amitiés à vie grâce à leur participation à l'open source, que ce soit dans le cadre de conférences ou de bavardages en ligne tard dans la nuit sur les burritos. + +### Trouver des mentors et enseigner aux autres + +Travailler avec d'autres sur un projet partagé signifie que vous devrez expliquer comment vous faites les choses, ainsi que de demander de l'aide à d'autres personnes. Les actes d'apprentissage et d'enseignement peuvent être une activité enrichissante pour tous ceux qui sont impliqués. + +### Construire des artefacts publics qui vous aident à acquérir une réputation (et une carrière) + +Par définition, tout votre travail open source est public, ce qui signifie que vous obtenez des exemples gratuits à emporter pour démontrer ce que vous pouvez faire. + +### Apprendre les compétences des personnes + +L'Open Source offre des opportunités de pratiquer des compétences de leadership et de gestion, telles que la résolution de conflits, l'organisation d'équipes de personnes et la hiérarchisation du travail. + +### Cela permet de faire des changements, même les plus petits + +Vous n'avez pas besoin de devenir un contributeur permanent pour profiter de la participation à l'open source. Avez-vous déjà vu une faute de frappe sur un site Web et souhaité que quelqu'un la corrige ? Sur un projet open source, vous pouvez le faire. L'Open Source aide les gens à se sentir interpellés par leur vie et leur expérience du monde, ce qui est en soi gratifiant. + +## Que signifie contribuer + +Si vous êtes un nouveau contributeur open source, le processus peut être intimidant. Comment trouvez-vous le bon projet ? Que faire si vous ne savez pas coder ? Et si quelque chose ne va pas ? + +Ne pas s'inquiéter ! Il y a toutes sortes de façons de s'impliquer dans un projet open source, et quelques conseils vous aideront à tirer le meilleur parti de votre expérience. + +### Vous n'avez pas à contribuer au code + +Une idée commune fausse sur la contribution à l'open source est que vous devez contribuer au code. En fait, ce sont souvent les autres parties d'un projet qui sont [le plus négligées ou négligées](https://github.com/blog/2195-the-shape-of-open-source). Vous allez faire une faveur au projet en offrant de participer à ces types de contributions ! + + + +Même si vous aimez écrire du code, d'autres types de contributions sont un excellent moyen de s'impliquer dans un projet et de rencontrer d'autres membres de la communauté. Construire ces relations vous donnera l'opportunité de travailler sur d'autres parties du projet. + + + +### Aimez-vous la planification d'événements ? + +* Organiser des ateliers ou des meetups sur le projet, [comme @fzamperin a fait pour NodeSchool](https://github.com/nodeschool/organizers/issues/406) +* Organiser la conférence du projet (s'ils en ont une) +* Aider les membres de la communauté à trouver les bonnes conférences et soumettre des propositions de talk + +### Aimez-vous créer ? + +* Restructurer les mises en page pour améliorer la convivialité du projet +* Effectuer des recherches utilisateur pour réorganiser et affiner la navigation ou les menus du projet, [comme suggère Drupal](https://www.drupal.org/community-initiatives/drupal-core/usability) +* Mettre en place un guide de style pour aider le projet à avoir un design visuel cohérent +* Créer de l'art pour des t-shirts ou un nouveau logo, [comme les contributeurs de hapi.js l'ont fait](https://github.com/hapijs/contrib/issues/68) + +### Aimez-vous écrire ? + +* Écrire et améliorer la documentation du projet +* Curate un dossier d'exemples montrant comment le projet est utilisé +* Démarrer un bulletin d'information pour le projet, ou organiser des faits marquants de la liste de diffusion +* Rédiger des tutoriels pour le projet, [comme les contributeurs de PyPA l'ont fait](https://github.com/pypa/python-packaging-user-guide/issues/194) +* Écrire une traduction pour la documentation du projet + + + +### Aimez-vous l'organisation ? + +* Lien vers des questions en double, et suggérer de nouveaux labels pour les issues, pour garder les choses organisées +* Passer en revue les problèmes ouverts et suggérer de fermer les anciens, [comme @nzakas a fait pour ESLint](https://github.com/eslint/eslint/issues/6765) +* Posez des questions de clarification sur les issues récemment ouvertes pour faire avancer la discussion + +### Aimez-vous le code ? + +* Trouver un problème ouvert à aborder, [comme @dianjin a fait pour Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) +* Demandez si vous pouvez aider à écrire une nouvelle fonctionnalité +* Automatiser la configuration du projet +* Améliorer l'outillage et les tests + +### Aimez-vous aider les gens ? + +* Répondez aux questions sur le projet sur, par exemple, Stack Overflow ([comme cet exemple Postgres](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) ou Reddit +* Répondre aux questions pour les personnes sur les questions ouvertes +* Aider à modérer les forums de discussion ou les canaux de conversation + +### Aimez-vous aider les autres ? + +* Réviser le code sur les soumissions d'autres personnes +* Écrire des tutoriels sur la façon dont un projet peut être utilisé +* Proposer de parrainer un autre contributeur, [comme @ereichert l'a fait pour @bronzdoc sur Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) + +### Il ne suffit pas de travailler sur des projets logiciels ! + +Alors que "open source" se réfère souvent à un logiciel, vous pouvez collaborer sur à peu près n'importe quoi. Il existe des livres, des recettes, des listes et des classes qui sont développés en tant que projets open source. + +Par exemple: + +* @sindresorhus gère une [liste de listes "géniales"](https://github.com/sindresorhus/awesome) +* @h5bp tient à jour une [liste des questions potentielles lors d'entretiens](https://github.com/h5bp/Front-end-Developer-Interview-Questions) pour les candidats développeurs +* @stuartlynn et @nicole-a-tesla ont fait une [collection de faits amusants sur les macareux](https://github.com/stuartlynn/puffin_facts) + +Même si vous êtes un développeur de logiciels, travailler sur un projet de documentation peut vous aider à démarrer en open source. Il est souvent moins intimidant de travailler sur des projets qui n'impliquent pas de code, et le processus de collaboration renforcera votre confiance et votre expérience. + +## S'orienter vers un nouveau projet + + + +Pour tout ce qui n'est pas une faute de frappe, contribuer à l'open source, c'est comme aller à un groupe d'étrangers lors d'une fête. Si vous commencez à parler des lamas, alors qu'ils étaient plongés dans une discussion sur les poissons rouges, ils vous regarderont probablement un peu étrangement. + +Avant de sauter à l'aveuglette avec vos propres suggestions, commencez par apprendre à lire la pièce. Cela augmente les chances que vos idées soient remarquées et entendues. + +### Anatomie d'un projet open source + +Chaque communauté open source est différente. + +Passer des années sur un projet open source signifie que vous avez appris à connaître un projet open source. Déplacez-vous vers un projet différent, et vous pourriez trouver le vocabulaire, les normes et les styles de communication complètement différents. + +Cela dit, de nombreux projets open source suivent une structure organisationnelle similaire. Comprendre les différents rôles de la communauté et le processus global vous aidera à vous orienter rapidement vers tout nouveau projet. + +Un projet Open Source typique comprend les types de personnes suivants: + +* **Auteur :** La personne / l'organisation qui a créé le projet +* **Propriétaire :** La ou les personnes qui ont la propriété administrative de l'organisation ou du repository (pas toujours les mêmes que l'auteur original) +* **Responsables :** Collaborateurs responsables de la vision et de la gestion des aspects organisationnels du projet. (Ils peuvent aussi être auteurs ou propriétaires du projet.) +* **Contributeurs :** Tous ceux qui ont contribué au projet. +* **Membres de la communauté :** Les personnes qui utilisent le projet. Ils peuvent être actifs dans les conversations ou exprimer leur opinion sur la direction du projet. + +Les plus grands projets peuvent également avoir des sous-comités ou des groupes de travail axés sur différentes tâches, telles que l'outillage, le triage, la modération communautaire et l'organisation d'événements. Regardez sur le site Web d'un projet pour une page «équipe», ou dans le repository pour la documentation de gouvernance, pour trouver cette information. + +Un projet a également une documentation. Ces fichiers sont généralement répertoriés à la racine d'un repository. + +* **LICENCE :** Par définition, chaque projet open source doit avoir une [licence open source](https://choosealicense.com). Si le projet n'a pas de licence, il n'est pas open source. +* **README :** Le README est le manuel d'instructions qui accueille les nouveaux membres de la communauté au projet. Cela explique pourquoi le projet est utile et comment démarrer. +* **CONTRIBUTING :** Alors que les fichiers README aident les gens à utiliser le projet, les documents de contribution aident les gens à contribuer au projet. Il explique quels types de contributions sont nécessaires et comment le processus fonctionne. Bien que tous les projets n'aient pas de fichier CONTRIBUTING, sa présence indique qu'il s'agit d'un projet accueillant auquel contribuer. +* **CODE_OF_CONDUCT :** Le code de conduite établit des règles de base pour le comportement des participants et contribue à faciliter un environnement amical et accueillant. Bien que tous les projets n'aient pas de fichier CODE_OF_CONDUCT, sa présence indique qu'il s'agit d'un projet accueillant auquel contribuer. +* **Autre documentation :** Il pourrait y avoir de la documentation supplémentaire, comme des tutoriels, des procédures pas à pas, ou des politiques de gouvernance, en particulier sur des projets plus importants. + +Enfin, les projets open source utilisent les outils suivants pour organiser la discussion. La lecture des archives vous donnera une bonne idée de la façon dont la communauté pense et travaille. + +* **Suivi des issues :** Lorsque les gens discutent des issues liés au projet. +* **Pull Requests :** Où les gens discutent et examinent les changements en cours. +* **Forums de discussion ou listes de diffusion :** Certains projets peuvent utiliser ces canaux pour des sujets conversationnels (par exemple, _"Comment puis-je..."_ ou _"Que pensez-vous de..."_ au lieu d'un rapport de bug ou demandes de fonctionnalités). D'autres utilisent le suivi des issues pour toutes les conversations. +* **Canal de discussion synchrone :** Certains projets utilisent des canaux de discussion (tels que Slack ou IRC) pour des conversations informelles, la collaboration et des échanges rapides. + +## Trouver un projet auquel contribuer + +Maintenant que vous avez compris comment fonctionnent les projets open source, il est temps de trouver un projet auquel contribuer ! + +Si vous n'avez jamais contribué à l'open source auparavant, prenez quelques conseils du président américain John F. Kennedy, qui a dit: _"Ne demandez pas ce que votre pays peut faire pour vous - demandez ce que vous pouvez faire pour votre pays."_ + +Contribuer à l'open source se produit à tous les niveaux, à travers les projets. Vous n'avez pas besoin de trop réfléchir sur ce que sera exactement votre première contribution ou sur ce à quoi elle ressemblera. + +Au lieu de cela, commencez par penser aux projets que vous utilisez déjà ou que vous voulez utiliser. Les projets auxquels vous contribuez activement sont ceux auxquels vous revenez. + +Dans ces projets, chaque fois que vous pensez que quelque chose pourrait être meilleur ou différent, agissez selon votre instinct. + +L'open source n'est pas un club exclusif. C'est fait par des gens comme vous. "Open source" est juste un terme de fantaisie pour traiter les problèmes du monde comme réparable. + +Vous pouvez scanner un fichier README et trouver un lien cassé ou une faute de frappe. Ou vous êtes un nouvel utilisateur et vous avez remarqué que quelque chose est cassé, ou un problème que vous pensez devrait vraiment être dans la documentation. Au lieu de l'ignorer et de passer à autre chose, ou de demander à quelqu'un d'autre de le réparer, voyez si vous pouvez aider en faisant un descriptif du problème. C'est cela l'open source ! + +> [28% des contributions occasionnelles](https://www.igor.pro.br/publica/papers/saner2016.pdf) à l'open source sont de la documentation, une correction de faute de frappe, un reformatage ou l'écriture d'une traduction. + +Vous pouvez également utiliser l'une des ressources suivantes pour vous aider à découvrir et à contribuer à de nouveaux projets : + +* [GitHub Explore](https://github.com/explore/) +* [Open Source Friday](https://opensourcefriday.com) +* [First Timers Only](https://www.firsttimersonly.com/) +* [CodeTriage](https://www.codetriage.com/) +* [24 Pull Requests](https://24pullrequests.com/) +* [Up For Grabs](https://up-for-grabs.net/) +* [Contributor-ninja](https://contributor.ninja) +* [First Contributions](https://firstcontributions.github.io) +* [SourceSort](https://www.sourcesort.com/) + +### Une checklist avant de contribuer + +Lorsque vous avez trouvé un projet auquel vous souhaitez contribuer, effectuez une analyse rapide pour vous assurer que le projet est adapté à l'acceptation des contributions. Sinon, votre travail acharné pourrait ne jamais avoir de réponse. + +Voici une liste de contrôle pratique pour évaluer si un projet est bon pour les nouveaux contributeurs. + +**Répondre à la définition de l'open source** + +
OSS yields massive benefits to the technology industry, which, in turn, means benefits to all industries. (...) However, if the only people who can focus on it are the lucky and the obsessed, then there's a huge untapped potential.
-— @isaacs, ["Money and Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c#.ftnd5qez0) +— @isaacs, ["Money and Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
@@ -100,15 +100,20 @@ If your company goes down this route, it's important to keep the boundaries betw If you can't convince your current employer to prioritize open source work, consider finding a new employer that encourages employee contributions to open source. Look for companies that make their dedication to open source work explicit. For example: * Some companies, like [Netflix](https://netflix.github.io/) or [PayPal](https://paypal.github.io/), have websites that highlight their involvement in open source -* [Rackspace](https://www.rackspace.com/en-us) published its [open source contribution policy](https://blog.rackspace.com/rackspaces-policy-on-contributing-to-open-source/) for employees +* [Zalando](https://opensource.zalando.com) published its [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) for employees Projects that originated at a large company, such as [Go](https://github.com/golang) or [React](https://github.com/facebook/react), will also likely employ people to work on open source. -Finally, depending on your personal circumstances, you can try raising money independently to fund your open source work. For example: +Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example: * @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/) * @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) +Finally, sometimes open source projects put bounties on issues that you might consider helping with. + +* @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/). +* @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134). + ## Finding funding for your project Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work. @@ -184,5 +189,3 @@ Does the funder have any requirements around disbursal? For example, you may nee ## Experiment and don't give up Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases require you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding. - -> diff --git a/_articles/how-to-contribute.md b/_articles/how-to-contribute.md index 35ad736ae69da66847f6d4ada6dd87c6c20d8662..81158f6f25a7eb15f9ca88ebc15df03715f0c8c9 100644 --- a/_articles/how-to-contribute.md +++ b/_articles/how-to-contribute.md @@ -31,6 +31,10 @@ Contributing to open source can be a rewarding way to learn, teach, and build ex Why do people contribute to open source? Plenty of reasons! +### Improve software you rely on + +Lots of open source contributors start by being users of software they contribute to. When you find a bug in an open source software you use, you may want to look at the source to see if you can patch it yourself. If that's the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it. + ### Improve existing skills Whether it's coding, user interface design, graphic design, writing, or organizing, if you're looking for practice, there's a task for you on an open source project. @@ -69,7 +73,7 @@ A common misconception about contributing to open source is that you need to con
I’ve been renowned for my work on CocoaPods, but most people don’t know that I actually don’t do any real work on the CocoaPods tool itself. My time on the project is mostly spent doing things like documentation and working on branding.
-— @orta, ["Moving to OSS by default"](https://realm.io/news/orta-therox-moving-to-oss-by-default/) +— @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
@@ -175,9 +179,9 @@ A typical open source project has the following types of people: * **Author:** The person/s or organization that created the project * **Owner:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author) -* **Maintainers:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project. (They may also be authors or owners of the project.) -* **Contributors:** Everyone who has contributed something back to the project. -* **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction. +* **Maintainers:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.) +* **Contributors:** Everyone who has contributed something back to the project +* **Community Members:** People who use the project. They might be active in conversations or express their opinion on the project's direction Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project's website for a "team" page, or in the repository for governance documentation, to find this information. @@ -214,16 +218,19 @@ You might scan a README and find a broken link or a typo. Or you're a new user a > [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as a typo fix, reformatting, or writing a translation. +If you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)). + You can also use one of the following resources to help you discover and contribute to new projects: * [GitHub Explore](https://github.com/explore/) * [Open Source Friday](https://opensourcefriday.com) -* [First Timers Only](http://www.firsttimersonly.com/) -* [Your First PR](https://yourfirstpr.github.io/) +* [First Timers Only](https://www.firsttimersonly.com/) * [CodeTriage](https://www.codetriage.com/) * [24 Pull Requests](https://24pullrequests.com/) -* [Up For Grabs](http://up-for-grabs.net/) +* [Up For Grabs](https://up-for-grabs.net/) * [Contributor-ninja](https://contributor.ninja) +* [First Contributions](https://firstcontributions.github.io) +* [SourceSort](https://www.sourcesort.com/) ### A checklist before you contribute @@ -236,7 +243,7 @@ Here's a handy checklist to evaluate whether a project is good for new contribut
Whenever you see a long thread, spot check responses from core developers coming late in the thread. Are they summarizing constructively, and taking steps to bring the thread to a decision while remaining polite? If you see a lot of flame wars going on, that's often a sign that energy is going into argument instead of into development.
-— @kfogel, [_Producing OSS_](http://producingoss.com/en/evaluating-oss-projects.html) +— @kfogel, [_Producing OSS_](https://producingoss.com/en/evaluating-oss-projects.html)
@@ -391,7 +398,7 @@ Whether you're a one-time contributor or trying to join a community, working wit
\[As a new contributor,\] I quickly realized I had to ask questions if I wanted to be able to close the issue. I skimmed through the code base. Once I had some sense of what was going on, I asked for more direction. And voilà! I was able to solve the issue after getting all the relevant details I needed.
-— @shubheksha, [A Beginner's Very Bumpy Journey Through The World of Open Source](https://medium.freecodecamp.com/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39#.pcswr2e78) +— @shubheksha, [A Beginner's Very Bumpy Journey Through The World of Open Source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
diff --git a/_articles/hu/best-practices.md b/_articles/hu/best-practices.md new file mode 100644 index 0000000000000000000000000000000000000000..c98d032a7494786ce59a55258798ef4cc9f2e583 --- /dev/null +++ b/_articles/hu/best-practices.md @@ -0,0 +1,280 @@ +--- +lang: hu +title: Bevált gyakorlatok karbantartók részére +description: Nyílt forráskódú karbantartóként tedd az életed könnyebbé a folyamatok dokumentálásától kezdve a közösség erejének a kiaknázásáig. +class: best-practices +order: 5 +image: /assets/images/cards/best-practices.png +related: + - metrics + - leadership +--- + +## Mit jelent karbantartónak lenni? + +Ha olyan nyílt forráskódú projektet tartasz fenn, amelyet sok ember használ, akkor valószínűleg észrevetted, hogy kevesebbet kódolsz, és többet válaszolsz a problémákra. + +A projekt korai szakaszában új ötletekkel kísérletezel és alapvető döntéseket hozol az alapján, hogy mit szeretnél. Ahogy a projekted népszerűsége növekszik, azon veszed észre magad, hogy egyre többet dolgozol együtt a felhasználókkal és a közreműködőkkel. + +Egy projektet fenntartani többet jelent, mint csak kódolni. Ezek a feladatok gyakran váratlanok, de ugyanolyan fontosak egy fejlődő projektben. Összegyűjtöttünk néhány módszert az életünk megkönnyítésére, a folyamatok dokumentálásától kezdve a közösség erejének a kiaknázásáig. + +## A folyamatok dokumentálása + +A dolgok leírása az egyik legfontosabb dolog, amelyet karbantartóként megtehetsz. + +A dokumentáció nem csak a saját gondolkodásod letisztulását segíti, hanem azt is, hogy más is megértse a szándékodat anélkül, hogy kérdezni kellene. + +A dolgok leírása könnyebbé teszi azt, hogy nemet tudj mondani olyan dolgokra, amelyek nem illeszkednek a projekt hatókörébe. Ezenkívül megkönnyíti az embereknek a belépését és segítését. Sohasem tudhatod, hogy ki olvassa vagy használja a projektet. + +Még ha nem is fejted ki a teljes mondanivalód, akkor is jobb legalább felsoroláspontokban röviden összeszedni azt, mintha nem írnál semmit sem. + +Ne felejtsd el naprakészen tartani a dokumentációt. Ha nem vagy képes ezt mindig megtenni, töröld az elavult dokumentációt, vagy jelezd azt, hogy elavult, így a közreműködők tudják, hogy szívesen várod a frissítéseket ezekre. + +### Írd le a projekt vízióját + +Kezd azzal, hogy leírod a projekt célját. Írd le a README-ben, vagy hozz létre egy különálló VISION fájlt. Ha van bármi más ami segít, mint például egy projekt roadmap, akkor tedd elérhetővé azt is. + +A tiszta, jól dokumentált elképzelés segít fókuszálni és elkerülni azt, hogy más hozzájárulók felesleges vagy oda nem illő dolgokkal járuljanak hozzá. + +Például @lord észrevette, hogy a projekt vízió segített neki abban, hogy eldöntse, hogy melyik kéréssel töltse az idejét. Új karbantartóként sajnálta, hogy nem ragaszkodott a projektjének hatóköréhez, amikor megkapta az első, funkcióra irányuló kérést a [Slate-hez](https://github.com/lord/slate). + + + +### Kommunikáld az elvárásaid + +A szabályok leírása idegesítő lehet. Időnként úgy érzed, mintha más emberek viselkedését szabályoznád, vagy mintha kiölnél minden szórakoztató dolgot a projektből. + +Ugyanakkor megfelelően leírva és jól végrehajtva, a jó szabályok támogatják a karbantartókat. Megakadályozzák, hogy olyan dolgokba menj bele, amelyekbe nem akarsz. + +A legtöbb ember, aki a projekttel találkozik, semmit sem tud rólad vagy a körülményeidről. Feltételezhetik, hogy fizetést kapsz a munkádért, különösen, ha rendszeresen használják, és függnek a projekttől Lehet, hogy egy ideig sok időt töltesz a projekttel, de az is lehet, hogy most egy új munkával, vagy épp a családdal foglalkozol. + +Mindez teljesen rendben van! Csak legyél biztos abban, hogy mások is tudnak erről. + +Ha a projekt fenntartása részmunkaidős vagy tisztán önkéntes, akkor legyél őszinte abban, hogy mennyi időd van rá. Ez nem egyezik meg azzal, hogy szerinted mennyi időt igényelne a projekt, vagy azzal, hogy mennyi időt várnak el mások tőled. + +Néhány szabály, amelyeket érdemes leírni: + +* Hogyan vizsgálod meg és fogadod el a hozzájárulást (_Meg vannak követelve a tesztek? Van az issue-khoz sablon?_) +* A hozzájárulások típusai, amelyeket elfogadsz (_Csak egy bizonyos részéhez fogadsz el hozzájárulást a kódnak?_) +* Mikor helyénvaló ismét figyelmeztetni (_például: "7 napon belül várhatsz választ a karbantartótól. Ha ez alatt még sincs visszajelzés, nyugodtan pingeld meg a szálat."_) +* Mennyi időt fogsz a projektre fordítani (_például: "Csak kb. 5 órát foglalkozunk a hetente ezzel a projekttel."_) + +[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), és a [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) mellett számos példa van a karbantartók és közreműködők alapszabályairól rendelkező projektekre. + +### Legyen a kommunikáció nyilvános + +Ne felejtsd el dokumentálni az interakciókat is. Ahol csak lehet, tartsd nyilvánosan a projekttel kapcsolatos kommunikációt. Ha valaki megpróbál privát kapcsolaton keresztül kommunikálni egy funkciókérést vagy támogatási igényt akkor, udvariasan irányítsd egy nyilvános kommunikációs csatornára, például egy levelezőlistára vagy a hibakövető rendszerre. + +Ha személyesen találkozol más karbantartókkal, vagy ha zártkörű döntés születik, akkor is nyilvánosan dokumentáld ezeket a beszélgetéseket, még akkor is, ha csak jegyzeteket írsz. + +Így bárki, aki csatlakozik a közösséghez, ugyanazt az információt éri el, mint az, aki már évek óta tagja a közösségnek. + +## Meg kell tanulni nemet mondani + +Leírtad a dolgokat. Ideális esetben mindenki elolvassa a dokumentációt, de a valóságban ez nem mindig van így, ezért figyelmeztetned kell majd másokat arra, hogy ez a tudás létezik. + +Ha mindent leírsz, az segít megszüntetni azokat a helyzeteket, amikor szükség van a szabályok érvényesítésére. + +Nemet mondani nem kellemes, de a _"Hozzájárulásod nem felel meg a projekt kritériumoknak"_ kevésbé személyeskedő, mint a _"Nem tetszik ez a hozzájárulásod"_. + +Sok helyzetben kell majd nemet mondanod, amelyekkel karbantartóként találkozol: olyan funkciókérések, amelyek nem felelnek meg az alkalmazási körnek, valaki félrevisz egy beszélgetést, amellyel felesleges munkát generál másoknak. + +### Legyen barátságos a beszélgetés + +A legfontosabb helyek, ahol gyakorolni fogod a nemet mondást, azok az issue-k és a beolvasztási kérelmek. Projekt karbantartóként elkerülhetetlen lesz az a helyzet, amikor olyan javaslatokat kapsz, amelyeket nem akarsz elfogadni. + +Lehet, hogy a hozzájárulás megváltoztatja a projekt célját, vagy nem felel meg a jövőképének. Talán az ötlet jó, de a megvalósítás rossz. + +Az indoktól függetlenül lehetséges tapintatosan kezelni azokat a hozzájárulásokat, amelyek nem felelnek meg a projekt normáinak. + +Ha olyan hozzájárulást kapsz, amelyet nem akarsz elfogadni, akkor az első reakciód lehet hogy az, hogy figyelmen kívül hagyod, vagy úgy teszel, mintha nem látnád. Ha így teszel, akkor a másik személy érzéseit megsértheted, vagy akár más, lehetséges hozzájárulók kedvét is elveszed a részvételtől. + + + +Ne hagyj nyitva nem kívánt hozzájárulást, csak azért, mert bűntudatot éreznél attól, hogy lezárod. Az idő múlásával a megválaszolatlan kérdések és a nem kívánt beolvasztási kérelmek sokkal stresszesebbé és elrettentőbbé teszik a projekttel való munkát. + +Sokkal jobb, ha azonnal lezárod a hozzájárulást, ha nem akarod elfogadni. Ha a projekted már eleve nagy feladatlistával rendelkezik, akkor itt van @steveklabnik javaslata arra, hogy [hogyan priorizáld hatékonyan az issue-kat](https://words.steveklabnik.com/how-to-be-an-open-source-gardener). + +Ugyanakkor a hozzájárulások rendszeres figyelmen kívül hagyása negatív jelet küldhet a közösségnek. A projekthez való hozzájárulás elrettentő is lehet, különösen, ha valaki először próbálja. Még ha nem is fogadod el az általa benyújtott hozzájárulást, becsüld meg azt a személyt aki benyújtotta, és mondj köszönetet az érdeklődése iránt, ez nagy dicséret! + +Ha nem akarsz elfogadni egy hozzájárulást: + +* **Köszönd meg neki** a hozzájárulást +* **Magyarázd el, miért nem illik bele a projekt kritériumokba,** vagy ha lehetséges, javasolj egyértelmű dolgokat a javításra. Legyél határozott, de kedves. +* **Linkeld be a releváns dokumentációkat,** ha vannak. Ha arra leszel figyelmes, hogy rendszeresen kapsz olyan kéréseket, amelyeket nem akarsz elfogadni, akkor add hozzá a dokumentációhoz, ezzel elkerülheted, hogy mindig magadat ismételd. +* **Zárd le a kérést** + +Nem kell több a válaszba mint 1-2 mondat. Például a [celery](https://github.com/celery/celery/) felhasználója jelentett egy Windows-hoz kapcsolódó hibát, erre @berkerpeksag [így válaszolt](https://github.com/celery/celery/issues/3383): + + + +Ha megijeszt a nemet mondás, ne aggódj, nem vagy egyedül, lásd @jessfraz [írását erről](https://blog.jessfraz.com/post/the-art-of-closing/): + +> Számos, különböző nyílt forráskódú projektekből beszéltem karbantartókkal – Mesos, Kubernetes, Chromium –, és abban mindannyian egyetértettek, hogy a legkeményebb rész a "Nem"-et mondás egy olyan javításra, amelyet nem akarsz. + +Ne érezd bűntudatot azért, mert nem fogadsz el egy hozzájárulást. Az első szabálya a nyílt forráskódnak @shykes [szerint](https://twitter.com/solomonstre/status/715277134978113536): _"A nem az átmeneti, az igen az örökös."_ Bár jó érzés a másik ember lelkesedését látni, a hozzájárulás elutasítása nem jelenti a mögötte álló személy elutasítását. + +Végül, ha a hozzájárulás nem elég jó, akkor nem vagy köteles elfogadni azt. Légy kedves és közreműködő, ha az emberek hozzájárulnak a projekthez, de csak azokat a változásokat fogadd el, amelyektől valóban azt hiszed, hogy a projekt jobbá válik. Minél gyakrabban gyakorolod a nemet mondást, annál könnyebbé válik. + +### Legyél pro-aktív + +A nemkívánatos hozzájárulások mennyiségének csökkentése érdekében mindenekelőtt mutasd be a hozzájárulási útmutatóban a projekt hozzájárulások benyújtásának és elfogadásának folyamatát. + +Ha túl sok gyenge színvonalú hozzájárulást kapsz, kérd meg a közreműködőket, hogy végezzenek el előtte egy kis munkát, például: + +* Töltsék ki a hibához, vagy beolvasztási kérelemhez rendelt űrlapot, vagy ellenőrző listát +* Nyissanak egy issue-t, mielőtt beolvasztási kérelmet adnak fel + +Ha nem követik a szabályokat, akkor azonnal zárd le a jelzést és hivatkozd meg a dokumentációt. + +Noha ez a megközelítés kezdetben kellemetlennek tűnik, a pro-aktív fellépés mindkét fél számára jó. Csökkenti annak az esélyét, hogy valaki sok elpazarolt órát fordítson egy beolvasztási kérelemre, amelyet nem fogsz elfogadni. Emellett a Te munkaterhelésed is könnyebben kezelhetővé válik. + + + +Időnként, amikor nemet mondsz, a potenciális közreműködőt felháboríthatja a döntés vagy kritizálhatja azt. Ha a viselkedése ellenségessé válik, akkor [tegyél lépéseket a helyzet enyhítésére](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) vagy akár el is távolíthatod a közösségből a személyt, ha meg sem próbál konstruktívan együttműködni. + +### Erősítsd a mentorálást + +Lehet, hogy valaki a közösségedben rendszeresen nyújt be olyan hozzájárulásokat, amelyek nem felelnek meg a projekt normáinak. Mindkét fél számára frusztráló lehet az ismételt visszautasítás. + +Ha azt látod, hogy valaki lelkesedik a projekted iránt, de egy kis segítségre van szüksége, légy türelmes. Mindig magyarázd el világosan, hogy miért nem felelnek meg a hozzájárulások a projekt elvárásainak. Próbálj ajánlani egy könnyebb vagy kevésbé bonyolult feladatot, például egy feladatot a _"good first issue"_ jelöléssel, hogy a megtegye az első lépéseket. Ha van időd, akkor fontold meg a mentorálásukat az első hozzájárulásuk alkalmával, vagy keress meg valaki mást a közösségében, aki hajlandó mentorálni őket. + +## Használd ki a közösség erejét + +Nem kell mindent egymagad csinálni. A projekt közösség okkal létezik! Ha még nincs aktív közreműködő közösség, de már sokan vannak benne, akkor is próbáld munkára fogni őket. + +### Oszd el a munkaterhelést + +Ha szeretnél másokat bevonni, akkor kérdezz körbe. + +Az új közreműködők megszerzésének egyik módja az, hogy kifejezetten [olyan issue-kat nevezel meg, amelyek elég egyszerűek a kezdők számára](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). A GitHub segíti ezen issue-k kiemelésén és láthatóvá tételét. + +Amikor azt látod, hogy az új résztvevők rendszeresen hozzájárulnak a projekthez, akkor ismerd el a munkájukat azzal, hogy nagyobb felelősséget adsz számukra. Dokumentáld le, hogy hogyan válhat valaki a projekt irányító tagjává, ha azt szeretné. + +Ösztönözz másokat arra, hogy [részt vegyenek a projekt irányításában](../building-community/#a-projekt-tulajdonjogának-megosztása) ezzel jelentősen csökkented a saját terhelésed, mint ahogy @lmccart észrevette ezt a saját projektjénél, [p5.js](https://github.com/processing/p5.js). + + + +Ha a projektet magára kell hagynod rövid vagy akár hosszabb időre, akkor nincs semmi szégyelleni való abban, ha megkérsz mást, hogy vegye át a helyed. + +Ha mások is lelkesek a projekt irányát illetően, akkor add meg nekik a hozzáférést, vagy formálisan is add át az irányítást. Ha valaki forkolta a projektet, és máshol aktívan fenntartja azt, fontold meg az eredeti projekt csatlakozását ehhez. Nagyszerű, ha sok ember akarja azt, hogy a projekt tovább éljen! + +@progrium [úgy találta](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) hogy a projekt vízió dokumentálása a [Dokku](https://github.com/dokku/dokku) esetén, segített abban, hogy a célok tovább éljenek még akkor is, amikor ő már nem vesz részt a projektben: + +> Egy wiki oldalon leírtam, hogy mit és miért akartam. Valami oknál fogva meglepetésnek számított nekem, hogy a karbantartók elkezdték vinni a projektet ebbe az irányba! Hogy pontosan úgy történt ez, ahogy én csináltam volna? Nem mindig. De mégis közelebb hozta a projektet ahhoz, amit leírtam. + +### Hagyd, hogy mások építsék ki a számukra szükséges megoldásokat + +Ha egy potenciális közreműködő eltérő véleményen van arról, hogy mit kellene a projektben megvalósítani, akkor érdemes udvariasan ösztönözni őt, hogy saját forkon dolgozzon. + +A projekt forkolása (elágaztatása) nem jelent rossz dolgot. A projekt lemásolása és módosítása a legjobb része a nyílt forráskódnak. A közösség tagjainak ösztönzése arra, hogy saját forkon dolgozzanak alkalmas arra, hogy saját kreativitásukat kiélhessék anélkül, hogy ez ütközne a projekted eredeti víziójával. + + + +Ugyanez a megoldás jó akkor is, ha valaki komolyan akarna egy megoldást a projektben valamire, de erre neked már nincs kapacitásod. API-k és testre szabható hook-ok biztosítása lehetővé teszi mások számára, hogy anélkül elégítsék ki a szükségleteiket, hogy a projektet módosítani kellene közvetlenül. @orta [szerint](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) a CocoaPods plugin megjelenése vezetett "néhány nagyon érdekes ötlethez": + +> Szinte elkerülhetetlen, hogy ha egy projekt nagyméretűvé válik, a karbantartóknak sokkal konzervatívabbá kell válniuk az új kódok bevezetése terén. Az rendben van, ha tudod mondani a "nem" szót, de sok embernek van valódi, jogos igénye. Emiatt a megoldást végül platformmá alakítod át. + +## Használj robotokat + +Ahogy vannak olyan feladatok, amelyekben mások segítenek, úgy vannak olyan feladatok is, amelyeket nem embereknek kell csinálnia. A robotok a barátaid. Használd őket, hogy megkönnyítsd az életét karbantartóknak. + +### Szükség van tesztekre és egyéb ellenőrzésekre a kód minőségének javítása érdekében + +A projekt automatizálásának egyik legfontosabb módja a tesztek hozzáadása. + +A tesztek segítenek a közreműködőknek, hogy biztosak legyenek abban, hogy semmit sem rontanak el. Ezenkívül megkönnyítik az észrevételek gyors áttekintését és elfogadását. Minél jobban és gyorsabban reagálsz, annál elkötelezettebbé válhat a közösség. + +Állíts be automatikus teszteket, amelyek az összes bejövő hozzájárulásra futnak, és győződj meg arról, hogy a teszteket a közreműködők könnyen, a saját gépeiken is futtathatják. Mielőtt beküldenék a hozzájárulásokat, követeld meg, hogy az összes kódminőségi követelményt teljesítse, minden teszten átmenjen. Itt egy segítség a minimális minőségi követelmények megkövetelésére: [Kötelező ellenőrzések](https://help.github.com/articles/about-required-status-checks/), a GitHub segít abban, hogy ellenőrzés nélkül a hozzájárulás ne kerüljön beolvasztásra. + +Ha teszteket adsz hozzá, akkor bizonyosodj meg arról, hogy elmagyaráztad azt a CONTRIBUTING.md fájlban, hogy hogyan működnek. + + + +### Használj eszközöket az alapvető karbantartási feladatok automatizálásához + +A jó hír egy népszerű projekt fenntartásához az, hogy más karbantartók valószínűleg hasonló problémákkal már szembesültek és megoldást találtak rá. + +[Számos eszköz elérhető](https://github.com/showcases/tools-for-open-source) amelyek a karbantartók munkájának különböző részeit automatizálják. Néhány példa: + +* [semantic-release](https://github.com/semantic-release/semantic-release) automatizálja a release-elést +* [mention-bot](https://github.com/facebook/mention-bot) a beolvasztási kérelemben megemlíti automatikusan a lehetséges embereket, akik a kódot majd átnézik (kód review) +* [Danger](https://github.com/danger/danger) segít automatizálni a kód review-t +* [no-response](https://github.com/probot/no-response) lezárja azokat az issue-kat, amelyekben az issue szerzője nem válaszolt a további információkérésre +* [dependabot-preview](https://github.com/marketplace/dependabot-preview) minden nap ellenőrzi a függőségeket, ha talál frissebb verziót, akkor automatikusan beolvasztási kérelmet készít az új verzió számmal + +A hiba jelzésekhez és más általános hozzájárulásokhoz a GitHub biztosít egy [hiba jelzés és beolvasztási kérelem formanyomtatványt](https://github.com/blog/2111-issue-and-pull-request-templates), amellyel egyszerűsíteni és egységesíteni tudod ezek beadását. @TalAter készített egy [Választásos Kalandjátékot](https://www.talater.com/open-source-templates/#/) hogy segítse ezen formanyomtatványok elkészítését. + +Az email értesítések kezeléséhez be tudod állítani az [email szűrőket](https://github.com/blog/2203-email-updates-about-your-own-activity) amellyel a prioritás megadható. + +Ha még jobban akarod csinálni, akkor a stílus útmutatók és linterek segítenek abban, hogy a hozzájárulások könnyebben áttekinthetőbbek és beolvaszthatók legyenek. + +Ellenben, ha a szabályok túl komplikáltak, akkor akadályozzák a hozzájárulást a projekthez. Figyelj arra, hogy annyi szabályt adj hozzá, amely feltétlenül szükséges ahhoz, hogy mindenkinek könnyebb legyen az élete. + +Ha nem vagy biztos abban milyen eszközt kellene használnod, akkor nézz meg más, ismert projekteket, különösen a te ökoszisztémádhoz tartozók közül. Például megnézheted, hogy hogyan néz ki egy hozzájárulási folyamat más Node modulok esetén? Hasonló eszközök és megközelítések alkalmazása segít abban, hogy a folyamatod a hozzájárulók számára már ismert legyen. + +## Teljesen rendben van, ha szünetet tartasz + +Eddig a nyílt forráskódú munka örömet okozott neked, de lehet hogy most már túlterhel téged, ami miatt kerülöd, és emiatt bűntudatod van. + +Lehet, hogy túlterheltnek érzed magad, vagy szorongást okoz, amikor a projektjeidre gondolsz, és mindeközben a hibajelzések és a beolvasztási kérelmek felhalmozódnak. + +A kiégés létező és széles körben ismert probléma a nyílt forráskódú munkákban, különösen a karbantartók körében. Karbantartóként a megelégedettséged megkérdőjelezhetetlen követelmény a nyílt forráskódú projekted fennmaradásához. + +Magától értetődik, hogy szükség van pihenésre! Nem szabad elodázni a pihenést addig, amíg kiégsz. Például @brettcannon, a Python fejlesztője úgy döntött, hogy [egy hónapos vakációt vesz ki](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) 14 éve folyamatosan tartó, önkéntes OSS munka után. + +Mint minden más munka esetén a rendszeres pihenők tartása felfrissít, boldogabbá teszt és fokozza a munkád iránti vágyadat. + + + +Gyakran úgy érzed nehéz pihenőt tartani, mert mindenki téged akar. Vannak akik bűntudatot éreznek, ha pihenni mennek. + +Próbáld kialakítani azt, hogy a legjobb legyen a felhasználóknak és a közösségnek, amikor távol vagy a projekttől. Ha nem találod meg a támogatást ehhez, akkor is tarts szünetet. Határozottan és biztosan kommunikáld azt, amikor nem vagy elérhető, nehogy az emberek összekeverjék azzal, hogy nem szándékosan válaszolsz nekik, vagy nem vagy reszponzív. + +A szünetek nemcsak a vakációk idejére vonatkoznak. Ha nem akarsz hétvégén, vagy munkaidőben nyílt forráskódú munkát végezni, kommunikáld ezt mások felé, így tudni fogják, hogy ne zavarjanak ezen idő alatt téged. + +## Legfontosabb, hogy vigyázz magadra! + +A népszerű projekt fenntartása más készségeket igényel később, mint a projekt elején. Karbantartóként vezetői és személyes készségeket gyakorolsz majd olyan szinten, amelyet kevés ember tapasztal meg. Noha ezt nem mindig könnyű kezelni, az egyértelmű határok meghatározása, és csak olyan dolgok elvégzése ami számodra is elfogadható, segítenek abban, hogy boldog, kipihent és produktív maradj. diff --git a/_articles/hu/building-community.md b/_articles/hu/building-community.md new file mode 100644 index 0000000000000000000000000000000000000000..2e1051c4336d0ab9945c96bbaa0f72d7ca7fb6aa --- /dev/null +++ b/_articles/hu/building-community.md @@ -0,0 +1,276 @@ +--- +lang: hu +title: Építs befogadó közösséget +description: Közösség építése, amely bátorítja az embereket a használatra, a részvételre és a projekt hírnevének terjesztésére. +class: building +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +--- + +## Sikeres projekt összeállítása + +Elindítottad a projektet, próbálod ismertté tenni, és az emberek érdeklődnek iránta. Fantasztikus! De hogy fogod őket megtartani? + +A befogadó közösség egy befektetés a projekt jövőjébe és megítélésébe. Ha a projekt éppen most kezdi el fogadni az első hozzájárulásokat, akkor kezd azzal, hogy az első közreműködők pozitív tapasztalatokat kapjanak, és könnyítsd meg nekik, hogy rendszeresen visszatérjenek. + +### Érezzék az emberek, hogy szívesen látod őket + +Gondolj a projekt közösségére például úgy, ahogyan @MikeMcQuaid amit ő [résztvevői tölcsérnek](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/) nevezett el: + + + +A közösség felépítése során fontold meg, hogy a tölcsér tetejéről valaki (potenciális felhasználó) hogyan tud eljutni a tölcsér aljára (aktív karbantartó). Cél, hogy minden résztvevő tapasztalatát a projektről javítsd ezeken a szakaszokon. Amikor az emberek könnyen érnek el eredményt, az ösztönözni fogja őket, hogy még többet tegyenek. + +Kezd a dokumentációkkal: + +* **Tedd egyszerűvé, hogy valaki könnyen használhassa a projektedet!** [Egy barátságos README](../starting-a-project/#readme-írása) és tiszta kód példák mindenkit hozzásegítenek ahhoz, hogy könnyen el tudjanak indulni. +* **Tisztán és érthetően magyarázd el, hogy hogyan lehet hozzájárulni**, használd a [CONTRIBUTING fájlodat](../starting-a-project/#részvételi-irányelvek-leírása) és a hibajelzéseket tartsd naprakészen. +* **Good first issues**: Az új hozzájárulókat segíti az, ha egyértelműen [jelezve van címkével az issue, amely kezdőknek ajánlott](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). A GitHub kiemeli ezeket az issue-kat, és ezzel segíti a hasznos hozzájárulásokat úgy, hogy a hozzájáruló szintjének megfelelő hibát ajánl megoldásra. + +[A GitHub 2017. évi nyílt forráskódú felmérése](http://opensourcesurvey.org/2017/) azt mutatta ki, hogy a félkész és zavaros dokumentáció a legnagyobb probléma a felhasználók számára. A jó dokumentáció beszippantja az embereket a projektbe: egyszer csak valaki nyit egy hibajelzést, vagy beküld egy beolvasztási kérelmet. Használd ki ezeket a lehetőségeket, hogy az emberek tovább mozogjanak lefelé a _résztvevői tölcséren_. + +* **Ha valaki újként jelenik meg a projektben, akkor köszönd meg neki az érdeklődését!** Egyetlen egy negatív tapasztalat is elég ahhoz, hogy valaki ne jöjjön vissza többé a projekthez. +* **Legyél reszponzív!** Ha hónapokig nem válaszol a problémájára valakinek, nagy esély van rá, hogy elfelejti a projektedet. +* **Légy nyitott gondolkodású az új hozzájárulások elfogadásakor!** Sok hozzájáruló hibák jelzésével vagy apró javításokkal kezdi. [Számos módja van a hozzájárulásoknak](../how-to-contribute/#mit-jelent-a-hozzájárulás) a projekthez. Hagy segítsenek az emberek úgy, ahogy ők szeretnének. +* **Ha van olyan hozzájárulás, amivel nem értesz egyet,** akkor köszönd meg az ötletet, és [magyarázd el miért](../best-practices/#meg-kell-tanulni-nemet-mondani) nem felel meg a projekt víziónak, és csatold a hivatkozásokat a dokumentációra. + + + +A nyílt forráskódú közreműködők többsége "alkalmi közreműködő": olyan emberek, akik csak alkalmanként járulnak hozzá a projekthez. Előfordulhat, hogy egy alkalmi közreműködőnek nincs ideje teljes mértékben felkészülni a projektre, ezért az a feladatod, hogy megkönnyítsd számukra a hozzájárulást ilyen esetekben is. + +Más közreműködők ösztönzése számodra is hasznos befektetés. Ha támogatod a projekt legnagyobb rajongóit abban, hogy azon dolgozzanak amin szeretnének, akkor kevesebb lesz a nyomás rajtad, hogy mindent te csinálj. + +### Dokumentálj mindent + + + +Amikor új projektet indítasz, először természetesnek tűnhet, hogy a munkádat nem publikálod. De a nyílt forráskódú projektek akkor sikeresek, ha a folyamatait is nyilvánosan dokumentálod. + +Amikor leírod a dolgokat, több ember vehet részt a projekt minden lépésében. Segíthet akár olyan dolgokban is, amelyekre még nem is gondoltad, hogy szükséged van. + +A dolgok leírása nem csupán a műszaki dokumentációt jelent. Bármikor, amikor azt érzed, hogy le kell írni valamit, vagy egy magánbeszélgetést folytattál a projektről, gondolkozz el arról, hogy nyilvánosságra tudod-e hozni azt. + +Legyen átlátható a projekt ütemterve, a várt hozzájárulások típusai, vagy azok áttekintésének módja és akár az is, hogy miért hoztál meg bizonyos döntéseket. + +Ha több felhasználó jelzi ugyanazt a problémát, akkor dokumentáld a válaszokat a README részben. + +Találkozók alkalmával fontold meg a megjegyzések, vagy döntések közzétételét az adott kérdésben. Az ilyen szintű átláthatóság miatt kapott visszajelzések lehet meg fognak majd lepni. + +Mindennek a dokumentálása az te általad végzett munkára is vonatkozik. Ha a projekt lényeges frissítésén dolgozol, akkor add fel beolvasztási kérelemként és jelöld meg folyamatban lévő munkaként (WIP). Ily módon más emberek, már korán bekapcsolódhatnak a folyamatba és így maguknak érzik azt. + +### Legyél reszponzív + +Amint [ismertté próbálod tenni a projektet](../finding-users), az emberek visszajelzéseket fognak küldeni neked. Lesznek kérdéseik a működéséről, vagy épp segítségre lehet szükségük az induláshoz. + +Próbálj azonnal reagálni, ha valaki hibajegyet vagy beolvasztási kérelmet nyújt be, vagy kérdést tesz fel a projekttel kapcsolatban. Ha gyorsan reagálsz, az emberek úgy érzik, hogy részesei a párbeszédnek, és lelkesebben fognak részt venni. + +Még ha a kérelmet nem is tudod azonnal átvizsgálni, a korai befogadás segít növelni az elkötelezettséget. Így válaszolt @tdreyno a [Middleman](https://github.com/middleman/middleman/pull/1466) egyik beolvasztási kérelmére: + + + +[Egy Mozilla tanulmány szerint](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) azoknak a válaszadóknak, akik 48 órán belül megkapták a kód review eredményét, sokkal magasabb volt a visszatérési aránya a projekthez, és a hozzájárulásuk ahhoz. + +A projekttel kapcsolatos beszélgetések az internet más részein is zajlanak, például a StackOverflow, a Twitter vagy a Reddit oldalain. Ezen helyek egy részén értesítéseket állíthatsz be, így figyelmeztetést kapsz, ha valaki megemlíti a projektedet. + +### Biztosíts egy helyet a közösségednek + +Két oka is van, hogy miért kell a közösségnek egy állandó helyet biztosítani, ahol összejöhetnek. + +Az első ok ők maguk. Segíts az embereknek megismerni egymást. A közös érdeklődésű emberek szeretnének egy helyet, ahol lehet beszélgetni. És amikor a kommunikáció nyilvános és hozzáférhető, bárki elolvashatja a múltbeli archívumokat, hogy felvegye a ritmust, és hogy részt vegyen a párbeszédben. + +A másik ok te vagy. Ha nem biztosítasz egy nyilvános helyet az embereknek, ahol a projektjéről lehet beszélni, akkor valószínűleg közvetlenül téged keresnek meg. A kezdetben ez könnyűnek tűnhet, hiszen a magánüzenetekre csípőből válaszolunk. De az idő múlásával, különösen, ha a projekt népszerűvé válik, kimerülten fogod magad érezni. Állj ellen annak a kísértésnek, hogy privát módon kommunikálj az emberekkel a projekttel kapcsolatosan. Ehelyett irányítsd őket egy kijelölt, és nyilvános csatornára. + +A nyilvános kommunikáció egyszerű, ha arra kéred az embereket, hogy nyissanak egy hibajegyet, ahelyett, hogy közvetlenül e-mailen küldnének azt, vagy megjegyzést fűznének a blogodhoz. Beállíthatsz egy levelezőlistát, vagy létrehozhatsz egy Twitter fiókot, Slack vagy akár egy IRC csatornát arra, hogy az emberek beszéljenek a projektedről. De akár próbálkozhatsz mindegyikkel! + +[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) minden második héten biztosít időt arra, hogy segítse a közösség tagjait: + +> Kopsnak minden második héten van elkülönített ideje arra, hogy segítséget és útmutatást nyújtson a közösség számára. A Kops fenntartói megállapodtak abban, hogy külön időt fordítanak az újonnan érkezőkkel való együttműködésre, a PR-ekkel kapcsolatos segítségnyújtásra és az új funkciók megvitatására. + +A nyilvános kommunikáció alól kivételt képeznek: a 1) biztonsági kérdések és a 2) magatartási kódex megsértése. Az embereknek mindig képesnek kell lenniük arra, hogy ezeket a kérdéseket privát módon jelentsék be. Ha nem akarod használni a személyes e-mail címed, akkor állíts be egy külön e-mail címet erre a célra. + +## Növeld a közösséget + +A közösség rendkívül erős dolog. Ez a hatalom áldás vagy átok lehet, attól függően, hogy hogyan kezeled. Ahogy a projekt közössége növekszik, vannak olyan módok, amelyek segítenek abban, hogy ez az erő az építés, és ne pusztítás erejévé váljon. + +### Ne tűrd el a helytelen viselkedést + +Bármely népszerű projekt elkerülhetetlenül vonzza azokat az embereket, akik ahelyett, hogy segítséget nyújtanának a közösségnek inkább ártanak neki. Lehet, hogy felesleges vitákat indítanak, felkavaró kritikákat fogalmaznak meg alapvető funkciókról, vagy másokat piszkálnak. + +Tegyél meg mindent, hogy zéró toleranciát tanúsíts az ilyen típusú emberekkel szemben. Ha figyelmen kívül hagyod ezt, akkor a negatív emberek kellemetlenné teszik a közösség többi tagjának részvételét a projektben, akik akár emiatt még távozhatnak is. + + + +A projekt alapvető céljairól folytatott rendszeres vita zavarhat másokat, köztük téged is, és elvonja a figyelmet a fontos feladatokról. A projektbe érkező új emberek láthatják ezeket a beszélgetéseket, és emiatt lehet nem akarnak részt venni majd benne. + +Ha negatív viselkedést látsz a projektben, azt hozd nyilvánosságra. Magyarázd el kedvesen, de határozott hangon, hogy miért nem fogadható el ez a viselkedés. Ha a probléma továbbra is fennáll, akkor lehet, hogy [fel kell kérned az érintettet a távozásra](../code-of-conduct/#a-magatartási-kódex-érvényesítése). A [Magatartási kódexed](../code-of-conduct/) konstruktív útmutatást jelenthet az ilyen jellegű beszélgetésekhez. + +### Maradj kapcsolatban + +A jó dokumentáció akkor válik fontosabbá, ha közösséged növekszik. Az alkalmi közreműködők, akik esetleg egyébként nem ismerik a projektet, azért olvassák el a dokumentációt, hogy gyorsan megértsék azt a környezetet, amire szükségük van. + +A CONTRIBUTING fájljában kifejezetten mond el az új közreműködőknek az elindulás módját. Érdemes lehet erre a célra egy külön fejezetet létrehozni. Például a [Django](https://github.com/django/django) projektnek van egy speciális nyitóoldallal, amelyen az új közreműködőket fogadják. + + + +A hibalistában azon hibákat címkézd meg, amelyek különböző hozzájárulás típusokat igényelnek, például: [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, vagy _"documentation"_. [Ezek a címkék](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) segítik az újonnan érkezőket abban, hogy gyorsan átnézzék a listát és el tudják kezdeni a munkát. + +Végül, de nem utolsó sorban a dokumentáció alapján érezzék az emberek, hogy szívesen látod őket bármely folyamatában a projektnek. + +Általában nem fogsz közvetlenül minden emberrel kommunikálni, aki megfordul a projekten. Lehet, hogy lesznek olyan hozzájárulások, amelyeket azért nem kapsz meg, mert valaki elrettent a projekttől, vagy nem tudta, hogy hol kezdje. Akár néhány kedves szó is elég lehet ahhoz, hogy megakadályozd, hogy valaki csalódottan hagyja el a projektet. + +Itt egy példa, hogy hogyan kezdj a [Rubinius](https://github.com/rubinius/rubinius/) projektben, [a CONTRIBUTING útmutatójuk](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md): + +> Mindenekelőtt azzal szeretnénk kezdeni, hogy köszönjük azt, hogy használod a Rubinius-t. Ez a projekt szeretetteljes munkát jelent, és nagyra értékeljük az összes felhasználót, aki hibákat észlel, javít a teljesítményben és segítséget nyújt a dokumentációban. Minden hozzájárulás hasznos, ezért köszönjük a részvételed. Kérjük néhány iránymutatást tarts be, hogy sikeresen meg tudjuk oldani a problémádat. + +### A projekt tulajdonjogának megosztása + + + +Az emberek örömmel járulnak hozzá a projektekhez, ha maguknak érzik azt. Ez nem azt jelenti, hogy át kell szabni a projekt víziódat, vagy el kell fogadni a nem kívánt hozzájárulásokat. De minél többet adsz ebből másoknak, annál jobban magukénak fogják érezni. + +Nézd meg, hogyan találhatod meg a módját, hogy a lehető legnagyobb mértékben megoszd a tulajdont a közösséggel. Íme néhány ötlet: + +* **Állj ellen az egyszerű (nem kritikus) hibák javításának.** Ehelyett használd ezeket a hibákat arra, hogy új segítőket toborozz toborzására, vagy mentorálj valakit, aki szeretne hozzájárulni. Bár furcsának tűnhet, de ez a befektetés idővel megtérül. Például a @michaeljoseph megkérte az egyik közreműködőt, hogy nyújtson be beolvasztási kérelmet egy alábbi, [Cookiecutter] (https://github.com/audreyr/cookiecutter) hibával kapcsolatosan, ahelyett, hogy saját maga javította volna ki. + + + +* **Állíts össze egy CONTRIBUTORS vagy AUTHORS fájlt a projektben,** amely listáz mindenkit aki hozzájárul a projekthez. Például ahogy a [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) csinálja. + +* Ha széles közösséged van, **akkor küldj ki hírlevelet vagy vezess blogot** amelyen megköszönöd a hozzájárulásokat. A Rust-nak a [Heti Rust](https://this-week-in-rust.org/) és a Hoodie-nak a [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) két jó példa erre. + +* **Minden közreműködő kapjon commit jogot.** @felixge szerint az emberek [sokkal aprólékosabban kidolgozzák a hozzájárulásukat](https://felixge.de/2013/03/11/the-pull-request-hack.html), és még több karbantartót lehet bevonni, akik esetleg korábban passzívak voltak. + +* Ha a projekted a GitHub-on van, **akkor mozgasd a projektet át a személyes fiókod alól a [Szervezeti Fiók](https://help.github.com/articles/creating-a-new-organization-account/)** alá és adj hozzá legalább egy admint még biztonság esetére. Az Szervezeti Fiók alkalmasabb külső résztvevők bevonására. + +A valóságban [a legtöbb projektnek](https://peerj.com/preprints/1233.pdf) csak egy, két karbantartója van. Minél nagyobb a projekted, és a közösséged, annál könnyebb segítséget találni. + +Bár nem mindig válaszolnak a felhívásodra, de egy jelzés kiküldése növeli az esélyét, hogy valaki reagál majd rá. És minél előbb megteszed ezt, annál hamarabb segíthetnek az emberek. + + + +## Konfliktusok megoldása + +A projekt korai szakaszában a fontos döntések meghozatala egyszerű. Ha akarsz csinálni valamit, akkor csak megcsinálod. + +Ahogy a projekt népszerűbbé válik, egyre több embert érdekelnek majd az általad meghozott döntések. Még ha nem is rendelkezel nagy közreműködő közösséggel, de a projektnek már sok felhasználója van, akkor találni fogsz olyan embereket, akik a döntéseket mérlegelni fogják, vagy a saját kifogásaikat megfogalmazzák. + +Nagyrészt barátságos és tiszteletteljes közösség esetén és nyíltan dokumentált folyamat esetén találni fogsz megoldást. De néha olyan helyzetbe kerülhetsz, amit kicsit nehezebb lesz megoldani. + +### Viselkedéseddel mutass példát + +Ha a közösség egy nehéz kérdéssel kerül szembe, akkor emelkedetté válhat a hangulat. Az emberek dühösek vagy csalódottak lehetnek, és ezt egymáson vagy épp rajtad vezethetik le. + +Mint karbantartó az a feladatod, hogy ezt a szituációt ne engedd eszkalálódni. Még ha határozott véleményed is van az adott témában, próbáld felvenni a moderátor és az egyeztető szerepet inkább ahelyett, hogy fejest ugranál a csatározásba, és a nézetedet erőltetnéd. Ha valaki barátságtalan, vagy kisajátítja a beszélgetést, akkor [azonnal cselekedj](../building-community/#ne-tűrd-el-a-helytelen-viselkedést), hogy a beszélgetés udvarias és produktív maradjon. + + + +Mások útmutatást kérnek tőled, mutass jó példát. Bátran kifejezheted a csalódottságod, szomorúságod vagy aggodalmadat, de ezt mindig nyugodtan tedd. + +A nyugalom megtartása nem könnyű, de ennek demonstrálása a projekt vezetés által javítja a közösséget. Az internet meg fogja köszönni. + +### A README-t alkotmányként kezeld + +A README fájlod [több mint utasítások összessége](../starting-a-project/#readme-írása). Ez egy olyan hely, ahol beszélhetsz a céljaidról, a termék jövőképéről és az ütemtervről. Ha az emberek túlzottan arra koncentrálnak, hogy megvitatják egy adott funkció értékességét, akkor előfordulhat, hogy át kell értékelned a README-t és még pontosabban kell definiálnod a projekt vízióját. A README szem előtt tartása személytelenebbé teszi a beszélgetést, így az konstruktív maradhat. + +### Az útra figyelj, ne a végcélra + +Egyes projektek szavazási folyamatot használnak a nagyobb döntések meghozatalához. Bár a szavazás első pillantásra ésszerű, a szavazás inkább a "válasz" elérésére helyezi a hangsúlyt, ahelyett, hogy meghallgatná és kezelné a véleményeket. + +A szavazás politikai jellegűvé válhat, amikor a közösség tagjai nyomást gyakorolnak egymásra, hogy egymást előnyben részesítsék, vagy bizonyos módon szavazzanak. Nem mindenki szavaz, függetlenül attól, hogy a [néma többségről](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users), vagy a jelenlegi felhasználókról van szó, akik épp nem tudták, hogy szavazás zajlik. + +Időnként a szavazással történik a szükséges döntéshozás. Mindazonáltal, amennyire képes vagy, hangsúlyozd a ["konszenzus keresését"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) a létrehozott konszenzus helyett. + +Konszenzuskeresési folyamat keretében a közösség tagjai megbeszélik a legfontosabb problémákat, amíg úgy nem érzik, hogy mindenkit meg nem hallgattak. Amikor csak apró észrevételek maradnak már csak, akkor a közösség tovább haladhat. A "konszenzuskeresés" elismeri azt, hogy a közösség nem biztos, hogy képes megtalálni a tökéletes választ. Ehelyett egymás meghallgatását, és a beszélgetést részesíti előnyben. + + + +Ha karbantartóként nem használod a konszenzuskeresési folyamatot, akkor is fontos, hogy az emberek tudják, hogy figyelsz rájuk. Érezzék, hogy meghallgatod őket, és elkötelezed magad a problémáik megoldása mellett, ez a tartós módja annak, hogy elkerüld a komolyabb, kiterjedt problémákat. A szavak után lépj a tettek mezejére. + +Ne siess a döntéssel annak érdekében, hogy megold. Mielőtt állást foglalnál egy kérdésben, győződj meg arról, hogy mindenki úgy érzi-e, hogy meghallgatták és hogy minden információ ezzel kapcsolatban nyilvánosságra került. + +### A cselekvés legyen a fókuszban + +A beszélgetés fontos, de különbség van a produktív és a nem produktív beszélgetések között. + +Támogassa a párbeszédet mindaddig, amíg az a megoldást szolgálja. Ha a párbeszéd egyértelműen tárgytalanná, személyeskedővé válik, vagy félrecsúszik, esetleg az emberek lényegtelen, apró részletekkel kezdenek el foglalkozni, akkor ideje leállítani a megbeszélést. + +Ezen beszélgetések továbbengedése nem csak a jelenlegi probléma kezelésére, hanem a közösség egészségére is káros lehet. Azt üzeni, hogy az ilyen típusú beszélgetések megengedettek vagy akár bátoríthatók, ennek következménye, hogy ez visszatarthatja az embereket a jövőbeli kérdések felvetésétől vagy megoldásától. + +Ha már mások minden észrevételét meghallgattad, akkor kérdezd meg magadtól: _"Hogyan visz ez minket közelebb a megoldáshoz?"_ + +Ha a beszélgetés kezd letisztulni, akkor kérdezd meg a csoportot: _"Mi legyen a következő lépés?"_, ezzel továbbra is fókuszálva tartod a beszélgetést. + +Ha egy beszélgetés nyilvánvalóan nem vezet sehova, vagy nincs egyértelmű intézkedés amit végre kell hajtani, vagy az már meg is megtörtént, akkor zárd le a problémát, és indokold meg, miért zártad le. + + + +### Válassz okosan csatát + +Fontos a környezet. Gondold át, hogy kik vesznek részt a vitában, és hogyan képviselik a közösség többi részét. + +A közösség minden tagja ideges, vagy éppen elragadtatott a kérdéssel kapcsolatban? Vagy egy magányos bajkeverő műve az egész? Ne felejts el figyelni a közösség csendes tagjait, nem csak a hangoskodókat halld meg. + +Ha a téma nem a közösség szélesebb körű igényeit képviseli, akkor el kell fogadni az aggódó hangokat. Ha ez egy rendszeresen visszatérő probléma, egyértelmű megoldás nélkül, akkor mutass rá a témával kapcsolatos korábbi megbeszélésekre, és zárd be a szálat. + +### Keress döntéshozókat a közösségben + +Jó hozzáállással, és egyértelmű kommunikációval a legnehezebb helyzetek is megoldhatók. De még egy eredményes beszélgetés után is eltérhet a vélemény arról, hogy hogyan kell folytatni. Ezekre az esetekre keress egy embert vagy embercsoportot, akik döntéshozóként szolgálnak. + +A döntéshozó lehet a projekt karbantartója, vagy akár egy kis embercsoport, akik szavazás alapján hoznak döntést. Ideális az ha, a döntéshozókat és a kapcsolódó folyamatot egy GOVERNANCE fájlban részletezed. + +A döntéshozódnak az utolsó lehetőségnek kell lennie. A megosztó kérdések a közösség növekedésének és tanulásának a lehetőségét jelentik. Ragadd meg ezeket a lehetőségeket, és használd az együttműködési folyamatot a megoldáshoz, amikor csak lehetséges. + +## A nyílt forráskód ❤️ a közösséget + +Az egészséges, virágzó közösségek heti több ezer órát fordítanak a nyílt forráskódra. Számos résztvevő másokra hivatkozik, hogy miért dolgozik – vagy éppen miért nem dolgozik –, a nyílt forráskódon. Ha megtanulod kreatívan használni a közösség erejét, akkor hozzásegítesz valakit majd ahhoz, hogy felejthetetlen élményeket szerezzen a nyílt forráskódban. diff --git a/_articles/hu/code-of-conduct.md b/_articles/hu/code-of-conduct.md new file mode 100644 index 0000000000000000000000000000000000000000..b135eccca468ed15ac7f66f02974ebf0c9bfde1f --- /dev/null +++ b/_articles/hu/code-of-conduct.md @@ -0,0 +1,114 @@ +--- +lang: hu +title: Magatartási kódex +description: Az egészséges és konstruktív közösség építéséhez a magatartási kódex elfogadásával és érvényesítésével lehet hozzájárulni. +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## Miért kell magatartási kódex? + +A magatartási kódex egy olyan dokumentum, amelyben a viselkedéssel kapcsolatos elvárásokat fogalmazzák meg a projekt tagjai számára. A magatartási kódex elfogadásával és betartásával segítheted a közösség egészséges szociális légkörének kialakítását és megtartását. + +A magatartási kódex nem csak a résztvevőket, téged is meg tud védeni. Karbantartóként találkozhatsz olyan lehangoló résztvevőkkel, akik a negatív hozzáállásukkal elkedvetlenítenek és elszívják az energiáidat. + +A magatartási kódex lehetőséget ad arra, hogy az egészséges és konstruktív közösségi viselkedést megtarthasd. A pro-aktív viselkedésed segíthet abban, hogy te vagy a közösség tagjai elfásuljanak a projekteden, és fel tudsz lépni azok ellen, akik a kódex szabályait megsértik. + +## A magatartási kódex létrehozása + +Próbáld létrehozni a magatartási kódexet olyan korán amennyire csak lehet, ideális esetben a projekt indulásakor. + +Az elvárásaid mellett a magatartási kódex az alábbiakat írja még le: + +* Mire érvényes a magatartási kódex? _(csak a hibakövető rendszerre és beolvasztási kérelmekre, vagy más közösségi eseményekre, mint például rendezvények?)_ +* Kikre vonatkozik a magatartási kódex? _(karbantartókra és közösségi tagokra, de vajon vonatkozik-e a szponzorokra?)_ +* Mi történik, ha valaki vét a szabályok ellen? +* Hogyan kell jelenteni, ha szabálysértést tapasztal valaki? + +Lehetőség szerint használj már létező, publikus dokumentumot. A [Contributor Covenant](https://contributor-covenant.org/) egy azonnal használható magatartási kódex, amelyet már több mint 40,000 nyílt forráskódú projekt használ, mint például a Kubernetes, Rails, és a Swift. + +A [Django Code of Conduct](https://www.djangoproject.com/conduct/) és a [Citizen Code of Conduct](http://citizencodeofconduct.org/) szintén nagyon jó minták. + +Helyezd el a CODE_OF_CONDUCT állomány a projekt gyökérkönyvtárában, és hivatkozd meg őket a CONTRIBUTING és README állományokból, hogy mindenkinek látható legyen. + +## Dönts arról, hogy fogod betartatni a szabályzatot + + + +Magyarázd el részletesen, hogy a magatartási kódexnek hogyan szerzel érvényt, **mielőtt** még szabályszegés történne. Ez több szempontból előnyös: + +* Megmutatja, hogy komolyan gondolod, hogy szükség esetén cselekszel. + +* A közösség nyugodtabbnak fogja érezni magát, mert a panaszok ténylegesen felülvizsgálatra kerülnek. + +* Meggyőzi a közösséget arról, hogy a felülvizsgálati folyamat tisztességes és átlátható, ha esetleg valakit felelősségre kell vonni a szabálysértés miatt. + +Praktikus biztosítani egy privát csatornát (pl. e-mail cím), amin a magatartási kódex megsértését jelenteni tudják. Add meg azt is, hogy ki vagy kik kapják a jelentést. Ez lehet egy vagy több karbantartó, esetleg egy külön testület. + +Ne feledd, előfordulhat, hogy épp olyan személyre vonatkozóan érkezik kifogás aki szintén kapja a jelentést. Ebben az esetben adj lehetőséget arra, hogy más személy részére jelentsék a szabálysértést. Például, @ctb és @mr-c [kifejtik ezt a projektjükben](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): + +> A zaklató, erőszakos vagy egyéb elfogadhatatlan viselkedést emailben lehet jelenteni **khmer-project@idyll.org** címre, amelyet csak C. Titus Brown és Michael R. Crusoe kap meg. Ha bármelyikük érintett a szabálysértésben, akkor **Judi Brown Clarke, Ph.D.** Sokszínűségért Felelős Igazgató legyen a címzett.* + +További inspirációért nézd meg a Django magatartás kódexét [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (nem biztos hogy, ennyire részletes kódexre van szükséged, ez a projekt méretétől függ). + +## A magatartási kódex érvényesítése + +Annak ellenére, hogy mindent megtettél, néha előfordul, hogy valaki vét a szabályok ellen. Ekkor számos módja van a negatív vagy káros viselkedés kezelésének. + +### Gyűjts információt a helyzetről + +A közösség minden tagjának hangja ugyanolyan fontos, mint a tiéd. Ha olyan jelentést kapsz, hogy valaki megsértette a magatartási kódexet, akkor vedd komolyan és vizsgáld meg az ügyet, még akkor is, ha nem feltételezel ilyet az adott személyről. Ezzel jelzed a közösségnek, hogy értékeled a szempontjaikat és bízol az ítélőképességükben. + +A szóban forgó illető lehet ismétlődő elkövető, aki rendszeresen kényelmetlen helyzetbe hoz másokat, vagy csak egyszer mondott vagy tett valamit. Mindkettő indok lehet a cselekvésre a témától függően. + +Mielőtt válaszolnál, adj magadnak időt, hogy megértsd, mi történt. Olvasd el a személy múltbeli észrevételeit és beszélgetéseit, hogy jobban megértsd, ki ő és miért cselekedett ilyen módon. Próbáld meg más emberek véleményét kikérni az adott emberről és viselkedéséről. + + + +### Tedd meg a megfelelő lépéseket + +A szükséges információk összegyűjtése és feldolgozása után el kell döntened, hogy mit teszel. Miközben megteszed a szükséges lépéseket, ne feledd, hogy a moderátor célja az, hogy biztonságos, tiszteletteljes és együttműködő környezetet teremtsen. Ne csak arra gondolj, hogy hogyan kell kezelni a szóban forgó helyzetet, hanem arra is, hogy a válasz hogyan befolyásolja a közösség további viselkedését és elvárásait. + +Amikor valaki bejelenti a magatartási kódex megsértését, akkor annak kezelése a te feladatod és nem az övé. Néha a bejelentő olyan információkat tár fel, amelyek nagy kockázatot jelenthetnek karrierjük, hírnevük vagy fizikai biztonságuk szempontjából. Ha arra kényszeríted őket, hogy szálljanak szembe a szabálysértővel, azzal kompromittálod őket. A közvetlen kommunikációt neked kell lefolytatnod ebben az ügyben, kivéve, ha a bejelentő mást kér. + +Számos lehetőséged van arra, hogy eljárj a szabálysértőkkel szemben: + +* **Publikusan figyelmeztesd a kérdéses személyt** és magyarázd el, hogy a viselkedése negatívan hatott másokra, lehetőleg azon a csatornán, ahol történt. A nyilvános kommunikáció, ahol lehetséges, azt közvetíti a közösség többi tagja felé, hogy komolyan veszed a magatartási kódexet. Légy kedves, de szilárd a kommunikációban. + +* **Privát módon lépj kapcsolatba a kérdéses személlyel** és magyarázd el, hogy a viselkedése negatívan hatott másokra. Szenzitív információk esetén privát csatornákat használj. Ha valakivel privát levelezést folytatsz, akkor jó ötlet CC mezőben értesíteni a bejelentőt, így értesül róla, hogy megtetted a szükséges lépéseket. Mindenképpen kérd a bejelentő hozzájárulását mielőtt a CC mezőbe teszed. + +Néha a fentiek nem érnek célt. A kérdéses személy agresszív vagy ellenséges lesz és nem változtatja meg a viselkedését. Ebben a helyzetben meg kell fontolnod keményebb intézkedéseket is, mint például: + +* **A kérdéses személyt felfüggeszted** a projekten, átmenetileg megtiltva neki, hogy a projektben bármilyen módon részt vegyen. + +* **A kérdéses személyt véglegesen kizárod** a projektből. + +A felfüggesztés és kizárás súlyos büntetés, és azt mutatja, hogy valaki összeegyeztethetetlen a projekttel és szabályaival. Csak akkor alkalmazd ezeket, ha biztos vagy benne, hogy nem lehet megoldani a problémát. + +## A felelősséged karbantartóként + +A magatartási kódex nem tetszőlegesen betartatott törvény. Te vagy a kódex végrehajtója és a te felelősséged, hogy az abban megállapított szabályok be legyenek tartva. + +Karbantartóként te állapítod meg a közösségére vonatkozó iránymutatásokat, és ezeket neked kell betartatni a magatartási kódexben meghatározott szabályok szerint. Ez azt jelenti, hogy a magatartási kódex bármilyen megsértését komolyan kell venned. A bejelentők felé kötelességgel tartozol a panaszok alapos és tisztességes felülvizsgálatával. Ha úgy ítéled meg, hogy az általuk jelentett magatartás nem sérti a kódexet, azt kommunikáld egyértelműen feléjük és magyarázd meg, miért nem teszel lépéseket. Ezután már rájuk van bízva, hogy a mit tesznek: eltűrik a magatartást, amelyet bejelentettek, vagy abbahagyják a közösségben való részvételt. + +Az olyan viselkedésről szóló jelentés, amely _technikailag_ nem sérti a magatartási kódexet, még mindig jelezheti azt, hogy probléma van a közösségben. Ilyenkor meg kell vizsgálnod ezt, mint lehetséges problémát és szükség esetén cselekedned is kell. Lehet, hogy felül kell vizsgálnod a magatartási kódexet, hogy tisztázódjon, mi az elfogadható viselkedés. Esetleg beszélned kell a viselkedési problémában érintett személyekkel, hogy bár nem sértették meg a szabályokat, nagyon közel álltak hozzá, és ezzel másokat kellemetlen helyzetbe hoztak. + +Végeredményben, karbantartóként te vagy az, aki lefekteti és betartatja az elfogadható viselkedés szabályait. Megvan a lehetőséged, hogy alakítsd a projekt közösségi értékeit és a résztvevők elvárják, hogy ezeket az értékeket tisztességesen és következetesen képviseld. + +## Erősítsd azt a viselkedést amit látni akarsz a világban 🌎 + +Ha egy projekt ellenségesnek vagy nem befogadónak tűnik – akkor is, ha csak egyetlen ember az oka, akinek a viselkedését mások tolerálják –, azt kockáztatod, hogy rengeteg közreműködőt elveszítesz. Ezek között olyanokat is, akikkel akár soha többé nem találkozhatsz. Nem mindig könnyű a magatartási kódex elfogadása vagy érvényesítése, de a barátságos környezet elősegítése segít a közösség növekedésében. diff --git a/_articles/hu/finding-users.md b/_articles/hu/finding-users.md new file mode 100644 index 0000000000000000000000000000000000000000..d88b44333c83fec5812828ed79dbad0f6a4a13cc --- /dev/null +++ b/_articles/hu/finding-users.md @@ -0,0 +1,156 @@ +--- +lang: hu +title: A projekt felhasználók megtalálása +description: Segítsd a projekted fejlődését azzal, hogy elégedett felhasználókat találsz. +class: finding +order: 3 +image: /assets/images/cards/finding.png +related: + - beginners + - building +--- + +## Az ige terjesztése + +Nincs olyan szabály, ami kimondja, hogy egy nyílt forráskódú projektet ismertté kell tenni az induláskor. Számos valós ok lehet arra, hogy olyan nyílt forráskódú munkát végezz, amelynek semmi köze a népszerűséghez. Ahelyett, hogy abban reménykednél, hogy mások majd megtalálják és felhasználják a nyílt forráskódú projektedet, kezdd el megismertetni a világot a kemény munkád eredményével! + +## Fogalmazd meg az üzenetet + +Mielőtt elindítanád a projekted népszerűsítési munkáját, meg kell tudnod fogalmazni, hogy az mit csinál, és miért fontos. + +Mitől más, mint a többi, vagy miért különleges a projekt? Miért hoztad létre? Ha megválaszolod ezeket a kérdéseket, segít kommunikálni a projekt lényegét. + +Ne feledd, hogy az emberek először _felhasználóként_ vesznek részt, majd idővel _résztvevőkké_ válnak, mert a projekt megold számukra egy problémát. Amikor a projekt üzenetéről és értékéről gondolkodsz, próbáld objektíven, a _felhasználók és résztvevők_ szemszögéből nézni ezeket. + +Például, @robb példa programkódokat használt a projektje népszerűsítésére, [Cartography](https://github.com/robb/Cartography), hogy bizonyítsa mennyire hasznos: + + + +Kicsit mélyebb üzenetért, nézd meg a Mozilla ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) felhasználói személyiség fejlesztéséről szóló útmutatóját. + +## Segítsd az embereket abban, hogy megtalálják és kövessék a projektedet + + + +Segíts az embereknek megjegyezni a projektedet azáltal, hogy egyetlen pontra, helyre irányítod őket. + +**Legyen egyértelmű, hogy hol népszerűsíted a munkád.** Ez lehet Twitter vagy IRC csatorna, vagy GitHub URL, amely könnyen elérhető mindenkinek. Ezek a helyek a projekt növekvő közösségének is helyet biztosítanak. + +Ha még nem szeretnél projekthez köthető kommunikációs csatornákat kiépíteni, akkor a saját Twitter vagy GitHub helyeiden is meg tudod azt tenni. A Twitter vagy GitHub azonosító alapján a felhasználók tudni fogják hogyan érjenek el téged és a projektet. Ha eseményen vagy szakmai találkozókon adsz elő, akkor bizonyosodj meg róla, hogy ezeket a elérhetőségeket feltüntetted az előadásodban. + + + +**Fontold meg webhely létrehozását a projektedhez.** A weboldal barátságosabbá teszi a projektet és könnyebbé teszi a keresést, főleg ha ez áttekinthető dokumentációval és útmutatókkal párosul. Egy weboldal azt sugallja, hogy a projekt aktív, így az emberek bátrabban fogják használni. Mutass példákat arra, hogy a felhasználók hogyan tudják használni a munkádat. + +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), a Django társalapítója mondta egyszer a weboldalról, hogy _"messze a legjobb dolog volt, amit csinálhattunk a Django indulásakor"_. + +Ha a projekted a GitHub-on van, akkor használhatod a [GitHub Pages](https://pages.github.com/) funkciót arra, hogy a weboldalt könnyedén létrehozd. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), és [Middleman](https://middlemanapp.com/) [és még számos példa](https://github.com/showcases/github-pages-examples) a nagyszerű, áttekinthető weboldalakra. + + + +Most, hogy van a projektednek üzenete és van egy könnyű módja annak, hogy az emberek megtalálják a projektedet, vágjunk bele, és beszéljünk az emberekkel. + +## Ott kell lenni, ahol a hallgatóság van (online) + +Az online tájékoztatás nagyszerű módja annak, hogy gyorsan megoszthasd és terjeszd az információt. Az online csatornák használatával lehetőséged van nagyon széles közönség elérésére. + +Használd ki a meglévő online közösségeket és platformokat, hogy elérd a saját közönségedet. Ha a nyílt forráskódú projekted szoftver projekt, akkor közönségedet megtalálhatod a [StackOverflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), vagy [Quora](https://www.quora.com/) oldalakon. Találd meg azokat a csatornákat, ahol olyan emberek vannak, akik a legtöbbet profitálhatnak a munkádból, vagy a leginkább kíváncsiak lehetnek rá. + + + +Nézzük, hogyan lehet megtalálni a lényeges helyeket, ahol megoszthatod a projekted: + +* **Ismerd meg a kapcsolódó nyílt forráskódú projekteket és közösségeket.** Néha nem kell közvetlenül hirdetni a projekted. Ha a projekt tökéletes a Python-t használó adathalmaz kutatók számára, ismerkedj meg a Python adatkutató közösséggel. Amint az emberek megismernek, természetes lehetőség adódik a beszélgetésre és arra, hogy megoszd velük a munkád eredményét. +* **Találd meg azokat az embereket, akiknek a problémájára megoldást kínál a projekted.** Nézd át a kapcsolódó fórumokat, hogy megtaláld azokat az embereket, akik a projekted közönségét alkothatják. Válaszold meg a kérdéseiket és ha lehetséges, tapintatosan ajánld fel a projektedet megoldásként. +* **Kérj visszajelzést.** Mutasd be magadat és a munkádat egy olyan közösségnek, amelyik érdekesnek találhatja azt. Legyél konkrét abban, hogy szerinted kinek hasznos a projekted. Próbáld így befejezni a mondatod: _"Úgy gondolom, hogy a projektem tényleg nagyon hasznos X csoportnak, akik az Y problémát akarják megoldani_". Hallgasd meg és válaszolj mások észrevételére, ne csak bemutató előadás legyen a projektedről. + +Általánosságban: fókuszálj mások megsegítésére mielőtt bármit is kérsz. Mivel bárki képes online egy projektet bemutatni, ezért sok lesz a zaj. Ahhoz, hogy kitűnj a tömegből, az embereknek meg kell érteniük, hogy ki is vagy és nem csak azt, hogy mit akarsz. + +Ha senki sem figyel fel vagy válaszol az első kísérletedre, ne add fel! A legtöbb projekt iteratív folyamat, amely hónapokig vagy akár évekig tart. Ha elsőre nem kapsz visszajelzést, akkor próbálj más taktikát vagy keress olyan lehetőséget, hogy mások munkájához hozzájárulj valami hasznossal. A projekt hírének megalapozása és elindítása időt és kitartást igényel. + +## Ott kell lenni, ahol a hallgatóság van (off-line) + + + +A projektek népszerűsítésének gyakori módja, ha egy off-line eseményen mutatod be őket. Ez nagyszerű módja annak, hogy elérjed az elkötelezett közönséget, és mélyebb emberi kapcsolatokat építs ki különösen, ha érdekelt vagy a fejlesztők elérésében. + +Ha teljesen [új vagy az előadásban](https://speaking.io/), keress egy helyi szakmai találkozót (meetup) amely kapcsolódik a projekted témájához vagy programnyelvéhez. + + + +Ha még soha nem beszéltél egy eseményen, teljesen normális, hogy feszültnek érzed magad. Ne feledd, hogy a közönség azért van ott, mert valóban szeretne hallani a munkádról. + +A beszéd írásakor összpontosíts arra, amit szerinted a közönség érdekesnek talál és mutasd meg az értéket a munkádban. Barátságos, elfogadható nyelvezetet használj. Mosolyogj, lélegezz és érezd jól magad! + + + +Amikor késznek érzed magad, gondolkozz el, hogy hol, milyen konferenciákon tudnád bemutatni a projektedet. A konferenciák segítenek abban, hogy több embert elérj, gyakran a világ minden részéről. + +Keress olyan konferenciát, amely erősen kapcsolódik a te fejlesztési nyelvedhez, ökoszisztémádhoz. Mielőtt az előadásoddal jelentkezel, nézz utána a konferenciának, és szabd kicsit hozzá az előadásodat, ezzel növelve az esélyét, hogy elfogadják az anyagodat. Gyakran a többi előadó alapján is fel tudod mérni, hogy milyen az adott konferencia közönsége. + + + +## Alapozd meg a hírnevet + +A fent vázolt stratégiák mellett a legjobb módja annak, hogy részvételre buzdítsd az embereket a projektedre az, hogy te is részt veszel az ő projektjeikben. + +Új résztvevők segítése, információ megosztása és átgondolt részvétel mások projektjeiben segít, hogy pozitív kép alakuljon ki rólad. Aktív nyílt forráskódú közösségi tagként az emberek felfigyelnek rád és könnyebben befogadják a projektedet. A más projektekkel kialakított kapcsolat akár hivatalos partnerséghez is vezethet. + + + +Soha sincs túl késő vagy túl korán a hírnév építéséhez. Még ha el is indítottad a saját projektedet, folyamatosan keresd a lehetőséget arra, hogy másoknak segíts. + +Nem létezik olyan módszer, amivel hirtelen közönséget és hírnevet tudsz szerezni. A bizalom és tisztelet megszerzéséhez idő kell, és a hírnév építése sohasem érhet véget. + + + +## Tarts ki! + +Lehet, hogy sokáig fog tartani, mire az emberek felfigyelnek a projektedre, de ezzel nincs semmi probléma! Számos olyan projektnek, amely ma a leghíresebbek között van, évekig tartott, mire elérte a jelenlegi ismertségét és aktivitását. A lényeg a kapcsolatépítésen legyen, ne abban reménykedj, hogy egyszer magától fog növekedni a hírneve. Légy türelmes, és működj együtt azokkal, akik értékelik a munkádat. diff --git a/_articles/hu/getting-paid.md b/_articles/hu/getting-paid.md new file mode 100644 index 0000000000000000000000000000000000000000..7fa29f1d3d4e58b04d4fa79c6bf4d5b1c96147de --- /dev/null +++ b/_articles/hu/getting-paid.md @@ -0,0 +1,190 @@ +--- +lang: hu +title: Fizetés a nyílt forráskódú munkaért +description: Tartsd fenn a nyílt forráskódú projektedet azáltal, hogy pénzügyi támogatókat szerzel. +class: getting-paid +order: 7 +image: /assets/images/cards/getting-paid.png +related: + - best-practices + - leadership +--- + +## Miért keresünk pénzügyi támogatást? + +A legtöbb nyílt forráskódú munka önkéntes. Például, ha valaki találkozik egy hibával egy projektben amelyet használ, akkor gyors javítást nyújt be, vagy szabadidejében a nyílt forráskódú projektet javítgatja. + + + +Számos oka lehet annak, hogy valaki nem akar fizetést a nyílt forráskódú munkájáért. + +* **Lehet, hogy már főállásban dolgozik, amit szeret,** és ami lehetővé teszi, hogy szabadidejében nyílt forráskódon is dolgozhasson. +* **Hobbiként tekint a nyílt forráskódú fejlesztésre** vagy a kreatív szabadság kiteljesedéseként és nem akarja magát korlátozni. +* **Más előnye származik a nyílt forráskódú munkájából,** például a hírnév vagy portfólió építés, tanulás, vagy a közösségi munka öröme. + + + +Mások számára, különösen, ha a hozzájárulásuk folyamatosak vagy jelentős időre van szükségük, a nyílt forráskódban való munkájuk megfizetése az egyetlen módja annak, hogy részt vehessenek benne, akár a projekt igényei, akár személyes okok miatt. + +A népszerű projektek fenntartása jelentős felelősséggel járhat, havi néhány óra helyett akár heti 10 vagy 20 órát is igénybe vehet. + + + +A fizetett munka az élet különböző területein élő emberek számára is lehetővé teszi, hogy érdemi hozzájárulást nyújtsanak a projekthez. Egyesek nem engedhetik meg maguknak, hogy fizetetlen időt töltsenek a nyílt forráskódú projekteken a jelenlegi pénzügyi helyzetük, adósságuk, családi vagy egyéb gondoskodási kötelezettségeik miatt. Ez azt jelenti, soha nem jutnak el a világba azoknak a tehetséges embereknek a hozzájárulásai, akik nem engedhetik meg maguknak, hogy ingyen dolgozzanak. Ennek etikai következményei vannak, ahogy @ashedryden [írta](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), azoknak akiknek nincs szüksége pénzügyi támogatásra könnyebben végezhetnek nyílt forráskódú munkát, így azzal további előnyöket szerezhetnek, míg aki nem tud pénzügyi okokból ilyen munkát végezni, ezt az előnyt értelemszerűen nem is szerezheti meg, ezzel tovább erősítve a sokszínűség hiányát a nyílt forráskódú közösségben. + + + +Ha pénzügyi támogatást keresel, akkor két irány lehet. Résztvevőként finanszírozhatod a saját idődet vagy találsz egy szervezetet, aki támogatja a projektet. + +## Saját időnk finanszírozása + +Ma sok embernek fizetnek részmunkaidőben vagy teljes munkaidőben nyílt forráskódú munkáért. A leggyakoribb módja annak, hogy fizessenek az idődért az, hogy megbeszéled a saját munkáltatóddal. + +Egyszerűbb elérni ezt, ha az adott nyílt forráskódú projektet a munkaadód is használja. Lehet, hogy a munkaadód nem használja a projektet, de használja a Python-t, és egy népszerű Python projekt fenntartása segíti, hogy új Python fejlesztőket találjon a munkaadód. Ezzel a munkaadód még fejlesztő-barátabbnak tűnik. + + + +Ha még nincs nyílt forráskódú projekted, amin dolgoznál, de szeretnéd, ha munkád eredménye nyílt forrású lenne, győzd meg a munkaadódat, hogy valamelyik belső projekt forráskódját tegye nyílttá. + +Számos cég fejleszt nyílt forráskódú programokat azért, hogy az imázsukat javítsák és a tehetséges fejlesztőket megszerezzék. + +@hueniverse, például úgy találta, hogy a pénzügyi okok miatt kezdett a [Walmart a nyílt forráskódba fektetni](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). És @jamesgpearce szerint a Facebook nyílt forráskódú programja [változtatott a munkaerő toborzáson](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon): + +> Ez szorosan illeszkedik a fejlesztői kultúránkhoz és a szervezetünk megítéléséhez. Megkérdeztük a kollégáinkat, "Tudtad-e, hogy a Facebooknak vannak nyílt forráskódú projektjei?". Kétharmad válaszolt igennel. A megkérdezettek fele mondta azt, hogy ez jelentősen hozzájárult a döntésükhöz, hogy nálunk dolgozzanak! Ezek nem elhanyagolható számok, és remélem, hogy ez a trend folytatódik. + +Ha a vállalatod ezt az utat választja, fontos, hogy a közösségi és a vállalati tevékenység jól elhatárolódjon. Végső soron a nyílt forráskód fenntartja saját magát a világ minden tájáról érkező emberek hozzájárulásaival, és ez jóval nagyobb, mint bármelyik vállalat vagy hely. + + + +Ha nem tudod meggyőzni a jelenlegi munkáltatót a nyílt forráskódú munka fontosságáról, fontold meg, hogy keresel egy új munkaadót, aki ösztönzi a munkavállalók hozzájárulását a nyílt forráskódhoz. Keress olyan cégeket, amelyek kifejezetten a nyílt forráskódú munkát támogatják. Például: + +* Néhány cégnek, mint a [Netflix](https://netflix.github.io/) vagy a [PayPal](https://paypal.github.io/), külön weboldala van, amin a nyílt forráskódú munkát támogatják +* [Zalando](https://opensource.zalando.com) publikálta a [nyílt forráskódban történő részvétel feltételeit](https://opensource.zalando.com/docs/using/contributing/) a munkavállalói számára + +A nagy cégektől származó projektek, mint a [Go](https://github.com/golang) vagy a [React](https://github.com/facebook/react), szintén nagy valószínűséggel foglalkoztatnak embereket, hogy nyílt forráskódon dolgozzanak. + +A személyes körülményeidtől függően megpróbálhatsz önállóan pénzt gyűjteni a nyílt forráskódú munkád finanszírozásához. Például: + +* @gaearon a [Redux](https://github.com/reactjs/redux) projektet egy [Patreon crowdfunding kampányon](https://redux.js.org/) keresztül finanszírozta (önkéntes támogatás) +* @andrewgodwin a Django schema migrációkat [egy Kickstarter kampányon keresztül](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) finanszírozta. + +Végül, néha a nyílt forráskódú projektek díjakat tűznek ki a hibák megoldására, amelyekkel kapcsolatban akár érdemes lehet segítséget nyújtani. + +* @ConnorChristie fizetséget kapott azért, mert [segített](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol -nak a JavaScript könyvtár fejlesztésében, mindezt a [gitcoin rendszeren keresztül](https://gitcoin.co/). +* @mamiM elvégezte a japán nyelvi fordítást @MetaMask részére, melyet [a Bounties Network-ön keresztül finanszíroztak](https://explorer.bounties.network/bounty/134). + +## Találd meg a projekt finanszírozását + +Az egyéni közreműködőkkel történő megállapodásokon túl, a projektek néha pénzt szereznek vállalatoktól, magánszemélyektől vagy másoktól a folyamatban lévő munka finanszírozásához. + +A szervezeti finanszírozás elkölthető a résztvevők támogatására, a projekt működtetésére (például a tárhely díjakra, hosztingra), illetve új funkciók vagy ötletek megvalósítására. + +Miközben a nyílt forráskód népszerűsége növekszik, a projektek finanszírozásának megtalálása még mindig kísérleti jellegű, de azért van pár elterjedt lehetőség. + +### Szerezz pénzt a munkádhoz közösségi finanszírozási kampányok vagy szponzorálás révén + +Könnyű szponzorokat találni, ha már erős közönséged vagy jó hírneved van, vagy ha nagyon népszerű a projekted. + +Néhány példa: + +* **[webpack](https://github.com/webpack)** magánszemélyektől és cégektől is támogatáshoz jut [az OpenCollective-en keresztül](https://opencollective.com/webpack) +* **[Vue](https://github.com/vuejs/vue)** [a Patreon-on keresztül jut támogatáshoz](https://github.com/open-source/stories/yyx990803) +* **[Ruby Together](https://rubytogether.org/),** egy non-profit szervezet, amely támogatja a [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), és egyéb Ruby infrastruktúra projekteket + +### Hozz létre bevételi forrást + +A projektedtől függően kérhetsz támogatást szupportért, új funkcióért, vagy szolgáltatásért. Néhány példa: + +* **[Sidekiq](https://github.com/mperham/sidekiq)** kínál fizetős verziót támogatásért cserébe +* **[Travis CI](https://github.com/travis-ci)** kínál fizetős verziót privát használatra +* **[Ghost](https://github.com/TryGhost/Ghost)** alapvetően non-profit, de a felügyelt szolgáltatásért fizetni kell + +Néhány híres projekt, mint az [npm](https://github.com/npm/npm) és a [Docker](https://github.com/docker/docker), még kockázati tőkét is bevontak a növekedés finanszírozásához. + +### Jelentkezz pályázatokra + +Egyes szoftveralapítványok és cégek támogatást nyújtanak a nyílt forráskódú munkákhoz. Előfordul, hogy a támogatásokat magánszemélyek is megkaphatják anélkül, hogy jogi személyt hoznának létre a projekthez. + +* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** támogatást kapott a [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/)-tól +* **[OpenMRS](https://github.com/openmrs)** támogatásban részesült a [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) által +* **[Libraries.io](https://github.com/librariesio)** támogatást kapott a [Sloan Foundation](https://sloan.org/programs/digital-technology)-től +* A **[Python Software Foundation](https://www.python.org/psf/grants/)** támogatást kínál a Python-hoz kapcsolódó projekteknek + +Ha érdekelnek a lehetőségek vagy esettanulmányok részletesebben, @nayafia [írt egy útmutatót](https://github.com/nayafia/lemonade-stand), hogy hogyan juthatunk pénzhez a nyílt forráskódú munkával. +A különböző finanszírozási lehetőségek különböző képességeket igényelnek, a választásnál vedd figyelembe az erősségeidet. + +## Pénzügyi támogatás kiépítése + +Függetlenül attól, hogy a projekted új ötlet-e, vagy már évek óta létezik, készülj arra, hogy jelentős figyelmet kell fordítanod a lehetséges támogatók megtalálására és meggyőzésére. + +Akár a saját időd finanszírozására, akár a projekted részére gyűjtesz támogatást, meg kell tudnod válaszolni a következő kérdéseket. + +### Hatás + +Miért olyan hasznos ez a projekt? Miért szeretik a felhasználók vagy a potenciális felhasználók a projektet? Hol fog tartani öt év múlva a projekt? + +### Elfogadottság + +Próbálj meg tényeket gyűjteni arra vonatkozóan, hogy a projekt lényeges, legyenek számok, anekdoták vagy ajánlások. Vannak-e olyan cégek vagy ismert emberek, akik most is használják a projektet? Ha nincs ilyen, akkor van-e olyan prominens személy, aki pozitívan nyilatkozott róla? + +### Érték a támogató részére + +A finanszírozók, akár a munkáltatód, akár egy alapítvány, gyakran a lehetőségek irányából közelítik meg a támogatás kérdését. Miért kellene támogatniuk a projektedet a kihívások ellenére? Hogyan részesülnek a hozadékából, milyen előnyöket jelent számukra a támogatás? + +### A támogatás felhasználása + +Pontosan mit fogsz elérni a javasolt finanszírozással? Az emberek fizetése helyett inkább a projekt mérföldköveire vagy eredményeire összpontosíts. + +### Hogyan kapod meg a támogatást + +A támogatónak vannak kikötései a kifizetéssel kapcsolatosan? Például lehet, hogy non-profit vállalkozásnak kell lenned vagy rendelkezned kell egy non-profit támogatóval. Lehetséges, hogy csak magánszemélyt támogatnak, szervezeteket vagy cégeket nem. Az igények támogatónként eltérhetnek, ezért érdemes ezeket előre felderíteni. + + + +## Kísérletezz és ne add fel + +Pénzügyi támogatást kapni nem könnyű dolog, legyen szó nyílt forráskódról, non-profit szervezetről, vagy szoftver startupról, legtöbb esetben kreatívnak kell lenned. El kell döntened, hogyan szeretnéd a támogatást megkapni, kutatnod kell, és a támogató helyébe kell képzelned magad, hogy meggyőzhesd a támogatásról. + +> diff --git a/_articles/hu/how-to-contribute.md b/_articles/hu/how-to-contribute.md new file mode 100644 index 0000000000000000000000000000000000000000..8c882058d7f3815d993478f8cbb7d847d56a8a58 --- /dev/null +++ b/_articles/hu/how-to-contribute.md @@ -0,0 +1,525 @@ +--- +lang: hu +title: Hogyan lehet hozzájárulni a nyílt forráskódhoz +description: Szeretnél hozzájárulni a nyílt forráskódhoz? Ez egy útmutató a nyílt forráskódú fejlesztésekben történő részvételhez kezdők és haladók számára. +class: contribute +order: 1 +image: /assets/images/cards/contribute.png +related: + - beginners + - building +--- + +## Miért vegyél részt a Nyílt Forráskódú fejlesztésben? + + + +A nyílt forráskódhoz való hozzájárulás a tanulás, a tanítás és a tapasztalatok megszerzésének a legjobb útja bármiben, amit csak el tudsz képzelni. + +Miért járulnak hozzá az emberek a nyílt forráskódhoz? Rengeteg oka van! + +### Készségfejlesztés + +Kódolás, felhasználói felület tervezése, grafikai tervezés, írás vagy akár szervezés – ha gyakorlatot keresel, akkor találsz feladatot nyílt forráskódú projekten. + +### Találkozz hasonló érdeklődésű emberekkel + +A nyílt forráskódú projektek befogadó, barátságos közösségek, ahová évek múlva is visszatérnek az emberek. Sokan egy egész életen át tartó barátságot kötnek a nyílt forráskódú részvételük révén, függetlenül attól, hogy konferenciákon vagy késő esti online beszélgetéseken ismerkednek-e meg. + +### Keress mentorokat és taníts másokat + +Közös projekten dolgozni másokkal azt jelenti, hogy el kell magyaráznod, hogy hogyan működnek a dolgok, vagy más embereket kell megkérned, hogy segítsenek. A tanításban és tanulásban minden résztvevő ki tud teljesedni. + +### Növeld a hírnevedet és támogasd a karriered azzal, hogy közzéteszed a munkád + +Alapértelmezés szerint minden nyílt forráskódú munka publikus, amit azt jelenti, hogy bárhol megjelenhetsz a munkáiddal bemutatva azt, hogy mire vagy képes. + +### Emberi készségek fejlesztése + +A nyílt forráskód számos kihívást tartogat a vezetői és szervezői készségek gyakorlásában, úgy mint konfliktus megoldás, csapatszervezés és a feladatok priorizálása. + +### Lehetőséged van változtatni, még ha kicsit is + +Ahhoz, hogy sikerélményed legyen egy nyílt forráskódú projektben, nem kell egy életen át részt venned a munkában. Láttál már valaha egy elgépelést egy weboldalon, és kívántad már azt, hogy valaki bárcsak kijavítaná? Egy nyílt forráskódú projektben éppen ezt tudod megtenni. A nyílt forráskód segít abban, hogy az emberek a saját életüket irányítsák és azt, hogy hogyan alakítsák a világot a maguk örömére. + +## Mit jelent a hozzájárulás? + +Ha új vagy a nyílt forráskódban, akkor a folyamat először félelmetes lehet. Hogyan találd meg a jó projektet? Mi van, ha nem jól kódolsz? Mi történik, ha valami nem működik? + +Ne aggódj! Rengeteg módja van annak, hogy részt vegyél a nyílt forráskódú fejlesztésekben, és számos tipp segít abban, hogy a legtöbbet hozd ki magadból. + +### Nem kell kóddal hozzájárulnod + +Gyakori tévhit a nyílt forráskódhoz való hozzájárulásról, hogy programozni kell hozzá. Valójában gyakran a projekt többi része az, amely [elhanyagolt, vagy mellőzött](https://github.com/blog/2195-the-shape-of-open-source). Óriási segítség a projektnek, ha ilyen jellegű munkával járulsz hozzá! + + + +Még ha szeretsz is programozni, akkor is nagyszerű módja a projektben való részvételnek vagy hogy találkozz közösségi tagokkal az, hogy más jellegű hozzájárulásod van a projekthez. Ezeknek a kapcsolatoknak a kiépítése lehetőséget teremt arra, hogy a projekt egyéb részein dolgozz. + + + +### Szeretsz rendezvényt szervezni? + +* Szervezz gyakorlati előadásokat vagy találkozókat a projektről, [ahogy @fzamperin csinálja a NodeSchool-nál](https://github.com/nodeschool/organizers/issues/406) +* Szervezd meg a projekttel kapcsolatos konferenciát (ha van ilyen) +* Segíts a közösség tagjainak megtalálni a megfelelő rendezvényeket és írj javaslatokat az előadások témáira + +### Szereted a grafikai tervezést? + +* Alakítsd át a megjelenést, hogy a projekt jobban áttekinthető legyen +* Végezz felhasználói igényfelmérést, hogy javítsd vagy finomítsd a projekt oldal navigációját vagy menürendszerét, [például ahogy a Drupal javasolja](https://www.drupal.org/community-initiatives/drupal-core/usability) +* Állíts össze egy stílus útmutatót ezzel segítve az egységes vizuális megjelenést +* Készíts póló terveket vagy új logót, [ahogy a hapi.js fejlesztői tették](https://github.com/hapijs/contrib/issues/68) + +### Szeretsz írni? + +* Írd és javítsd a projekt dokumentációját +* Tarts karban egy példa könyvtárat a projekt használatáról +* Indíts hírlevelet a projektről, vagy a levelező listáról készít összefoglalót +* Írj útmutatókat a projektről, [ahogy PyPA fejlesztői tették](https://github.com/pypa/python-packaging-user-guide/issues/194) +* Fordíts le a projekt dokumentációját + + + +### Szeretsz szervezni? + +* Kapcsold össze a duplikált hibajegyeket és javasolj más címkéket, hogy jobban szervezett legyen a projekt +* Nézd át a nyitott hibajegyeket és javasold a régiek lezárását, [ahogy @nzakas csinálta az ESLint esetén](https://github.com/eslint/eslint/issues/6765) +* Tegyél fel tisztázandó kérdéseket a közelmúltban megnyitott felvetésekről, problémákról a vita előmozdítása érdekében + +### Szeretsz kódolni? + +* Keress nyitott problémákat, amelyeket megoldhatsz, [mint ahogy @dianjin csinálta a Leaflet esetén](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) +* Kérdezd meg, hogy tudsz-e segíteni valamely új funkció kifejlesztésében +* Automatizáld a projektet +* Fejleszd az eszközöket és a teszteket + +### Szeretsz segíteni embereken? + +* Válaszolj a projekttel kapcsolatos kérdésekre, például a StackOverflow-n, ([mint ez a Postgres példa](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) vagy a Reddit-en +* Válaszold meg a kérdéseket a nyitott problémákról +* Segíts moderálni a beszélgetést a fórumokon vagy egyéb csatornákon + +### Szeretsz másoknak segíteni a kódolásban? + +* Nézd át más emberek kódját, amellyel a projekthez járulnak hozzá +* Írj útmutatót arról, hogyan kell a projektben dolgozni +* Ajánld fel a segítségedet a kódolásban résztvevőnek, légy mentor [mint ahogy @ereichert csinálta @bronzdoc esetén a Rust projektben](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) + +### Nem csak szoftver projekten tudsz dolgozni! + +Bár a "nyílt forráskód" gyakran szoftverre utal, bármi másban is részt tudsz venni. Vannak könyvek, receptek, válogatott listák és útmutatók, amelyeket nyílt forráskódú projektként fejlesztenek. + +Például: + +* @sindresorhus karbantart egy [listát a nagyszerű dolgokat listázó oldalakról](https://github.com/sindresorhus/awesome) +* @h5bp kezeli [a listát a lehetséges munkainterjú kérdésekről](https://github.com/h5bp/Front-end-Developer-Interview-Questions) a front-end fejlesztő jelölteknek +* @stuartlynn és @nicole-a-tesla készített egy [gyűjteményt az északi madarak érdekességeiről](https://github.com/stuartlynn/puffin_facts) + +Még ha szoftverfejlesztő is vagy, egy dokumentációs projekt könnyebbé teszi az elindulást a nyílt forráskód világában. Kevésbé ijesztő, ha olyan projektben veszel részt először, ami nem tartalmaz kódot és a másokkal való együttműködés folyamán alakul ki az önbizalmad és nő a tapasztalatod. + +## Kezdetek egy új projektben + + + +Bármi más dolog, mint mondjuk egy elírás javítása olyan, mintha idegenekkel állnál le beszélgetni. Ha elkezdesz a lámákról beszélni, miközben ők elmélyedt párbeszédet folytatnak az aranyhalakról, akkor lehet kicsit furán fognak rád nézni. + +Mielőtt vakon javasolnál valamit, próbálj elmélyedni a témában, hogy megértsd azt. Ha így teszel, nagyobb eséllyel figyelnek oda a véleményedre és javaslataidra. + +### Egy nyílt forráskódú projekt anatómiája + +Minden nyílt forráskódú közösség más. + +Éveket eltölteni ugyanazzal a nyílt forráskódú projekttel azt jelenti, hogy ismersz egy nyílt forráskódú projektet. Egy másik projekt esetén teljesen más fogalmakkal, viselkedési normákkal és kommunikációs módszerekkel találkozhatsz. + +Ugyanakkor számos nyílt forráskódú projekt hasonló módon működik. Az eltérő közösségi szerepek vagy folyamatok megértése segít abban, hogy gyorsan alkalmazkodni tudj bármely új projekthez. + +Egy tipikus nyílt forráskódú projekt esetén az alábbi szerepek vannak: + +* **Szerző:** Személy(ek), esetleg szervezet, aki létrehozta a projektet +* **Tulajdonos:** Személy(ek), akinek adminisztrációs joga van a szervezet vagy a nyílt forrás felett (nem mindig egyezik a Szerzővel a személye) +* **Karbantartók:** Olyan résztvevők, akiknek felelőssége a projekt irányítása, az elképzelések formába öntése. (Ők lehetnek akár a Szerzői vagy a Tulajdonosai is a projektnek.) +* **Közreműködők:** Bárki, aki hozzájárul valamivel a projekthez. +* **Közösség tagjai:** Emberek, akik használják a projektet. Aktívak lehetnek a vitákban, vagy jelezhetik észrevételeiket a projekttel kapcsolatban. + +A nagyobb projekteknek lehetnek olyan albizottságai vagy munkacsoportjai is, amelyek különböző feladatokra összpontosítanak, mint például eszközök, prioritás, közösségi moderálás és rendezvényszervezés. Ezt az információt megtalálod a projekt honlapján a "csapat" oldalon, vagy a működési szabályok dokumentációi között. + +A projektnek dokumentációja is van. Ezek a fájlok általában a forráskód legfelső szintjén vannak felsorolva. + +* **LICENSE:** Alapértelmezés szerint minden nyílt forráskódú projektnek kell rendelkeznie egy [nyílt forráskód licenccel](https://choosealicense.com). Ha a projektnek nincs ilyen licence, akkor az nem nyílt forráskód. +* **README:** A README egy használati útmutató a közösség új tagjainak. Elmagyarázza, hogy miért hasznos a projekt és hogy hogyan lehet használni. +* **CONTRIBUTING:** Míg a README segíti az embereket a _használatban_, addig a CONTRIBUTING a projektben való _részvétel_ módját dokumentálja. Elmagyarázza, hogy mivel járulhatsz hozzá a projekthez és hogyan működnek a folyamatok. Bár nem minden projektnek van ilyen dokumentációja, a jelenléte azt mutatja, hogy számítanak a részvételedre és a hozzájárulásodra. +* **CODE_OF_CONDUCT:** Magatartási kódex, amely meghatározza a résztvevők magatartásának alapszabályait és elősegíti a barátságos környezet kialakítását. Bár nem minden projektnek van ilyen dokumentációja, a jelenléte azt mutatja, hogy barátságos projekt, amely számít a részvételedre. +* **Egyéb dokumentációk:** Lehetnek további dokumentációk, különösen nagyobb projektek esetén, mint például oktató anyagok, fejlesztési útmutatók, irányítási szabályok. + +A nyílt forráskódú projektek az alábbi eszközöket használják az egyeztetések szervezéséhez. A korábbi anyagok elolvasása jó képet ad arról, hogyan gondolkodik és működik a közösség. + +* **Issue tracker:** A résztvevők ennek segítségével beszélik meg a projekttel kapcsolatos problémákat. +* **Pull requests:** A résztvevők ezek segítségével vitatják meg és tekintik át a folyamatban lévő változtatásokat. +* **Internetes fórumok vagy levelező listák:** Néhány projekt használhatja ezen csatornákat is a különböző témák átbeszélésére (például, _"Hogyan tudom...?"_ vagy _"Mit gondolsz arról, hogy...?"_ című témát indít a _hiba jelentés,_ vagy _új funkció létrehozása_ helyett). Mások minden beszélgetést az _Issue tracker_-en keresztül kezelnek. +* **Csevegő csatorna:** Néhány projekt azonnali üzenetküldő (IM) csevegő csatornákat használ (mint amilyen a Slack vagy az IRC) általános beszélgetésre, együttműködésre és gyors üzenet váltásra. + +## Találd meg a projektedet! + +Most, hogy már tudod, hogy hogyan működnek a nyílt forráskódú projektek, itt az idő megtalálni azt, amelyben részt veszel! + +Ha még sohasem vettél részt nyílt forráskódú fejlesztésben korábban, akkor fogadd meg John F. Kennedy volt amerikai elnök egyik tanácsát: _"Ne azt kérdezd, hogy az ország mit tud tenni érted – kérdezd azt, hogy te mit tehetsz az országért."_ + +Hozzájárulás egy nyílt forráskódú projekthez bárhogy lehetséges, bármelyik projektben. Nem kell túlgondolni azt, hogy pontosan mi lesz az első hozzájárulásod, vagy azt, hogy az hogyan fog kinézni. + +Gondolkozz olyan projektben, amelyet már használsz, vagy használni akarsz. Azokat a projekteket, amelyekben aktívan részt veszel, szívesebben használni fogod a jövőben is. + +Ezekben a projektekben, amikor azon kapod magad, hogy gondolkozol egy jobb vagy más megoldásban, cselekedj ösztönösen! + +A nyílt forráskód nem egy zártkörű klub; ugyanolyan emberek dolgoznak rajta, mint te. A "Nyílt Forráskód" csak egy divatos kifejezés arra, hogy a világ problémáit megoldhatóként is lehet kezelni. + +Talán épp a README-t olvasod és találsz egy rossz hivatkozást, vagy egy elírást. De az is lehet, hogy új felhasználó vagy és észreveszel valami hibát, vagy egy problémát, amit dokumentálni kellene. Ahelyett, hogy nem törődsz vele és továbblépsz vagy megkérsz valakit, hogy javítsa, inkább ajánld fel a segítséged. Ez az amiről a nyílt forráskód szól! + +> [a nyílt forráskódú alkalmi hozzájárulások 28%-a](https://www.igor.pro.br/publica/papers/saner2016.pdf) a dokumentációt érinti, mint például egy elírás javítása, formázás, vagy fordítás. + +Ha szeretnél egy hibát javítani, akkor minden nyílt forráskódú projekt esetén találsz egy `/contribute` oldalt, amely segít abban, hogy kezdőként kijavítsd az első hibát. A projekt GitHub kezdőoldal URL-jét egészítsd ki a `/contribute` résszel a végén, (például [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)). + +Az alábbiakban találsz néhány oldalt, amelyek segítenek abban, hogy felfedezd és megtaláld az új projektedet: + +* [GitHub Explore](https://github.com/explore/) +* [Open Source Friday](https://opensourcefriday.com) +* [First Timers Only](https://www.firsttimersonly.com/) +* [CodeTriage](https://www.codetriage.com/) +* [24 Pull Requests](https://24pullrequests.com/) +* [Up For Grabs](https://up-for-grabs.net/) +* [Contributor-ninja](https://contributor.ninja) +* [First Contributions](https://firstcontributions.github.io) +* [SourceSort](https://www.sourcesort.com/) + +### Egy ellenőrző lista, mielőtt részt vennél a projektben + +Ha találtál egy projektet, amelyhez hozzájárulnál, végezz előtte egy gyors ellenőrzést. Bizonyosodj meg arról, hogy alkalmas-e a külső hozzájárulások fogadására. Máskülönben előfordulhat, hogy a kemény munkádnak nem lesz eredménye. + +Itt egy lista, aminek segítségével kiértékelheted, hogy a projekt alkalmas-e egy új résztvevőnek. + +**Megfelel a nyílt forráskód definíciójának** + +
Saya percaya bahwa pengujian otomatis sangat diperlukan untuk semua kode yang dikerjakan orang-orang. Jika kode tersebut benar, maka tidak diperlukan perubahan - kita hanya menuliskan kode apabila terjadi kesalahan, apakah "crash" atau "kurang fitur". Tanpa memperhatikan perubahan yang Anda lakukan, pengujian otomatis sangatlah penting untuk menangkap regresi kesalahan yang mungkin Anda timbulkan.
-— @edunham, ["Rust's Community Automation"](http://edunham.net/2016/09/27/rust_s_community_automation.html) +— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
diff --git a/_articles/id/building-community.md b/_articles/id/building-community.md index 7a4783e128945e3bdaec795daff53b256dd72b7f..09d564c460bda993cd65617070cb558b43cd79ca 100644 --- a/_articles/id/building-community.md +++ b/_articles/id/building-community.md @@ -3,10 +3,6 @@ lang: id title: Membangun Komunitas yang Ramah description: Membangun komunitas yang mendorong orang lain untuk menggunakan, berkontribusi, dan mempromosikan proyek Anda. class: building -toc: - mengarahkan-proyek-anda-untuk-kesuksesan: "Mengarahkan proyek Anda untuk kesuksesan" - mengembangkan-komunitas-anda: "Mengembangkan komunitas Anda" - menyelesaikan-konflik: "Menyelesaikan konflik" order: 4 image: /assets/images/cards/building.png related: @@ -22,7 +18,7 @@ Sebuah komunitas yang ramah merupakan investasi pada masa depan dan reputasi pro ### Buatlah agar orang-orang merasa diterima -Satu cara untuk memikirkan komunitas proyek Anda adalah melalui apa yang disebut @MikeMcQuaid sebagai [saluran kontributor](https://speakerdeck.com/mikemcquaid/the-open-source-contributor-funnel): +Satu cara untuk memikirkan komunitas proyek Anda adalah melalui apa yang disebut @MikeMcQuaid sebagai [saluran kontributor](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):  @@ -58,7 +54,7 @@ Mendorong kontributor lain adalah sebuah investasi pada diri Anda juga. Ketika A
Apakah Anda pernah menghadiri sebuah acara dimana Anda tidak mengenal siapapun, tetapi orang lain tampak saling mengenal satu sama lain dan berbicara seperti sahabat dekat? (...) Sekarang bayangkan Anda ingin berkontribusi pada proyek open source, namun Anda tidak dapat melihat kenapa dan bagaimana ini bisa terjadi.
-— @janl, ["Sustainable Open Source"](http://writing.jan.io/2015/11/20/sustainable-open-source.html) +— @janl, ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
@@ -117,10 +113,10 @@ Sembarang proyek yang terkenal akan menarik orang lain untuk merusak dibandingka Lakukan yang terbaik untuk mengadopsi kebijakan tanpa toleransi terhadap orang-orang jenis ini. Jika dibiarkan, orang-orang negatif ini akan membuat orang lain menjadi tidak nyaman. Bahkan mereka bisa meninggalkan proyek Anda. @@ -136,23 +132,23 @@ Pada dokumen CONTRIBUTING, jelaskan secara eksplisit bagaimana kontributor baru  -Pada daftar laporan masalah Anda, tandai masalah yang cocok untuk setiap jenis kontributor yang berbeda: misalnya, [_"hanya pemula"_](https://medium.com/@kentcdodds/first-timers-only-78281ea47455#.g1k01jy05), _"laporan kesalahan pertama"_, atau _"dokumentasi"_. [Label ini](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) mempermudah orang yang baru pada proyek Anda untuk mencari daftar laporan masalah dan mulai berkontribusi. +Pada daftar laporan masalah Anda, tandai masalah yang cocok untuk setiap jenis kontributor yang berbeda: misalnya, [_"hanya pemula"_](https://kentcdodds.com/blog/first-timers-only), _"laporan kesalahan pertama"_, atau _"dokumentasi"_. [Label ini](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) mempermudah orang yang baru pada proyek Anda untuk mencari daftar laporan masalah dan mulai berkontribusi. Akhirnya, gunakan dokumentasi Anda untuk membuat orang lain nyaman pada setiap langkahnya. Anda tidak akan pernah berinteraksi dengan sebagian besar orang-orang yang hadir pada proyek Anda. Bisa jadi terdapat kontribusi yang tidak Anda dapatkan karena seseorang merasa terintimidasi atau tidak tahu bagaimana memulainya. Sebuah kata-kata sederhana bisa menjaga mereka untuk tetap bertahan dan bebas dari rasa frustasi. -Sebagai contoh, berikut bagaimana cara [Rubinius](https://github.com/rubinius/rubinius/) memulai [panduan kontribusinya](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md): +Sebagai contoh, berikut bagaimana cara [Rubinius](https://github.com/rubinius/rubinius/) memulai [panduan kontribusinya](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md): > Kita ingin memulainya dengan mengucapkan terima kasih karena menggunakan Rubinius. Proyek ini merupakan hasil cinta kami, dan kami menghargai semua pengguna yang menemukan kesalahan, membuat perbaikan performa, dan membantu dengan dokumentasi. Setiap kontribusi sangat berharga, sehingga kami mengucapkan terima kasih untuk berpartisipasi. Meski demikian, berikut adalah beberapa panduan yang kami harapkan untuk bisa diikuti sehingga kami bisa menyelesaikan permasalahan Anda dengan baik. ### Berbagi kepemilikan dari proyek Anda @@ -164,11 +160,11 @@ Cari cara untuk bisa berbagi kepemilikan dengan komunitas Anda sebanyak mungkin.  -* **Bualah dokumen CONTRIBUTORS atau AUTHORS pada proyek Anda** yang mendata semua orang yang berkontribusi pada proyek Anda, seperti [Sinatra](https://github.com/sinatra/sinatra/blob/master/AUTHORS.md). +* **Bualah dokumen CONTRIBUTORS atau AUTHORS pada proyek Anda** yang mendata semua orang yang berkontribusi pada proyek Anda, seperti [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md). * Jika Anda memiliki komunitas yang cukup besar, **kirimkan surat berita atau tuliskan blog** dan ucapkan terima kasih pada kontributor. [This Week in Rust](https://this-week-in-rust.org/) milik Rust dan [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) milik Hoodie adalah dua contoh bagus. -* **Berikan setiap kontributor akses commit.** @felixge menemukan bahwa hal ini membuat orang lain [lebih tertarik untuk memperbaiki perbaikan mereka](http://felixge.de/2013/03/11/the-pull-request-hack.html), dan dia juga menemukan pengelola baru untuk proyek yang tidak dia kelola selama beberapa waktu. +* **Berikan setiap kontributor akses commit.** @felixge menemukan bahwa hal ini membuat orang lain [lebih tertarik untuk memperbaiki perbaikan mereka](https://felixge.de/2013/03/11/the-pull-request-hack.html), dan dia juga menemukan pengelola baru untuk proyek yang tidak dia kelola selama beberapa waktu. * Jika proyek Anda berada pada GitHub, **pindahkan proyek Anda dari akun personal ke [Organisasi](https://help.github.com/articles/creating-a-new-organization-account/)** dan tambahkan paling tidak satu admin cadangan. Organisasi mempermudah pekerjaan kolaborasi dengan kolaborator eksternal. @@ -218,7 +214,7 @@ Dokumen README [lebih dari sekedar sekumpulan instruksi](../starting-a-project/# Beberapa proyek menggunakan proses pemilihan suara model voting untuk pengambilan keputusan yang besar. Meskipun masuk akal di awal, voting berfokus pada mendapatkan "jawaban", dan bukan pada mendengarkan dan menjawab kekhawatiran orang lain. -Voting bisa sangat politis, dimana anggota komunitas merasa tertekan untuk melakukannya. Tidak semua memberikan suaranya, baik sebagai [silent majority](http://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) pada komunitas Anda, atau pengguna yang tidak tahu bahwa terjadi voting. +Voting bisa sangat politis, dimana anggota komunitas merasa tertekan untuk melakukannya. Tidak semua memberikan suaranya, baik sebagai [silent majority](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) pada komunitas Anda, atau pengguna yang tidak tahu bahwa terjadi voting. Seringkali voting memang diperlukan untuk memecah kebuntuan. Namun tekankan ["consensus seeking"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) daripada konsensus. @@ -254,7 +250,7 @@ Jika sebuah diskusi tidak mengarah kemana-mana, tidak ada tindakan yang jelas ya
Mengarahkan sebuah diskusi pada sebuah kegunaan tanpa bersifat memaksa adalah sebuah seni. Hal ini tidak semudah untuk meminta orang-orang untuk menghabiskan waktu mereka, atau meminta mereka untuk tidak memberikan komentar kecuali mereka memiliki ide yang konstruktif. (...) Anda harus menyarankan kondisi untuk peningkatan lebih lanjut: berikan rute kepada orang, jalur yang bisa diikuti yang mengarah pada hasil yang Anda inginkan, tanpa seolah-olah Anda mengatur perilaku mereka.
-— @kfogel, [_Producing OSS_](http://producingoss.com/en/producingoss.html#common-pitfalls) +— @kfogel, [_Producing OSS_](https://producingoss.com/en/producingoss.html#common-pitfalls)
diff --git a/_articles/id/code-of-conduct.md b/_articles/id/code-of-conduct.md index 9388a8891d2d25b9efaafb24d357cfa812b7533c..910858359b9a4e29419366d0270c13a30c8fc35d 100644 --- a/_articles/id/code-of-conduct.md +++ b/_articles/id/code-of-conduct.md @@ -3,11 +3,6 @@ lang: id title: Kode Etik Anda description: Fasilitasi perilaku komunitas yang sehat dan konstruktif dengan mengadopsi dan menerapkan kode etik. class: coc -toc: - kenapa-saya-perlu-menerapkan-kode-etik: "Kenapa saya perlu menerapkan kode etik?" - membuat-kode-etik: "Membuat kode etik" - menentukan-bagaimana-anda-akan-menerapkan-kode-etik: "Menentukan bagaimana Anda akan menerapkan kode etik" - menerapkan-kode-etik: "Menerapkan kode etik" order: 8 image: /assets/images/cards/coc.png related: @@ -34,7 +29,7 @@ Selain mengkomunikasikan ekspektasi Anda, kode etik juga menjelaskan beberapa ha * Apa yang terjadi jika seseorang melanggar kode etik * Bagaimana seseorang dapat melaporkan pelanggaran -Apabila dimungkinkan, gunakan yang sudah ada. [Contributor Covenant](http://contributor-covenant.org/) adalah kode etik yang bisa digunakan dan sudah digunakan oleh lebih dari 40.000 proyek open source, termasuk Kubernetes, Rails, dan Swift. +Apabila dimungkinkan, gunakan yang sudah ada. [Contributor Covenant](https://www.contributor-covenant.org/) adalah kode etik yang bisa digunakan dan sudah digunakan oleh lebih dari 40.000 proyek open source, termasuk Kubernetes, Rails, dan Swift. [Kode etik Django](https://www.djangoproject.com/conduct/) dan [Kode etik Warga](http://citizencodeofconduct.org/) adalah dua contoh kode etik yang bagus. @@ -59,7 +54,7 @@ Anda harus menjelaskan bagaimana kode etik Anda akan diterapkan **_sebelum_** pe Anda harus memberikan sebuah jalan yang pribadi (seperti alamat email) untuk melaporkan pelanggaran kode etik dan menjelaskan siapa yang menerima laporan tersebut. Penerima laporan bisa jadi pengelola, sekelompok orang pengelola, atau tim kode etik. -Jangan lupa bahwa seseorang mungkin melaporkan pelanggaran terhadap orang yang akan menerima laporan tersebut. Pada kasus ini, berikan opsi untuk melaporkan pelanggaran pada orang lain. Misalnya, @ctb dan @mr-c [menjelaskan pada proyek mereka](https://github.com/dib-lab/khmer/blob/master/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): +Jangan lupa bahwa seseorang mungkin melaporkan pelanggaran terhadap orang yang akan menerima laporan tersebut. Pada kasus ini, berikan opsi untuk melaporkan pelanggaran pada orang lain. Misalnya, @ctb dan @mr-c [menjelaskan pada proyek mereka](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): > Perilaku kasar, melecehkan, atau perilaku lainnya yang tidak dapat diterima dapat dilaporkan dengan mengirimkan email pada **khmer-project@idyll.org** yang akan sampai pada C. Titus Brown dan Michael R. Crusoe. Untuk melaporkan masalah pada salah satu dari mereka, kirimkan email pada **Judi Brown Clarke, Ph.D.** Direktur Diversity pada BEACON Center untuk Studi Evolusi, sebuah pusat studi NSF untuk Ilmu Pengetahuan dan Teknologi.* diff --git a/_articles/id/finding-users.md b/_articles/id/finding-users.md index 8a9aa3d3019b932979d7351195ac758baccf8fb9..05dbf7cd56be3d61d537f0d54f0bf701a33b8da9 100644 --- a/_articles/id/finding-users.md +++ b/_articles/id/finding-users.md @@ -3,13 +3,6 @@ lang: id title: Menemukan Pengguna untuk Proyek Anda description: Membantu proyek open source Anda untuk berkembang dengan cara menyampaikannya ke pengguna yang senang dengan proyek Anda class: finding -toc: - menyebarkan-kata: "Menyebarkan kata" - menentukan-pesan-anda: "Menentukan pesan Anda" - bantu-orang-lain-menemukan-dan-mengikuti-proyek-anda: "Bantu orang lain menemukan dan mengikuti proyek Anda" - ketika-pengguna-proyek-anda-online: "Ketika pengguna proyek Anda (online)" - ketika-pengguna-proyek-anda-offline: "Ketika pengguna proyek Anda (offline)" - membangun-sebuah-reputasi: "Membangun sebuah reputasi" order: 3 image: /assets/images/cards/finding.png related: @@ -33,7 +26,7 @@ Sebagai contoh, @robb menggunakan contoh kode program untuk menjelaskan kenapa p  -Untuk mendalami lebih dalam tentang penyampaian pesan, lihat panduan Mozilla ["Persona dan Jalur"](http://mozillascience.github.io/working-open-workshop/personas_pathways/) untuk mengembangkan persona pengguna. +Untuk mendalami lebih dalam tentang penyampaian pesan, lihat panduan Mozilla ["Persona dan Jalur"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) untuk mengembangkan persona pengguna. ## Bantu orang lain menemukan dan mengikuti proyek Anda @@ -72,13 +65,13 @@ Ketika Anda telah memiliki pesan untuk proyek Anda dan cara mudah bagi orang lai Kegiatan outreach online merupakan cara yang bagus untuk berbagi dan menyebarkan informasi dengan cepat. Dengan menggunakan chanel online, Anda memiliki potensi untuk menjangkau jumlah pengguna yang sangat besar. -Ambil keuntungan dari komunitas dan platform online yang sudah ada untuk menjangkau pengguna Anda. Jika proyek open source Anda adalah proyek perangkat lunak, Anda mungkin bisa menjangkau proyek Anda melalui [Stack Overflow](http://stackoverflow.com/), [reddit](http://www.reddit.com), [Hacker News](https://news.ycombinator.com/), atau [Quora](https://www.quora.com/). Temukan chanel yang Anda pikir orang-orang akan mendapatkan keuntungan dari pekerjaan Anda. +Ambil keuntungan dari komunitas dan platform online yang sudah ada untuk menjangkau pengguna Anda. Jika proyek open source Anda adalah proyek perangkat lunak, Anda mungkin bisa menjangkau proyek Anda melalui [Stack Overflow](https://stackoverflow.com/), [reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/), atau [Quora](https://www.quora.com/). Temukan chanel yang Anda pikir orang-orang akan mendapatkan keuntungan dari pekerjaan Anda. @@ -98,7 +91,7 @@ Jika tidak ada yang menanggapi atau merespon, jangan kecewa! Rilis proyek awal b Kegiatan _offline_ adalah cara yang populer untuk mempromosikan proyek baru. Kegiatan ini merupakan cara yang baik untuk menjangkau pengguna yang sibuk dan membangun koneksi yang lebih personal, terutama jika Anda tertarik untuk menjangkau para pengembang. -Jika Anda termasuk [awam pada komunikasi publik](http://speaking.io/), mulailah dengan mencari acara pertemuan lokal yang berhubungan dengan bahasa atau ekosistem dari proyek Anda. +Jika Anda termasuk [awam pada komunikasi publik](https://speaking.io/), mulailah dengan mencari acara pertemuan lokal yang berhubungan dengan bahasa atau ekosistem dari proyek Anda. diff --git a/_articles/id/getting-paid.md b/_articles/id/getting-paid.md index 1e5be9b73ee9ea6d517384e07601c171927b1ffd..861a68abaeebaab98a32ecccc1bbc79ed97a57ea 100644 --- a/_articles/id/getting-paid.md +++ b/_articles/id/getting-paid.md @@ -3,11 +3,6 @@ lang: id title: Dibayar untuk Pekerjaan Open Source description: Pertahankan pekerjaan Anda pada open source dengan mendapatkan dukungan finansial untuk waktu Anda pada proyek. class: getting-paid -toc: - kenapa-beberapa-orang-mencari-dukungan-finansial: "Kenapa beberapa orang mencari dukungan finansial" - mendanai-waktu-anda-sendiri: "Mendanai waktu Anda sendiri" - mencari-pendanaan-untuk-proyek-anda: "Mencari pendanaan untuk proyek Anda" - membangun-kasus-untuk-dukungan-finansial: "Membangun kasus untuk dukungan finansial" order: 7 image: /assets/images/cards/getting-paid.png related: @@ -37,7 +32,7 @@ Terdapat banyak alasan kenapa seseorang tidak ingin dibayar untuk pekerjaan open
Donasi finansial memang menambahkan perasaan tanggung jawab untuk beberapa orang. (...) Merupakan sesuatu yang penting bagi kami yang hidup pada dunia yang sangat cepat dan terkoneksi secara global untuk bisa mengatakan "belum waktunya, saya merasa melakukan sesuatunya dengan cara yang berbeda".
-— @alloy, ["Why We Don't Accept Donations"](http://blog.cocoapods.org/Why-we-dont-accept-donations/) +— @alloy, ["Why We Don't Accept Donations"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
@@ -59,7 +54,7 @@ Pekerjaan yang dibayar juga memungkinkan orang-orang dari berbagai latar belakan
OSS menghasilkan keuntungan yang besar pada industri teknologi, yang akan menguntungkan semua industri. (...) Namun, jika satu-satunya orang yang bisa berfokus padanya adalah orang yang beruntung dan terobsesi, maka terdapat potensi yang sangat besar.
-— @isaacs, ["Money and Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c#.ftnd5qez0) +— @isaacs, ["Money and Open Source"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
@@ -99,14 +94,14 @@ Jika perusahaan Anda mengikuti rute ini, merupakan hal yang penting untuk menjag Jika Anda tidak mampu meyakinkan perusahaan untuk memprioritaskan pekerjaan open source, pertimbangkan untuk mencari perusahaan lain yang mendorong kontribusi karyawan pada open source. Cari perusahaan yang mendedikasikan pada pekerjaan open source secara eksplisit. Sebagai contoh: -* Beberapa perusahaan, seperti [Netflix](https://netflix.github.io/) atau [PayPal](http://paypal.github.io/), memiliki halaman web yang menunjukan keterlibatan mereka pada open source -* [Rackspace](https://www.rackspace.com/en-us) mempublikasikan [kebijakan kontribusi open source](https://blog.rackspace.com/rackspaces-policy-on-contributing-to-open-source/) bagi pegawai +* Beberapa perusahaan, seperti [Netflix](https://netflix.github.io/) atau [PayPal](https://paypal.github.io/), memiliki halaman web yang menunjukan keterlibatan mereka pada open source +* [Zalando](https://opensource.zalando.com) mempublikasikan [kebijakan kontribusi open source](https://opensource.zalando.com/docs/using/contributing/) bagi pegawai Proyek-proyek yang berasal dari perusahaan besar, seperti [Go](https://github.com/golang) atau [React](https://github.com/facebook/react), juga akan memperkerjakan orang-orang untuk bekerja pada open source. Akhirnya, melihat dari kondisi pribadi Anda, Anda bisa mencoba mengumpulkan uang secara mandiri untuk mendanai proyek open source Anda. Sebagai contoh: -* @gaearon mendanai pekerjaannya pada [Redux](https://github.com/reactjs/redux) melalui [kampanye Patreon crowdfunding](http://redux.js.org/) +* @gaearon mendanai pekerjaannya pada [Redux](https://github.com/reactjs/redux) melalui [kampanye Patreon crowdfunding](https://redux.js.org/) * @andrewgodwin mendanai pekerjaan pada migrasi skema Django [melalui kampanye Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) ## Mencari pendanaan untuk proyek Anda @@ -183,5 +178,3 @@ Apakah pemberi dana memiliki persyaratan? Misalnya Anda harus bersifat nirlaba a ## Eksperimen dan jangan menyerah Mendapatkan pendanaan tidaklah mudah, baik untuk proyek open source, nirlaba, atau startup perangkat lunak, dan pada banyak kasus, Anda harus kreatif. mengindentifikasi bagaimana Anda hendak didanai, melakukan riset, dan menempatkan diri Anda pada penyandang dana akan membantu Anda membangun kasus yang meyakinkan untuk pendanaan. - -> diff --git a/_articles/id/how-to-contribute.md b/_articles/id/how-to-contribute.md index be9d765422efcd51785f424dd5cd0efeaa46eaef..32fb5cdd575a4623bb6f57f1f2f63b065262521b 100644 --- a/_articles/id/how-to-contribute.md +++ b/_articles/id/how-to-contribute.md @@ -3,13 +3,6 @@ lang: id title: Bagaimana Berkontribusi pada Open Source description: Ingin berkontribusi pada open source? Sebuah panduan untuk melakukan kontribusi open source, untuk pemula dan veteran. class: contribute -toc: - mengapa-berkontribusi-pada-open-source: "Mengapa berkontribusi pada open source?" - apa-artinya-berkontribusi: "Apa artinya berkontribusi" - berorientasi-pada-proyek-baru: "Berorientasi pada proyek baru" - menemukan-sebuah-proyek-untuk-melakukan-kontribusi: "Menemukan sebuah proyek untuk melakukan kontribusi" - bagaimana-mengajukan-kontribusi: "Bagaimana mengajukan kontribusi" - apa-yang-terjadi-setelah-anda-mengajukan-sebuah-kontribusi: "Apa yang terjadi setelah Anda mengajukan sebuah kontribusi" order: 1 image: /assets/images/cards/contribute.png related: @@ -69,7 +62,7 @@ Kesalahpahaman yang sering terjadi tentang berkontribusi pada open source adalah
Saya menjadi terkenal karena pekerjaan saya pada CocoaPods, tetapi banyak orang tidak tahu bahwa saya tidak melakukan pekerjaan yang berarti pada perangkat CocoaPods itu sendiri. Waktu saya pada proyek lebih banyak dihabiskan untuk melakukan kegiatan seperti dokumentasi dan pencitraan.
-— @orta, ["Moving to OSS by default"](https://realm.io/news/orta-therox-moving-to-oss-by-default/) +— @orta, ["Moving to OSS by default"](https://academy.realm.io/posts/orta-therox-moving-to-oss-by-default/)
@@ -127,7 +120,7 @@ Meskipun Anda suka untuk menulis kode program, kontribusi jenis lain merupakan c ### Apakah Anda suka membantu orang lain? -* Menjawab pertanyaan tentang proyek, pada (misalnya) Stack Overflow ([seperti contoh Postgres ini](http://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) atau reddit +* Menjawab pertanyaan tentang proyek, pada (misalnya) Stack Overflow ([seperti contoh Postgres ini](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) atau reddit * Menjawab pertanyaan pada permasalahaan terbuka * Membantu memoderasi halaman diskusi atau chanel diskusi @@ -155,7 +148,7 @@ Meskipun Anda seorang pengembang perangkat lunak, bekerja pada proyek dokumentas
Jika Anda mengunjungi issue tracker dan tampaknya membingungkan, hal itu terjadi bukan hanya kepada Anda saja. Perangkat ini membutuhkan banyak pemahaman implisit, tetapi orang lain mampu membantu Anda dalam mengeksplorasi dan Anda bisa bertanya kepada mereka.
-— @shaunagm, ["How to Contribute to Open Source"](http://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/) +— @shaunagm, ["How to Contribute to Open Source"](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
@@ -212,18 +205,19 @@ Open source bukanlah klub ekslusif; Open source dibuat oleh orang-orang seperti Anda bisa melihat dokumen README dan menemukan tautan yang tidak valid atau kesalahan pengetikkan. Atau Anda sebagai pengguna baru dan melihat bahwa ada yang salah, atau sebuah laporan dimana Anda rasa penting untuk didokumentasikan. Daripada mengabaikannya, atau meminta orang lain untuk memperbaikinya, cari tahu apakah Anda bisa membantu dengan ikut serta didalamnya. Itulah makna sesungguhnya dari open source! -> [28% dari kontribusi umum](http://www.igor.pro.br/publica/papers/saner2016.pdf) pada open source adalah berupa dokumentasi, seperti kesalahan pengetikkan, pemformatan ulang, atau menuliskan terjemahan. +> [28% dari kontribusi umum](https://www.igor.pro.br/publica/papers/saner2016.pdf) pada open source adalah berupa dokumentasi, seperti kesalahan pengetikkan, pemformatan ulang, atau menuliskan terjemahan. Anda juga bisa menggunakan salah satu dari beberapa sumber daya berikut untuk mencari dan berkontribusi pada proyek baru: * [GitHub Explore](https://github.com/explore/) * [Open Source Friday](https://opensourcefriday.com) -* [First Timers Only](http://www.firsttimersonly.com/) -* [Your First PR](https://yourfirstpr.github.io/) +* [First Timers Only](https://www.firsttimersonly.com/) * [CodeTriage](https://www.codetriage.com/) * [24 Pull Requests](https://24pullrequests.com/) -* [Up For Grabs](http://up-for-grabs.net/) +* [Up For Grabs](https://up-for-grabs.net/) * [Contributor-ninja](https://contributor.ninja) +* [First Contributions](https://firstcontributions.github.io) +* [SourceSort](https://www.sourcesort.com/) ### Daftar sebelum Anda berkontribusi @@ -375,7 +369,7 @@ Sebuah proyek yang bersahabat dan menyambut menandai bahwa mereka sangat menerim
Setiap kali Anda melihat diskusi yang panjang, amati respon dari pengembang inti di bagian akhir dari diskusi. Apakah mereka meringkasnya secara konstruktif dan mengambil langkah-langkah untuk mendapatkan kesimpulan tanpa mengabaikan sopan santun? Jika Anda melihat banyak perdebatan yang tidak konstruktif (_flame war_), biasanya merupakan sebuah tanda bahwa energi dihabiskan untuk berargumentasi dibandingkan untuk pengembangan proyek.
-— @kfogel, [_Producing OSS_](http://producingoss.com/en/evaluating-oss-projects.html) +— @kfogel, [_Producing OSS_](https://producingoss.com/en/evaluating-oss-projects.html)
@@ -391,7 +385,7 @@ Apakah Anda merupakan kontributor atau mencoba untuk bergabung dengan sebuah kom
\[Sebagai kontributor baru,\] saya menyadari bahwa saya perlu bertanya jika ingin menutup sebuah laporan masalah. Saya mengamati kode program. Setelah saya mengetahui situasinya, saya bertanya untuk pengarahan lebih lanjut. Dan akhirnya! Saya berhasil menutup sebuah laporan masalah setelah mendapatkan semua informasi relevan yang saya butuhkan.
-— @shubheksha, [A Beginner's Very Bumpy Journey Through The World of Open Source](https://medium.freecodecamp.com/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39#.pcswr2e78) +— @shubheksha, [A Beginner's Very Bumpy Journey Through The World of Open Source](https://www.freecodecamp.org/news/a-beginners-very-bumpy-journey-through-the-world-of-open-source-4d108d540b39/)
@@ -447,7 +441,7 @@ Jika Anda tidak bisa menemukan ide Anda dimanapun, Anda siap untuk bergerak. Jik Sebelum Anda membuka sebuah laporan masalah atau melakukan pull request, periksa dokumen kontribusi proyek (biasanya pada dokumen bernama CONTRIBUTING, atau pada README), untuk melihat apakah Anda perlu mencantumkan informasi yang spesifik. Sebagai contoh, mereka mungkin meminta Anda untuk mengikuti sebuah template, atau mengharuskan Anda untuk menggunakan perangkat pengujian. -Jika Anda hendak melakukan kontribusi yang cukup substansial, buatlah sebuah laporan masalah sebelum memulai bekerja. Sangatlah bermanfaat untuk mengamati proyek dalam kurun waktu tertentu (pada Github, [Anda bisa memilih menu "Watch"](https://help.github.com/articles/watching-repositories/) untuk mendapatkan notifikasi dari semua percakapan), dan mengenal anggota komunitas, sebelum memulai pekerjaan yang belum tentu akan diterima. +Jika Anda hendak melakukan kontribusi yang cukup substansial, buatlah sebuah laporan masalah sebelum memulai bekerja. Sangatlah bermanfaat untuk mengamati proyek dalam kurun waktu tertentu (pada GitHub, [Anda bisa memilih menu "Watch"](https://help.github.com/articles/watching-repositories/) untuk mendapatkan notifikasi dari semua percakapan), dan mengenal anggota komunitas, sebelum memulai pekerjaan yang belum tentu akan diterima. @@ -105,15 +97,15 @@ Terdapat tiga struktur pengelolaan yang umumnya dipakai pada proyek open source. * **BDFL:** BDFL kependekan dari "Benevolent Dictator for Life". Pada struktur ini, satu orang (biasanya pendiri proyek) memiliki keputusan final terhadap semua keputusan proyek. [Python](https://github.com/python) adalah contoh klasik. Proyek yang lebih kecil biasanya menganut model BDFL secara default, karena hanya terdapat satu atau dua pengelola. Sebuah proyek yang berawal dari sebuah perusahaan juga bisa masuk kedalam kategori BDFL. -* **Meritokrasi:** **(Catatan: istilah "meritokrasi" memiliki konotasi negatif pada beberapa komunitas dan [sejarah sosial dan politis yang kompleks](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Pada model meritokrasi, kontributor aktif sebuah proyek (mereka yang "layak") diberikan peran dalam pengambilan keputusan formal. Keputusan biasanya dilakukan berdasarkan konsensus voting. Konsep ini diciptakan oleh [Yayasan Apache](http://www.apache.org/); [semua proyek Apache](http://www.apache.org/index.html#projects-list) menganut model ini. Kontribusi hanya dapat dilakukan secara perseorangan mewakili dirinya sendiri, bukan untuk sebuah perusahaan. +* **Meritokrasi:** **(Catatan: istilah "meritokrasi" memiliki konotasi negatif pada beberapa komunitas dan [sejarah sosial dan politis yang kompleks](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Pada model meritokrasi, kontributor aktif sebuah proyek (mereka yang "layak") diberikan peran dalam pengambilan keputusan formal. Keputusan biasanya dilakukan berdasarkan konsensus voting. Konsep ini diciptakan oleh [Yayasan Apache](https://www.apache.org/); [semua proyek Apache](https://www.apache.org/index.html#projects-list) menganut model ini. Kontribusi hanya dapat dilakukan secara perseorangan mewakili dirinya sendiri, bukan untuk sebuah perusahaan. -* **Kontribusi liberal:** Pada model ini, orang-orang yang banyak melakukan pekerjaan adalah yang dianggap berperan, namun ini berbasiskan pada pekerjaan saat ini dan bukan kontribusi yang lampau. Pengambilan keputusan pada proyek berdasarkan pada proses pencarian konsensus dibandingkan voting murni, dan mencoba melibatkan banyak pandangan dari komunitas. Contoh populer proyek yang menggunakan model ini meliputi [Node.js](https://nodejs.org/en/foundation/) dan [Rust](https://www.rust-lang.org/en-US/). +* **Kontribusi liberal:** Pada model ini, orang-orang yang banyak melakukan pekerjaan adalah yang dianggap berperan, namun ini berbasiskan pada pekerjaan saat ini dan bukan kontribusi yang lampau. Pengambilan keputusan pada proyek berdasarkan pada proses pencarian konsensus dibandingkan voting murni, dan mencoba melibatkan banyak pandangan dari komunitas. Contoh populer proyek yang menggunakan model ini meliputi [Node.js](https://foundation.nodejs.org/) dan [Rust](https://www.rust-lang.org/). Mana yang harus Anda gunakan? Semuanya tergantung Anda! Setiap model memiliki kelebihan dan kekurangan. Meskipun pada awalnya mereka tampak berbeda di awal, semua model memiliki banyak kesamaan. Jika Anda tertarik untuk mengadopsi salah satu model tersebut, silahkan lihat beberapa template berikut: * [template model BDFL](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) * [template model meritokrasi](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) -* [kebijakan kontribusi liberal Node.js](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951#.m9ht26e79) +* [kebijakan kontribusi liberal Node.js](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) ## Apakah saya perlu dokumentasi pengelolaan ketika Saya merilis proyek Saya? @@ -125,7 +117,7 @@ Jika Anda bagian dari sebuah perusahaan yang merilis proyek open source, maka ak @@ -72,7 +64,7 @@ Di satu sisi, jika salah satu dari lisensi ketergantungan Anda adalah "copyleft" Anda juga perlu memperhatikan **komunitas** akan menggunakan dan berkontribusi pada proyek Anda: -* **Apakah Anda ingin proyek Anda digunakan sebagai ketergantungan oleh proyek lain?** Mungkin paling tepat untuk menggunakan lisensi yang paling populer pada komunitas Anda. Sebagai contoh, [MIT](https://choosealicense.com/licenses/mit/) adalah lisensi yang paling populer untuk [pustaka npm](https://libraries.io/npm). +* **Apakah Anda ingin proyek Anda digunakan sebagai ketergantungan oleh proyek lain?** Mungkin paling tepat untuk menggunakan lisensi yang paling populer pada komunitas Anda. Sebagai contoh, [MIT](https://choosealicense.com/licenses/mit/) adalah lisensi yang paling populer untuk [pustaka npm](https://libraries.io/search?platforms=NPM). * **Apakah Anda ingin proyek Anda menarik bagi kalangan bisnis skala besar?** Kalangan bisnis yang berskala besar memiliki kencenderungan untuk menggunakan lisensi paten ekspress dari semua kontributor. Dalam hal ini, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) dapat mencakup Anda dan mereka. * **Apakah Anda ingin proyek Anda menarik bagi kontributor yang tidak ingin hasil kontribusinya tidak digunakan pada perangkat lunak tertutup?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) atau (jika mereka juga tidak mau berkontribusi pada layanan tertutup) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) merupakan pilihan yang tepat. @@ -96,7 +88,7 @@ Alternatif lain, Anda bisa mendapatkan persetujuan kontributor di awal (melalui ## Apakah proyek saya membutuhkan perjanjian kontributor tambahan? -Kemungkinan tidak. Untuk sebagian besar proyek open source, lisensi open source secara implisit berfungsi sebagai lisensi inbound (dari kontributor) dan outbound (bagi kontributor dan pengguna lainnya). Jika proyek Anda berada pada GitHub, Perjanjian Layanan GitHub membuat aturan "inbound=outbound" [default secara eksplisit](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license). +Kemungkinan tidak. Untuk sebagian besar proyek open source, lisensi open source secara implisit berfungsi sebagai lisensi inbound (dari kontributor) dan outbound (bagi kontributor dan pengguna lainnya). Jika proyek Anda berada pada GitHub, Perjanjian Layanan GitHub membuat aturan "inbound=outbound" [default secara eksplisit](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license). Sebuah perjanjian kontributor tambahan -- seringkali disebut Contributor License Agreement (CLA) -- bisa menimbulkan pekerjaan administratif tambahan bagi pengelola proyek. Seberapa banyak pekerjaan tersebut tergantung dari proyek dan implementasinya. Sebuah perjanjian yang sederhana mungkin meminta kontributor untuk melakukan konfirmasi dengan satu klik, bahwa mereka memiliki hak yang cukup untuk berkontribusi dibawah lisensi open source. Perjanjian yang lebih kompleks mungkin membutuhkan review hukum dan tanda tangan dari perusahaan yang memperkerjakan kontributor tersebut. @@ -152,7 +144,7 @@ Dalam jangka panjang, tim hukum Anda bisa melakukan lebih banyak lagi dengan mem * **Apa yang dirilis:** [(Hampir) semuanya?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) jika tim hukum Anda memahami dan berinvestasi pada strategi open source perusahaan Anda, mereka akan banyak membantu dibandingkan merugikan Anda. -* **Kesesuaian:** Meskipun perusahaan Anda tidak merilis proyek open source, perusahaan Anda menggunakan perangkat lunak open source milik orang lain. [Kewaspadaandan proses](https://www.linux.com/blog/why-companies-use-open-source-need-compliance-program) bisa mencegah masalah, keterlambatan produk, dan tuntutan hukum. +* **Kesesuaian:** Meskipun perusahaan Anda tidak merilis proyek open source, perusahaan Anda menggunakan perangkat lunak open source milik orang lain. [Kewaspadaandan proses](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) bisa mencegah masalah, keterlambatan produk, dan tuntutan hukum. -[Terdapat banyak alasan](http://ben.balter.com/2015/11/23/why-open-source/) kenapa seseorang atau sebuah organisasi ingin membuka proyek open source. Beberapa diantaranya meliputi: +[Terdapat banyak alasan](https://ben.balter.com/2015/11/23/why-open-source/) kenapa seseorang atau sebuah organisasi ingin membuka proyek open source. Beberapa diantaranya meliputi: * **Kolaborasi:** Proyek open source bisa menerima perubahan dari siapapun juga di seluruh dunia. [Exercism](https://github.com/exercism/), sebagai contoh, adalah kerangka latihan pemrograman dengan lebih dari 350 kontributor. -* **Adopsi dan menggabungkan:** Proyek open source bisa digunakan oleh siapapun untuk hampir semua tujuan. Bahkan bisa digunakan untuk membangun proyek lain. [WordPress](https://github.com/WordPress), sebagai contoh, dimulai dari hasil _fork_ dari proyek yang sudah ada bernama [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md). +* **Adopsi dan menggabungkan:** Proyek open source bisa digunakan oleh siapapun untuk hampir semua tujuan. Bahkan bisa digunakan untuk membangun proyek lain. [WordPress](https://github.com/WordPress), sebagai contoh, dimulai dari hasil _fork_ dari proyek yang sudah ada bernama [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md). * **Transparansi:** Setiap orang dapat melihat kesalahan atau inkonsistensi pada proyek open source. Transparansi sangat penting bagi pemerintah seperti [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) atau [Amerika Serikat](https://sourcecode.cio.gov/), industri yang memiliki regulasi seperti perbankan atau kesehatan, dan perangkat lunak keamanan seperti [Let's Encrypt](https://github.com/letsencrypt). @@ -85,7 +79,7 @@ Jika tujuan akhir Anda adalah untuk menunjukkan hasil pekerjaan Anda, Anda mungk
Pada suatu titik saya menciptakan UIAlertView hasil modifikasi yang saya gunakan...dan saya memutuskan untuk membuatnya menjadi open source. Lalu saya memodifikasinya menjadi lebih dinamis dan menyimpannya di GitHub. Saya menulis dokumentasi pertama saya dengan menjelaskan kepada pengembang lain bagaimana untuk menggunakannya pada proyek mereka. Mungkin saja tidak ada orang lain yang akan menggunakannya karena merupakan proyek sederhana, tetapi saya memiliki perasaan yang baik tentang kontribusi yang saya lakukan.
-— @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576#.zhwo5krlq) +— @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
@@ -101,7 +95,7 @@ Jika Anda membutuhkan pendanaan yang permanen atau alokasi staf untuk promosi, o
Ketika Anda mulai untuk membuka proyek Anda pada open source, sangatlah penting untuk memastikan bahwa proses manajemen Anda memperhatikan kontribusi dan kemampuan dari komunitas disekeliling proyek Anda. Jangan takut untuk melibatkan kontributor yang bukan merupakan karyawan sebagai aspek kunci dalam proyek - terutama jika mereka adalah kontributor yang aktif.
-— @captainsafia, ["So you wanna open source a project, eh?"](https://writing.safia.rocks/2016/12/06/so-you-wanna-open-source-a-project-eh/) +— @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
@@ -156,10 +150,10 @@ Pada dokumen README, cobalah untuk menjawab pertanyaan berikut: Anda bisa menggunakan README untuk menjawab pertanyaan lainnya, seperti bagaiman Anda akan menangani kontribusi, apa tujuan akhir dari proyek, dan informasi tentang lisensi. Jika Anda tidak ingin menerima kontribusi, atau proyek Anda belum siap untuk produksi, tuliskan informasi ini. @@ -185,7 +179,7 @@ Selain aspek teknis, dokumen CONTRIBUTING juga merupakan kesempatan untuk mengko Menggunakan nada yang bersahabat dan menawarkan tawaran yang spesifik untuk kontribusi (misalnya menuliskan dokumentasi, atau membuat halaman web) bisa membuat pendatang merasa nyaman dan diterima serta tertarik untuk berpartisipasi. -Sebagai contoh, [Active Admin](https://github.com/activeadmin/activeadmin/) memulai [panduan kontribusinya](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) dengan: +Sebagai contoh, [Active Admin](https://github.com/activeadmin/activeadmin/) memulai [panduan kontribusinya](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) dengan: > Pertama-tama, terima kasih karena Anda mempertimbangkan untuk berpartisipasi pada Active Admin. Orang-orang seperti Anda yang membuat Active Admin menjadi sebuah perangkat yang hebat. @@ -193,7 +187,7 @@ Pada fase awal dari proyek Anda, dokumen CONTRIBUTING bisa sangat sederhana. And Seiring dengan berjalannya waktu, Anda bisa menambahkan pertanyaan yang paling sering ditanyakan pada dokumen CONTRIBUTING. Menuliskan informasi ini berarti lebih sedikit orang yang akan bertanya pertanyaan yang sama kepada Anda berulang kali. -Untuk bantuan tentang penulisan dokumen CONTRIBUTING, silahkan lihat [template panduan berkontribusi](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) milik @nayafia atau ["Bagaimana Membangun Dokumen CONTRIBUTING.md"](http://mozillascience.github.io/working-open-workshop/contributing/) milik @mozilla. +Untuk bantuan tentang penulisan dokumen CONTRIBUTING, silahkan lihat [template panduan berkontribusi](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) milik @nayafia atau ["Bagaimana Membangun Dokumen CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/) milik @mozilla. Hubungkan dokumen CONTRIBUTING dari README, sehingga lebih banyak orang yang melihatnya. Jika Anda [meletakkan dokumen CONTRIBUTING pada repositori proyek](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub akan secara otomatis menghubungkan ke dokumen Anda ketika seorang kontributor membuat sebuah laporan masalah atau membuat pull request. @@ -205,7 +199,7 @@ Hubungkan dokumen CONTRIBUTING dari README, sehingga lebih banyak orang yang mel
Kita semua pernah memiliki pengalaman dimana kita dihadapkan dengan penyalahgunaan, baik sebagai pengelola yang menjelaskan kenapa sesuatu harus dilakukan dengan cara tertentu, atau sebagai pengguna...bertanya sebuah pertanyaan sederhana. (...) Kode etik merupakan dokumen yang mudah untuk dijadikan referensi yang mengindikasikan bahwa tim Anda sangat memperhatikan wacana yang bersifat membangun.
-— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f#.v4qhl7t7v) +— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
@@ -256,13 +250,13 @@ Baik dokumentasi resmi atau email sehari-hari, gaya penulisan Anda merupakan bag
Saya berusaha untuk ikut terlibat pada setiap diskusi pada mailing list, dan memberikan contoh panutan, bertindak baik kepada orang-orang, menganggap masalah mereka sebagai sesuatu yang serius, dan berusaha untuk membantu. Setelah beberapa waktu, orang-orang tidak hanya berhenti karena ada masalah, namun juga ikut membantu, dan mereka mengikuti gaya saya.
-— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](http://writing.jan.io/2015/11/20/sustainable-open-source.html) +— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
Menggunakan bahasa yang hangat, inklusif (seperti "mereka", meskipun mengacu pada satu orang) bisa membuat proyek Anda lebih nyaman bagi kontributor baru. Gunakan bahasa sederhana, karena bisa jadi banyak pengguna Anda bukan merupakan pengguna yang menggunakan bahasa Inggris sehari-harinya. -Selain bagaimana Anda menuliskan kata-kata, gaya pemrograman Anda juga bisa menjadi bagian dari citra proyek Anda. [Angular](https://github.com/johnpapa/angular-styleguide) dan [jQuery](http://contribute.jquery.org/style-guide/js/) adalah dua contoh proyek dengan gaya pemrograman dan panduan yang lengkap. +Selain bagaimana Anda menuliskan kata-kata, gaya pemrograman Anda juga bisa menjadi bagian dari citra proyek Anda. [Angular](https://github.com/johnpapa/angular-styleguide) dan [jQuery](https://contribute.jquery.org/style-guide/js/) adalah dua contoh proyek dengan gaya pemrograman dan panduan yang lengkap. Tidaklah penting untuk menuliskan gaya penulisan untuk proyek Anda ketika Anda baru memulainya dan Anda mungkin senang untuk mencoba beberapa gaya pemrograman pada proyek Anda. Tetapi Anda perlu mengantisipasi bagaimana penulisan dan pemrograman Anda bisa memikat orang atau malah membuat orang untuk menghindari proyek Anda. Tahap awal dari proyek Anda adalah kesempatan untuk menentukan arah yang Anda tuju. @@ -330,7 +324,7 @@ Jika Anda perseorangan:
Financial donations do add a feeling of responsibility, for some. (...) It's important for us, in the globally connected, fast-paced world we live in, to be able to say "not now, I feel like doing something completely different".
-— @alloy, ["우리가 왜 기여를 허락하면 안되는가"](http://blog.cocoapods.org/Why-we-dont-accept-donations/) +— @alloy, ["우리가 왜 기여를 허락하면 안되는가"](https://blog.cocoapods.org/Why-we-dont-accept-donations/)
@@ -59,7 +54,7 @@ I was looking for a "hobby" programming project that would keep me occupied duri
OSS yields massive benefits to the technology industry, which, in turn, means benefits to all industries. (...) However, if the only people who can focus on it are the lucky and the obsessed, then there's a huge untapped potential.
-— @isaacs, ["현금과 오픈소스"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c#.ftnd5qez0) +— @isaacs, ["현금과 오픈소스"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c)
@@ -99,14 +94,14 @@ I was looking for a "hobby" programming project that would keep me occupied duri 현 고용주가 오픈소스 업무의 우선 순위를 결정할 수 없다면, 직원의 오픈소스 기여도를 높이는 새로운 고용주를 찾는 것이 좋습니다. 오픈소스 작업에 대한 헌신을 분명히 하는 회사를 찾아보십시오. 예시입니다 : -* 일부 회사는, [넷플릭스](https://netflix.github.io/)혹은 [페이팔](http://paypal.github.io/)처럼, 오픈소스에 대한 그들의 참여를 강조하는 웹 사이트를 가지고있습니다 -* [Rackspace](https://www.rackspace.com/en-us)는 직원을 위한 [오픈소스 기여 정책](https://blog.rackspace.com/rackspaces-policy-on-contributing-to-open-source/)을 게시했습니다 +* 일부 회사는, [넷플릭스](https://netflix.github.io/)혹은 [페이팔](https://paypal.github.io/)처럼, 오픈소스에 대한 그들의 참여를 강조하는 웹 사이트를 가지고있습니다 +* [Zalando](https://opensource.zalando.com)는 직원을 위한 [오픈소스 기여 정책](https://opensource.zalando.com/docs/using/contributing/)을 게시했습니다 [Go](https://github.com/golang)또는 [React](https://github.com/facebook/react)와 같은 대기업에서 시작된 프로젝트도, 오픈소스 작업에 사람들을 고용 할 가능성이 높습니다. 마지막으로, 개인적인 상황에 따라, 오픈소스 작업을 위해 독립적으로 돈을 모으는 노력을 할 수 있습니다. 예시: -* @gaearon은 [Patreon crowdfunding campaign](http://redux.js.org/)을 통해 [Redux](https://github.com/reactjs/redux)에 대한 그의 작업에 펀드했습니다. +* @gaearon은 [Patreon crowdfunding campaign](https://redux.js.org/)을 통해 [Redux](https://github.com/reactjs/redux)에 대한 그의 작업에 펀드했습니다. * @andrewgodwin은 Django 스키마 마이그레이션 작업을 [Kickstarter 캠페인을 통해](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) 펀드했습니다. ## Finding funding for your project diff --git a/_articles/ko/how-to-contribute.md b/_articles/ko/how-to-contribute.md index a7443931070481982681afa79ba7d26cb15be019..8ba1371726bbe60909f11601f5d36bb050b92631 100644 --- a/_articles/ko/how-to-contribute.md +++ b/_articles/ko/how-to-contribute.md @@ -1,15 +1,8 @@ --- lang: ko title: 오픈소스에 기여하는 방법 -description: 오픈소스에 기여하고 싶습니까? 초보자와 숙련자를 위한 오픈소스 기여에 대한 가이드입니다. +description: 오픈소스에 기여하고 싶으세요? 초보자와 숙련자를 위한 오픈소스 기여 가이드입니다. class: contribute -toc: - why-contribute-to-open-source: "왜 오픈소스에 기여 하나요?" - what-it-means-to-contribute: "기여한다는 것의 의미" - orienting-yourself-to-a-new-project: "새로운 프로젝트에 동참하기" - finding-a-project-to-contribute-to: "기여할 프로젝트 찾기" - how-to-submit-a-contribution: "기여 제출 방법" - what-happens-after-you-submit-a-contribution: "기여를 제출하면 어떻게됩니까?" order: 1 image: /assets/images/cards/contribute.png related: @@ -23,131 +16,131 @@ related:
Working on \[freenode\] helped me earn many of the skills I later used for my studies in university and my actual job. I think working on open source projects helps me as much as it helps the project!
-— @errietta, ["왜 나는 오프소스 소프트웨어에 기여하는 것을 좋아하는가"](https://www.errietta.me/blog/open-source/) +— @errietta, ["Why I love contributing to open source software”](https://www.errietta.me/blog/open-source/)
-오픈소스에 기여하는 것은 당신이 상상할 수 있는 모든 기술을 배우고, 가르치고, 구축하는 보람찬 방법이 될 수 있습니다. +오픈소스에 기여하는 것은 여러분이 상상할 수 있는 모든 기술을 배우고, 가르치고, 구현하는 보람찬 방법이 될 수 있습니다. -왜 사람들은 오픈소스에 기여합니까? 이에는 많은 이유가 있습니다! +왜 사람들은 오픈소스에 기여할까요? 많은 이유가 있습니다! -### 기존 기술 향상 +### 기존 기술을 향상시키세요 -코딩, 사용자 인터페이스 디자인, 그래픽 디자인, 글쓰기 또는 조직화등의 실습을 원한다면 오픈소스 프로젝트에 대한 작업이 있습니다. +코딩, 사용자 인터페이스 디자인, 그래픽 디자인, 글쓰기 또는 조직화 등의 실습을 원한다면 여러분이 맡을 수 있는 오픈소스 프로젝트 작업이 기다리고 있습니다. -### 비슷한 것에 관심이있는 사람들을 만나십시오 +### 비슷한 것에 관심 있는 사람들을 만나세요 -따뜻하고 환영하는 커뮤니티가 있는 오픈소스 프로젝트는 사람들이 수년간 돌아오도록합니다. 많은 사람들이 부리토에 관한 회의나 심야 온라인 채팅를 가지고 서로를 실행하고 있든간에 오픈소스에 참여함으로써 평생동안 우정을 나누고 있습니다. +따뜻한 커뮤니티가 있는 오픈소스 프로젝트는 사람들은 오래 머물게 합니다. 많은 사람들이 오픈소스에 참여하며 평생의 우정을 다지고 있습니다. 그게 회의에서 서로를 마주치는 것이든 한밤중에 부리토에 관해 채팅을 하는 것이든 상관없이요. -### 멘토를 찾고 다른 사람들을 가르치십시오 +### 멘토를 찾고 사람들과 배움을 주고받으세요 -공유 프로젝트에서 다른 사람들과 함께 일한다는 것은 당신이 일을 어떻게하는지 설명하고, 다른 사람들에게 도움을 요청해야 함을 의미합니다. 학습하고 가르치는 행위는 관련된 모든 사람들에게 성취감있는 활동이 될 수 있습니다. +공유 프로젝트에서 다른 사람들과 함께 일한다는 것은 여러분이 무엇을 어떻게 하는지 설명하고, 다른 사람들에게 도움을 요청해야 함을 의미합니다. 학습하고 가르치는 행위는 관련된 모든 사람들에게 성취감 있는 활동이 될 수 있습니다. -### 평판(및 경력)을 키우는 데 도움이 되는 공공 예제 만들기 +### 평판(과 경력)을 쌓는 데 도움이 되는 예제를 만드세요 -정의에 따르면, 모든 오픈소스 저작물은 공개되어 있으므로, 어디서나 할 수 있는 무료 예제를 얻을 수 있습니다. +정의에 따라 모든 오픈소스 저작물은 공개되어 있으므로, 당신이 할 수 있는 것을 보여줄 예제를 가질 수 있는 셈입니다. -### 사람들의 기술 습득 +### 사람을 대하는 기술을 습득하세요 -오픈소스는 충돌 해결, 사람들의 팀 구성 및 작업 우선순위 지정과 같은 리더십 및 관리 기술을 연습 할 수있는 기회를 제공합니다. +오픈소스는 충돌 해결, 팀 구성, 작업 우선순위 지정과 같은 리더십 및 관리 기술을 연습할 수 있는 기회를 제공합니다. -### 작은 것조차도 변경할 수 있는 힘이 있습니다 +### 작은 것조차도 바꿀 수 있는 힘이 있습니다 -오픈소스에 참여하는 것을 즐기는 평생 기여자가 될 필요는 없습니다. 웹 사이트에 오타가 있는 것을 본 적이 있고, 누군가 그것을 고치기를 바랬습니까? 오픈소스 프로젝트에서 여러분은 그렇게 할 수 있습니다. 오픈소스는 사람들이 삶에 대해 어떻게 대처하고 그들이 세상을 경험하는지를 느끼도록 도와줍니다. +오픈소스에 참여하는 것을 즐기는 평생 기여자가 될 필요는 없습니다. 웹 사이트에서 오타를 발견하고 누군가가 고쳐주길 바란 적 있나요? 오픈소스 프로젝트에서 여러분은 그렇게 할 수 있습니다. 오픈소스는 사람들이 삶에 대해 어떻게 대처하고 그들이 세상을 경험하는지를 느끼도록 도와줍니다. ## What it means to contribute -새로운 오픈소스 기여자라면, 기여하는 과정이 위협적일 수 있습니다. 올바른 프로젝트를 어떻게 찾을 수 있습니까? 코딩 방법을 모르는 경우에는 어떻게 해야합니까? 뭔가 잘못되면 어떡하죠? +새로운 오픈소스 기여자라면, 기여하는 과정이 겁날 수도 있습니다. 알맞은 프로젝트를 어떻게 찾아야 할까요? 코딩을 할 줄 모른다면요? 뭔가 잘못되면 어떡하죠? 걱정 마세요! 오픈소스 프로젝트에 참여하는 데는 여러 가지 방법이 있으며, 몇 가지 팁을 통해 경험을 최대한 활용할 수 있습니다. ### 코드를 제공할 필요가 없습니다 -오픈소스에 기여하는 것에 대한 일반적인 오해는 코드를 작성해야한다는 것입니다. 실제로 대부분 프로젝트에서 [무시되거나 간과되는 부분](https://github.com/blog/2195-the-shape-of-open-source)입니다 . 이러한 유형의 기여를 제공하도록 제안함으로써 프로젝트에 큰 도움을 줄 것입니다! +오픈소스에 기여하는 것에 대한 일반적인 오해는 코드를 작성해야 한다는 것입니다. 사실, 프로젝트의 다른 부분이 [무시되거나 간과되는 경우](https://github.com/blog/2195-the-shape-of-open-source)가 더 많습니다. 이러한 유형의 기여에 동참하겠다고 제안하면 프로젝트에 큰 도움이 될 것입니다. -코드 작성을 원한다고해도, 다른 유형의 기여는 프로젝트에 참여하고 다른 커뮤니티 회원을 만날 수 있는 좋은 방법입니다. 이러한 관계를 구축하면 프로젝트의 다른 부분에서 작업 할 수있는 기회가 주어집니다. +코드를 작성하는 것을 좋아해도, 다른 유형의 기여는 프로젝트에 참여하고 다른 커뮤니티 구성원을 만날 수 있는 좋은 방법입니다. 이러한 관계를 구축하면 프로젝트의 다른 부분에서 작업할 기회를 얻을 수 있습니다. -### 기획 행사가 마음에 드십니까? +### 행사 계획 짜는 걸 좋아하세요? -* [@fzamperin이 NodeSchool에 대했던 것처럼](https://github.com/nodeschool/organizers/issues/406), 프로젝트에 관한 워크샵이나 모임을 조직하기 +* [NodeSchool을 위해 @fzamperin이 했던 것처럼](https://github.com/nodeschool/organizers/issues/406), 프로젝트에 관한 워크샵이나 미팅 조직하기 * 프로젝트 컨퍼런스 구성하기 (있는 경우) -* 커뮤니티 구성원들이 적절한 회의를 찾고 말하기에 대한 제안서 제출하기 +* 커뮤니티 구성원이 적합한 컨퍼런스를 찾고 발언을 위한 제안서를 제출할 수 있도록 지원하기 -### 디자인하고 싶습니까? +### 디자인을 하고 싶으세요? * 프로젝트의 유용성을 높이기 위해 레이아웃 재구성하기 -* [Drupal 제안처럼](https://www.drupal.org/community-initiatives/drupal-core/usability),사용자 조사를 통해, 프로젝트의 네비게이션 또는 메뉴를 재구성하고 수정하기 -* 프로젝트가 일관성있는 시각적 디자인을 가질 수 있도록, 스타일 가이드를 작성하기 -* [hapi.js의 기여처럼](https://github.com/hapijs/contrib/issues/68), 티셔츠 혹은 새로운 로고를 위한 예슐 작품 만들기 +* [Drupal의 제안](https://www.drupal.org/community-initiatives/drupal-core/usability)처럼, 사용자 조사를 통해 프로젝트의 네비게이션 또는 메뉴를 재구성하고 개선하기 +* 프로젝트가 일관성 있는 시각적 디자인을 가질 수 있도록 스타일 가이드 작성하기 +* [hapi.js의 기여](https://github.com/hapijs/contrib/issues/68)처럼, 티셔츠 혹은 새로운 로고를 위한 예술 작품 만들기 -### 글 쓰고 싶습니까? +### 글을 쓰고 싶으신가요? -* 프로젝트의 문서 작성 및 개선하기 -* 프로젝트 사용법을 보여주는 예제 폴더를 선별하기 -* 프로젝트의 뉴스 레터를 시작하거나 메일링 리스트의 하이라이트를 관리하십시오. -* [PyPA의 기여처럼](https://github.com/pypa/python-packaging-user-guide/issues/194), 프로젝트의 튜토리얼을 작성하기. -* 프로젝트의 문서의 번역문 작성하기 +* 프로젝트 문서 작성 및 개선하기 +* 프로젝트 사용법을 보여주는 예제 폴더 선별하기 +* 프로젝트의 뉴스레터 발행을 시작하거나 메일링 리스트의 하이라이트를 관리하기 +* [PyPA의 기여처럼](https://github.com/pypa/python-packaging-user-guide/issues/194), 프로젝트 튜토리얼 작성하기 +* 프로젝트 문서 번역 작성하기 -### 조직하는 것을 좋아합니까? +### 조직하는 것을 좋아하세요? * 중복된 이슈에 대한 링크 및 새로운 이슈 라벨 제안, 정리된 상태 유지하기 -* [@nzakas가 ESLint에 했던것처럼](https://github.com/eslint/eslint/issues/6765), 열려있는 이슈를 검토하고, 오래된 이슈를 닫을 것을 제안하기 -* 최근 열린 이슈에 대한 질문을 명확히 하여 토론으로 나아가게하기 +* [ESLint의 @nzakas](https://github.com/eslint/eslint/issues/6765)처럼, 열려있는 이슈를 검토하고 오래된 이슈를 닫을 것을 제안하기 +* 최근 열린 이슈에 대한 질문을 명확히 하여 토론으로 나아가게 하기 -### 코드 작성하고 싶습니까? +### 코드를 작성하고 싶으세요? -* [@dianjin이 Leaflet 했던것처럼](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560), 해결할 문제를 찾기 +* [Leaflet의 @dianjin처럼](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560), 해결할 문제를 찾기 * 새로운 기능을 작성하는 데 도움을 줄 수 있는지 물어보기 * 프로젝트 설정 자동화하기 * 툴링 및 테스트 개선하기 -### 사람들을 돕는 것을 좋아합니까? +### 사람들을 돕는 것을 좋아하세요? -* 예를 들어, Stack Overflow의 ([Postgres 예시](http://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) 혹은 Reddit과 관련된 질문에 대답해주기 -* 열린 이슈에서 사람들의 질문에 대답해주기 -* 토론 보드나 대화 채널의 관리 돕기 +* Stack Overflow([Postgres 예시](http://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) 혹은 Reddit에서 프로젝트에 관련된 질문에 답변하기 +* 열린 이슈에서 사람들의 질문에 답변하기 +* 토론 게시판이나 대화 채널 관리 돕기 -### 다른 사람들의 코드를 돕는 것을 좋아합니까? +### 사람들의 코드 작성을 돕고 싶으세요? -* 다른 사람들의 제출한 코드를 리뷰하기 -* 프로젝트를 어떻게 쓰는가에 대한 튜토리얼 작성하기 -* [@ereichert처럼 Rust에서 @bronzdoc을 사용하고](https://github.com/rust-lang/book/issues/123#issuecomment-238049666), 다른 기여자를 멘토로 초대하기 +* 사람들이 제출한 코드 리뷰하기 +* 프로젝트를 어떻게 이용하는가에 대한 튜토리얼 작성하기 +* [Rust의 @ereichert가 @bronzdoc에게 해준 것처럼](https://github.com/rust-lang/book/issues/123#issuecomment-238049666), 다른 기여자의 멘토가 되는 것을 제안하기 -### 소프트웨어 프로젝트만으로 작업할 필요는 없습니다! +### 꼭 소프트웨어 프로젝트에서 작업할 필요는 없습니다! -"오픈소스"는 종종 소프트웨어를 의미하지만, 무엇이든간에 거의 협력 할 수 있습니다. 오픈소스 프로젝트로 개발되는 책, 요리법, 목록 및 수업이 있습니다. +"오픈소스"는 보통 소프트웨어를 의미하지만, 무엇이든 간에 거의 협력할 수 있습니다. 오픈소스 프로젝트로 개발되는 책, 요리법, 리스트 및 수업도 있습니다. -예시로 아래와 같습니다: +예를 들면: * @sindresorhus는 [list of "awesome" lists](https://github.com/sindresorhus/awesome)를 만들었습니다 * @h5bp는 프론트엔드 개발자 후보군용 [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions)을 관리하고 있습니다 * @stuartlynn과 @nicole-a-tesla는 [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts)를 만들었습니다 -비록 당신이 소프트웨어 개발자일지라도, 문서 프로젝트 작업은 오픈소스에서 시작하는 데 도움이 될 수 있습니다. 코드를 포함하지 않는 프로젝트에서 작업하는 것이 종종 위협적이지 않으며, 협업 프로세스가 자신감과 경험을 쌓을 수 있습니다. +비록 당신이 소프트웨어 개발자일지라도, 문서 프로젝트 작업은 오픈소스에서 시작하는 데 도움이 될 수 있습니다. 코드를 포함하지 않는 프로젝트에서 작업하는 것은 보통 어렵지 않으며, 협력하는 과정에서 여러분의 자신감과 경험을 쌓을 수 있을 것입니다. ## Orienting yourself to a new project @@ -155,219 +148,220 @@ related:
If you go to an issue tracker and things seem confusing, it's not just you. These tools require a lot of implicit knowledge, but people can help you navigate it and you can ask them questions.
-— @shaunagm, ["어떻게 오픈소스에 기여하는가"](http://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/) +— @shaunagm, ["How to Contribute to Open Source”](https://readwrite.com/2014/10/10/open-source-diversity-how-to-contribute/)
-오타를 수정하는 이상의 것, 오픈소스에 기여하는 것은 파티에서 낯선 사람들에게 다가가는 것과 같습니다. 라마에 대해 이야기하기 시작하면, 금붕어에 관한 토론이 깊어지면서 아마 당신을 조금 이상하게 보게 될 것입니다. +오타를 수정하는 것 이상으로 오픈소스에 기여하는 것은 파티에서 낯선 사람들에게 다가가는 것과 같습니다. 사람들이 금붕어에 대한 깊은 토론에 빠져 있을 때 라마에 대해 이야기한다면 그들은 아마 여러분을 약간 이상하게 볼 겁니다. -자신의 제안으로 맹목적으로 뛰어 들기 전에, 먼저 방을 읽는 법을 배우십시오. 그렇게하면 아이디어가 눈에 띄고 들리게 될 확률이 높아집니다. +맹목적으로 여러분의 제안을 펼치기 전에, 방의 분위기를 읽는 법을 배우는 것부터 시작하세요. 그러면 여러분의 아이디어에 귀 기울여 줄 가능성이 높아집니다. ### 오픈소스 프로젝트의 해부학 -모든 오픈소스 커뮤니티는 다릅니다. +모든 오픈소스 커뮤니티는 서로 다릅니다. -하나의 오픈소스 프로젝트에 수년을 보내다 보면 하나의 오픈소스 프로젝트를 알게되었다는 것을 의미합니다. 다른 프로젝트로 이동하면 어휘, 규범 및 의사 소통 스타일이 완전히 다른 것을 알 수 있습니다. +여러 해 동안 한 오픈소스 프로젝트에 투자했다면 그 프로젝트를 잘 알게 됐을 것입니다. 다른 프로젝트로 넘어가면 어휘, 표준, 커뮤니케이션 스타일이 완전히 다르다는 것을 알 수 있습니다. -즉, 많은 오픈소스 프로젝트는 비슷한 조직 구조를 따릅니다. 서로 다른 커뮤니티 역할과 전반적인 프로세스를 이해하면 새로운 프로젝트를 신속하게 수행할 수 있습니다. +많은 오픈소스 프로젝트는 비슷한 조직 구조를 따릅니다. 다양한 커뮤니티 역할과 전반적인 프로세스를 이해하면 새로운 프로젝트에 빠르게 적응할 수 있습니다. -일반적인 오픈소스 프로젝트에는 다음 유형의 사람들이 있습니다: +일반적인 오픈소스 프로젝트에서 사람들은 다음과 같은 유형으로 나뉩니다. * **작성자:** 이 프로젝트를 만든 사람 혹은 조직 * **소유자:** 조직 또는 저장소에 대한 관리 권한을 가진 사람 (항상 원래 작성자와 동일하지는 않음) -* **메인테이너:** 비전을 주도하고 프로젝트의 조직 측면을 관리하는 책임이 있는 기여자. (그들은 프로젝트의 저자 또는 소유자일 수도 있습니다.) -* **기여자:** 프로젝트에 다시 기여한 모든 사람. -* **커뮤니티 맴버:** 프로젝트를 사용하는 사람들. 대화에서 적극적이거나 프로젝트 방향에 대한 의견을 표명할 수 있습니다. +* **메인테이너:** 비전을 주도하고 프로젝트의 조직 측면을 관리하는 책임이 있는 기여자 (그들은 프로젝트의 저자 또는 소유자일 수도 있습니다.) +* **기여자:** 프로젝트에 기여한 모든 사람. +* **커뮤니티 맴버:** 프로젝트를 사용하는 사람들. 적극적으로 대화에 참여하거나 프로젝트 방향에 대한 의견을 제시할 수도 있습니다. -더 큰 프로젝트에는 툴링, 선별, 커뮤니티 중재 및 이벤트 조직과 같은 다양한 업무에 초점을 둔 소위원회 또는 실무 그룹이 있을 수도 있습니다. 프로젝트 웹 사이트에서 "팀" 페이지를 찾거나 거버넌스 문서 저장소에 이 정보를 찾으십시오. +더 큰 프로젝트에는 툴링, 선별, 커뮤니티 중재 및 이벤트 조직과 같은 다양한 업무에 초점을 둔 소위원회 또는 실무 그룹이 있을 수도 있습니다. 프로젝트 웹 사이트에서 "팀" 페이지를 찾거나 거버넌스 문서 저장소에서 정보를 찾아보세요. 프로젝트에도 문서가 있습니다. 이러한 파일은 대개 저장소의 최상위 레벨에 나열됩니다. -* **라이선스:** 정의에 의하면, 모든 오픈소스 프로젝트는 반드시 [오픈소스 라이선스를 가져야 합니다](https://choosealicense.com). 만약 프로젝트가 라이선스를 가지지 않는다면, 이건 오픈소스가 아닙니다. -* **README:** README는 새로운 커뮤니티 구성원을 프로젝트에 환영하게 하는 지침서입니다. 왜 프로젝트가 유용하고 시작하는 방법을 설명합니다. -* **CONTRIBUTING:** README는 사람들이 프로젝트를 사용하는 데 도움이되지만, CONTRIBUTING 문서는 사람들이 프로젝트에 _기여_하는 데 도움이됩니다. 필요한 기여 유형과 프로세스 작동 방식을 설명합니다. 모든 프로젝트가 CONTRIBUTING 파일을 갖고있는 것은 아니지만, 공존하는 환영 프로젝트임을 알립니다. -* **CODE_OF_CONDUCT:** code of conduct는 참가자의 행동에 대한 기본 원칙을 설정하고, 친절하고 환영할만한 환경을 조성하는 데 도움이 됩니다. 모든 프로젝트가 CODE_OF_CONDUCT 파일을 가지고있는 것은 아니지만, 그 존재가 기여할 수 있는 환영 프로젝트임을 알립니다. +* **LICENSE:** 정의에 의해, 모든 오픈소스 프로젝트는 반드시 [오픈소스 라이선스를 가져야 합니다](https://choosealicense.com). 만약 프로젝트가 라이선스를 가지지 않는다면, 이건 오픈소스가 아닙니다. +* **README:** README는 새로운 커뮤니티 구성원을 프로젝트에 환영하는 지침서입니다. 왜 프로젝트가 유용한지, 어떻게 시작해야 할지 설명합니다. +* **CONTRIBUTING:** README는 사람들이 프로젝트를 사용하는 데 도움이되지만, CONTRIBUTING 문서는 사람들이 프로젝트에 _기여_하는 데 도움이 됩니다. 필요한 기여 유형과 프로세스 작동 방식을 설명합니다. 모든 프로젝트가 CONTRIBUTING 파일을 갖고 있는 것은 아니지만, 이 파일이 있다면 여러분의 기여를 환영한다는 뜻입니다. +* **CODE_OF_CONDUCT:** Code of Conduct(윤리 강령)는 참가자의 행동에 대한 기본 원칙을 정하고, 친절하고 따뜻한 환경을 조성하는 데 도움이 됩니다. 마찬가지로 모든 프로젝트가 CODE_OF_CONDUCT 파일을 가지고 있지는 않지만, 이 파일이 있다면 여러분의 기여를 환영한다는 뜻입니다. * **다른 문서:** (특히 큰 프로젝트의 경우) 튜토리얼, 연습장 또는 거버넌스 정책과 같은 추가 문서가 있을 수 있습니다. 마지막으로 오픈소스 프로젝트는 다음 도구를 사용하여 토론을 구성합니다. 기록 보관소를 읽으면 커뮤니티가 어떻게 사고하고 작동하는지 잘 알 수 있습니다. -* **Issue tracker:** 사람들이 프로젝트와 관련된 이슈를 토론하는 공간입니다. -* **Pull requests:** 사람들이 토론하고 진행중인 변경 사항을 검토합니다. -* **토론 포럼 혹은 메일링 리스트:** 일부 프로젝트는 회화 주제(ex. _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests)에 대해 이러한 채널을 사용할 수 있습니다. 다른 사람들은 모든 대화에 이슈 트래커를 사용합니다. -* **동기식 채널 채팅:** 일부 프로젝트에서는 일상 회화, 공동 작업 및 빠른 교환을 위해 채팅 채널 (예 : 슬랙 또는 IRC)을 사용합니다. +* **Issue tracker:** 프로젝트와 관련된 이슈를 토론하는 공간입니다. +* **Pull requests:** 지금 진행 중인 변경 사항에 대해 논의하고 검토하는 공간입니다. +* **토론 포럼 혹은 메일링 리스트:** 일부 프로젝트는 회화성 주제(버그 제보나 기능 요구 대신 _"...하려면 어떻게 하나요?"_ 또는 _"...에 대해 어떻게 생각하세요?"_ 같은 주제)에 대해 이러한 채널을 사용할 수 있습니다. 나머지 프로젝트는 모든 대화에 이슈 트래커를 사용합니다. +* **채팅 채널:** 일부 프로젝트에서는 일상 대화, 협업 및 빠른 의사소통을 위해 Slack이나 IRC 같은 채팅 채널을 사용합니다. ## Finding a project to contribute to -이제 오픈소스 프로젝트가 어떻게 작동하는지 알게 되었으니, 이제는 기여할 프로젝트를 찾아야 할 때입니다! +오픈소스 프로젝트가 어떻게 작동하는지 알았으니, 이제 기여할 프로젝트를 찾아야 합니다! -이전에 오픈소스에 기여한 적이 없다면, John F. Kennedy 미국 대통령의 _"Ask not what your country can do for you - ask what you can do for your country."_ 발언에서 조언을 구하십시오. +이전에 오픈소스에 기여한 적이 없다면, 케네디 미국 전 대통령으로부터 조언을 구하세요. _"Ask not what your country can do for you - ask what you can do for your country."_ -오픈소스에 기여하는 것은 프로젝트 전반에 걸쳐 모든 수준에서 발생합니다. 첫 번째 기여가 정확히 무엇인지 또는 어떻게 보일지를 생각할 필요가 없습니다. +오픈소스에 기여하는 것은 프로젝트 전반에 걸쳐 모든 수준에서 발생합니다. 여러분의 첫 번째 기여가 정확히 무엇이고 어떻게 보일지 생각할 필요가 없습니다. -대신, 이미 사용하고 있거나 사용하고 싶은 프로젝트에 대해 생각해보십시오. 적극적으로 기여할 프로젝트는 자신이 다시 찾아 오는 프로젝트입니다. +대신, 이미 사용하고 있거나 사용하고 싶은 프로젝트에 대해 생각하는 것으로 시작하세요. 여러분이 적극적으로 기여하게 될 프로젝트는 여러분이 계속 사용하게 되는 프로젝트입니다. -그 프로젝트 내에서, 뭔가가 더 좋거나 다를 수 있다고 생각할 때마다 본능에 따라 행동하십시오. +그 프로젝트에서, 뭔가가 더 좋거나 다를 수 있다고 생각할 때마다 본능에 따라 행동하세요. -오픈소스는 독점적인 클럽이 아닙니다; 그것은 당신 같은 사람들에 의해 만들어졌습니다. "오픈소스"는 전세계 문제를 유연하게 해결할 수 있는 멋진 용어입니다. +오픈소스는 독점적인 클럽이 아닙니다. 여러분과 같은 사람들에 의해 만들어졌습니다. "오픈소스"는 전세계의 문제들을 유연하게 해결할 수 있는 멋진 용어입니다. -README를 스캔하여 깨진 링크 또는 오타를 찾을 수 있습니다. 또는 새로운 사용자이고 무언가가 고장 났거나, 실제로 문서에 있어야한다고 생각되는 문제를 발견했습니다. 그것을 무시하고 계속 나아가거나, 다른 사람에게 그것을 고치라고 요구하는 대신, 피칭을 통해 도움을 줄 수 있는지 확인하십시오. 오픈소스가 무엇인지 알아보십시오! +README를 스캔하여 깨진 링크나 오타를 찾을 수 있습니다. 또는 여러분이 새로운 사용자로서 제대로 동작하지 않거나 문서에서 다뤄져야 할 이슈를 발견할 수도 있습니다. 그것을 무시하거나 다른 사람에게 그것을 고쳐달라고 하는 대신, 여러분이 직접 도움을 줄 수 있는지 알아보세요. 그것이 바로 오픈소스입니다! -> [일반적인 기여의 28%](http://www.igor.pro.br/publica/papers/saner2016.pdf)는 오타 수정, 서식 재 지정 또는 번역 작성과 같은 문서입니다. +> [일반적인 기여의 28%](http://www.igor.pro.br/publica/papers/saner2016.pdf)는 오타 수정, 서식 재지정 또는 번역 작성과 같은 문서입니다. -또한 다음 리소스 중 하나를 사용하여 새 프로젝트를 찾고 기여할 수 있습니다. +다음 리소스 중 하나를 사용하여 새 프로젝트를 찾고 기여할 수 있습니다. * [GitHub Explore](https://github.com/explore/) * [Open Source Friday](https://opensourcefriday.com) -* [First Timers Only](http://www.firsttimersonly.com/) -* [Your First PR](https://yourfirstpr.github.io/) +* [First Timers Only](https://www.firsttimersonly.com/) * [CodeTriage](https://www.codetriage.com/) * [24 Pull Requests](https://24pullrequests.com/) -* [Up For Grabs](http://up-for-grabs.net/) +* [Up For Grabs](https://up-for-grabs.net/) * [Contributor-ninja](https://contributor.ninja) +* [First Contributions](https://firstcontributions.github.io) +* [SourceSort](https://www.sourcesort.com/) -### A checklist before you contribute +### 기여하기 전 확인할 사항 -기여하고 싶은 프로젝트를 찾았으면, 프로젝트가 기여를 받기에 적합한 지 빠르게 확인하십시오. 그렇지 않으면, 노력이 절대로 응답을 받지 못할 수도 있습니다. +기여하고 싶은 프로젝트를 찾았으면, 프로젝트가 기여를 받기에 적합한지 빠르게 확인하세요. 그렇지 않으면, 노력이 영원히 응답을 받지 못할 수도 있습니다. -다음은 프로젝트가 새로운 기여자에게 좋은가에 대한 여부를 평가하는 편리한 체크리스트입니다. +다음은 프로젝트가 새로운 기여자에게 적합한지 평가할 수 있는 편리한 체크리스트입니다. -**오픈소스의 정의를 충족시킵니다** +**오픈소스의 정의를 충족시킬 것**
Whenever you see a long thread, spot check responses from core developers coming late in the thread. Are they summarizing constructively, and taking steps to bring the thread to a decision while remaining polite? If you see a lot of flame wars going on, that's often a sign that energy is going into argument instead of into development.
-— @kfogel, [_OSS 생산_](http://producingoss.com/en/evaluating-oss-projects.html) +— @kfogel, [_Producing OSS_](http://producingoss.com/en/evaluating-oss-projects.html)
## How to submit a contribution -원하는 프로젝트를 찾았으면 기꺼이 기여할 준비가되었습니다. 마침내! 올바른 방법으로 기여를 받는 방법은 다음과 같습니다. +기여하고 싶은 프로젝트를 찾았나요? 드디어! 기여하는 올바른 방법은 다음과 같습니다. -### 효과적으로 의사 소통하기 +### 효과적으로 의사소통하기 -일회 기여자이든 커뮤니티에 참여하려고하든, 관계없이 다른 사람들과 협력하는 것은 오픈소스에서 개발할 가장 중요한 기술 중 하나입니다. +하나의 기여를 하든 커뮤니티에 참여하려고 하든, 관계없이 다른 사람들과 협력하는 것은 오픈소스에서 개발할 가장 중요한 기술 중 하나입니다. -이슈를 열거나 pull request를 하기 전에, 또는 채팅에서 질문을 하기 전에, 아이디어를 효과적으로 전달할 수 있도록 이러한 점을 명심하십시오. +이슈나 PR을 열거나 채팅에서 질문을 하기 전에 아이디어를 효과적으로 전달할 수 있도록 아래와 같은 사항을 명심하세요. -**context 제공하기.** 다른 사람들이 신속하게 속도를 낼 수 있도록 도와주십시오. 오류가 발생하는 경우, 수행하려는 작업과 오류를 재현하는 방법을 설명하십시오. 새로운 아이디어를 제안하는 경우, 프로젝트에 유용하다고 생각하는 이유를 설명하십시오 (귀하뿐 아니라!). +**맥락을 제공하세요.** 다른 사람들이 빨리 속도를 낼 수 있도록 도와주세요. 오류가 발생하면 수행하려는 작업과 오류를 재현하는 방법을 설명하세요. 새로운 아이디어를 제안하는 경우 그것이 (여러분이 아닌) 프로젝트에 유용하다고 생각하는 이유를 설명하세요. -> 😇 _"제가 Y를 하려면 X가 안됩니다"_ +> 😇 _"Y를 할 때 X가 안 돼요."_ > -> 😢 _"X 가 망가졌네요! 이거 고쳐주세요."_ +> 😢 _"X가 안 돼요! 이거 고쳐주세요."_ -**미리 과제하기.** 무언가 알지는 못하지만 시도한 것을 보여주십시오. 도움을 요청하기 전에 프로젝트의 README, 문서, 이슈 (공개 또는 비공개), 메일링 리스트를 확인하고 인터넷에서 답변을 검색하십시오. 사람들은 당신이 배우려고한다는 것을 증명할 때 감사해할 것입니다. +**과제를 미리 하세요.** 이해하지는 못하지만 시도해봤다는 것을 보여주세요. 도움을 요청하기 전에 프로젝트의 README, 문서, (열린 혹은 닫힌) 이슈, 메일링 리스트를 확인하고 인터넷에서 해결책을 검색해보세요. 당신이 배우려는 자세를 보이면 사람들은 존중할 것입니다. -> 😇 _"X를 구현하는 방법을 잘 모르겠네요. 도움말 문서를 확인했고 모든 멘션도 찾지 못했습니다."_ +> 😇 _"X를 구현하는 방법을 잘 모르겠어요. 도움말 문서를 확인했지만 관련 언급을 찾지 못했어요."_ > > 😢 _"X는 어떻게 해요?"_ -**요청을 짧고 직접적으로 유지하기.** 이메일을 보내는 것과 마찬가지로 모든 기여는 아무리 간단하거나 도움이된다 하더라도, 다른 사람의 검토가 필요합니다. 많은 프로젝트는 도움을 줄 수있는 사람들보다 많은 요청을 받고 있습니다. 간결하게 하십시오. 누군가가 당신을 도울 수있는 기회를 증가시킬 것입니다. +**짧고 직접적으로 요청하세요.** 이메일을 보내는 것과 마찬가지로, 모든 기여는 아무리 간단하거나 도움이 된다 하더라도 다른 사람의 검토가 필요합니다. 많은 프로젝트가 사람들이 도울 수 있는 것보다 많은 요청을 받고 있습니다. 간결하게 적으세요. 누군가 당신을 도울 가능성이 늘어날 것입니다. -> 😇 _"API 튜토리얼을 작성하고 싶습니다."_ +> 😇 _"API 튜토리얼을 작성하고 싶어요."_ > -> 😢 _"저는 다른 날 고속도로를 몰고 가스로 달려 들었어요. 그리고 나서 저는 우리가 해야 할 일에 대해 이 놀라운 생각을 가지고 있었고요. 그렇지만 제가 설명하기 전에, 님께 보여주기 위해서..."_ +> 😢 _"요전날 고속도로를 따라 차를 몰고 가다가 주유소에 들렀는데, 우리가 해야 할 일에 대한 놀라운 아이디어가 떠올랐어요. 하지만 설명해드리기 전에 보셔야 할 게 있는데요…"_ -**모든 커뮤니케이션을 공개하기.** 유혹스러운 일이긴하지만, 중요한 정보(예 : 보안 문제 또는 심각한 행동 위반)를 공유해야하는 경우가 아니면 메인테이너에게 개인적으로 연락하지 마십시오. 대화를 공개 할 때 더 많은 사람들이 귀하의 교류를 통해 배우고 이익을 얻을 수 있습니다. 토론은 그 자체로 기여할 수 있습니다. +**모든 의사소통을 공개하세요.** 매혹적이긴 하지만 보안 문제나 심각한 규칙 위반 같은 중요한 정보를 공유해야 하는 경우가 아니면 관리자에게 개인적으로 연락하지 마세요. 대화를 공개해야 더 많은 사람들이 여러분의 교류를 통해 배우고 이익을 얻을 수 있습니다. 토론은 그 자체로 기여가 됩니다. -> 😇 _(댓글로) "@-메인테이너 안녕하세요! 이 PR은 어떻게 진행되고 있나요?"_ +> 😇 _(댓글로) "@-관리자 안녕하세요! 이 PR은 어떻게 진행되고 있나요?"_ > -> 😢 _(이메일로) "안녕하세요, 이메일을 보내서 죄송합니다만.제 PR을 검토할 기회가 있었는지 궁금합니다."_ +> 😢 _(이메일로) "안녕하세요, 메일로 귀찮게 해서 죄송합니다만 제 PR을 검토해보셨는가 해서요."_ -**질문을 하는 것은 괜찮습니다(그러나 참을성 있으십시오!).** 누구나 프로젝트를 처음 접했을뿐 아니라 경험 많은 공헌자도 새로운 프로젝트를 볼 때 속도를 높여야 합니다. 마찬가지로, 오랜 기간의 메인테이너가 프로젝트의 모든 부분을 항상 잘 알고있는 것은 아닙니다. 그들에게 당신이 보여주기를 바라는 것과 같은 인내심을 보여주십시오. +**질문하는 것은 좋지만 참을성을 가지세요.** 누구나 프로젝트를 처음 접했을 때가 있으며 경험 많은 기여자도 새로운 프로젝트에는 가속이 필요합니다. 마찬가지로 오랜 관리자도 프로젝트의 모든 부분을 항상 잘 알고 있는 것은 아닙니다. 여러분이 기대하는 만큼의 인내심을 사람들에게 보여주세요. -> 😇 _"이 오류 찾아주셔서 고맙습니다. 저는 이 제안에 따를게요. 이렇게 출력되네요."_ +> 😇 _"이 오류를 알아봐 주셔서 감사합니다. 제안을 따라 고쳐 봤어요. 이렇게 출력되네요."_ > -> 😢 _"왜 내 문제를 해결할 수 없어요? 이 프로젝트는 님이 만든게 아닌가요?"_ +> 😢 _"왜 이 문제를 해결할 수 없는 거죠? 이 프로젝트는 관리자님이 만든 게 아닌가요?"_ -**커뮤니티의 의사 결정을 존중하기.** 귀하의 아이디어는 커뮤니티의 우선 순위 또는 비전과 다를 수 있습니다. 그들은 의견을 제시하거나 아이디어를 추구하지 않기로 결정할 수 있습니다. 토론하고 타협을 찾아야하지만, 메인테이너는 당신보다 더 오래 결정을 내리지 않고 살아야합니다. 당신이 그들의 방향에 동의하지 않으면, 당신은 항상 자신의 포크에서 일하거나 자신의 프로젝트를 시작할 수 있습니다. +**커뮤니티의 결정을 존중하세요.** 여러분의 아이디어는 커뮤니티의 우선순위나 비전과 다를 수 있습니다. 그들은 개선점을 제시하거나 여러분의 아이디어를 도입하지 않기로 결정할 수 있습니다. 절충안을 논의하는 동안 관리자는 여러분보다 오래 여러분의 결정을 고려해야 합니다. 여러분이 커뮤니티의 비전에 동의하지 않는다면 여러분의 포크에서 작업하거나 따로 프로젝트를 시작하는 방법도 있습니다. -> 😇 _"제 use case를 지원할 수 없다는 점에 실망했지만, 사용자의 작은 부분에만 영향을 주었다고 설명하셨으니 이해됩니다. 들어주셔서 감사합니다."_ +> 😇 _"제 유즈케이스를 지원할 수 없다는 점은 아쉽지만 일부 사용자에게만 영향을 미친다는 관리자님의 설명은 이해가 되네요. 들어주셔서 감사합니다."_ > -> 😢 _"왜 use case를 지원하지 않나요? 납득할 수 없네요!"_ +> 😢 _"왜 제 유즈케이스를 지원하지 않나요? 납득할 수가 없네요!"_ -**무엇보다도 고급스러움을 유지하기.** 오픈소스는 전 세계의 공동 작업자로 구성됩니다. 컨텍스트는 언어, 문화, 지역 및 시간대에 걸쳐 손실됩니다. 또한 서면 의사 소통을 통해 분위기 나 분위기를 전달하기가 더 어려워집니다. 이 대화에서 좋은 의도를 가정하십시오. 정중하게 생각을 뒤로 밀거나, 더 많은 맥락을 묻거나, 더 자세하게 설명하는 것은 좋습니다. 인터넷을 찾은 때보다 더 나은 곳을 떠나보십시오. +**무엇보다도 세련된 자세를 유지하세요.** 오픈소스는 전 세계의 협력자로 구성되어 있습니다. 맥락은 언어, 문화, 지역, 시간대에 걸쳐 점점 손실됩니다. 게다가 글을 통한 의사소통은 말투나 분위기를 전달하기가 어렵습니다. 대화에 좋은 의도를 가지고 참여한다고 생각하세요. 예의를 갖추면 아이디어를 밀어붙여도, 더 자세한 설명을 요구해도, 여러분의 입장을 명확히 해도 좋습니다. 다만 인터넷 세계를 여러분의 첫인상보다 좋은 곳으로 만들어 주세요. -### 컨텍스트 수집 +### 정보 수집 -어떤 일을 하기 전에, 빠른 시일내에 당신의 아이디어가 다른 곳에서 논의되지 않았는지 확인하십시오. 프로젝트의 README, 이슈(공개 및 폐쇄), 메일링 리스트 및 스택 오버플로우를 생략하십시오. 모든 것을 처리하는 데 몇 시간을 허비하지 않아도 되지만, 핵심 용어에 대한 빠른 검색은 먼 길을 가집니다. +무언가 시작하기 전에, 여러분의 아이디어가 다른 곳에서 논의되지 않았는지 빠르게 확인해 보세요. 프로젝트의 README, 이슈, 메일링 리스트 및 스택 오버플로우를 훑어보세요. 모든 것을 찾아보는 데 몇 시간을 투자할 필요는 없지만, 몇 가지 핵심 용어에 대한 검색이면 충분할 것입니다. -다른 곳에서 아이디어를 찾을 수 없다면, 움직일 준비가 된 것입니다. 프로젝트가 GitHub에 있다면, 이슈를 열거나 pull request을 열어 소통할 수 있습니다: +다른 곳에서 여러분의 아이디어를 찾을 수 없다면, 움직일 때가 되었습니다. 프로젝트가 GitHub에 있는 경우 다음과 같이 이슈나 PR을 열어 소통할 수 있습니다. -* **이슈**는 대화나 토론을 시작하는 것과 같습니다 -* **Pull requests** 는 솔루션에서 일을 시작하기 위한 것입니다 -* 명확한 질문이나 How-To 질문과 같은 **간단한 커뮤니케이션의 경우,** 프로젝트에 하나의 채팅 채널이있으면 스택 오버플로우, IRC, 슬랙 또는 다른 채팅 채널을 요청합니다 +* **이슈**는 대화나 토론을 시작하는 것과 같습니다. +* **풀 리퀘스트**는 솔루션에 대한 작업을 시작하기 위한 것입니다. +* 명확한 질문이나 방법 질문과 같은 **간단한 커뮤니케이션**은 스택 오버플로우 또는 IRC, 슬랙 같은 프로젝트 채팅 채널에 물어보세요. -이슈를 열거나 pull request을 요청하기 전에, 프로젝트의 기여 문서(일반적으로 CONTRIBUTING 또는 README 파일)를 확인하여 구체적인 내용을 포함해야하는지 확인하십시오. 예를 들어, 템플릿을 따르거나 테스트를 사용하도록 요청할 수 있습니다. +이슈나 PR을 열기 전에 프로젝트의 기여 문서(일반적으로 CONTRIBUTING 또는 README 파일)에서 뭔가 구체적인 내용을 포함해야 하는지 확인하세요. 프로젝트에서 여러분에게 특정 템플릿을 따르거나 테스트를 사용하도록 요구할 수 있습니다. -실질적인 기여를 하고 싶다면, 이슈를 열고 작업하십시오. 수락되지 않을 수 있는 일을 하기 전에(깃허브에서는, ["Watch"를 클릭](https://help.github.com/articles/watching-repositories/)하여 토론을 알림 받을 수 있습니다), 잠시동안 프로젝트를 보고 커뮤니티 멤버를 알게되면 도움이됩니다. +실질적인 기여를 하고 싶다면, 작업하기 전에 이슈를 열고 물어보세요. 승인되지 않을 수도 있는 작업을 하기 전에(깃허브에서는, ["Watch"를 클릭](https://help.github.com/articles/watching-repositories/)해서 토론을 알림 받을 수 있습니다), 커뮤니티 구성원들을 알게 되면 도움이 됩니다. ### 이슈 열기 -일반적으로 다음과 같은 상황에서 이슈를 열어야합니다: +일반적으로 다음 상황에서 이슈를 열어야 합니다. -* 스스로 해결할 수 없는 오류를 보고 -* 높은 수준의 주제 또는 아이디어 (예시. 커뮤니티, 비전, 정책) 토론 +* 스스로 해결할 수 없는 오류 보고 +* 커뮤니티, 비전, 정책 등 높은 수준의 주제 또는 아이디어 토론 * 새로운 기능이나 다른 프로젝트 아이디어 제안 -이슈에서 의사소통을 위한 팁: +이슈에서 소통할 때의 팁은 다음과 같습니다. -* **해결하려는 이슈가 공개적으로 보이면,** 사람들이 당신이 그것에 대해 알 수 있도록 이슈에 대해 의견을 말하십시오. 그렇게하면 사람들은 중복으로 작업할 가능성이 줄어 듭니다. -* **이슈가 조금 전에 열렸다면,** 다른 곳에서 해결되었거나, 이미 해결되었기 때문에 작업을 시작하기 전에 확인을 요청하십시오. -* **이슈를 열었지만 나중에 대답을 알아 낸 경우,** 사람들에게 알리고 이슈를 해결할 수 있도록 이슈에 대한 의견을 말하십시오. 그 결과를 문서화하는 것조차도 프로젝트에 대한 기여입니다. +* **열린 이슈에 대해 작업하려고 한다면** 사람들이 알 수 있게 댓글을 달아두세요. 그렇게 하면 다른 사람과 같은 부분을 작업할 가능성이 줄어듭니다. +* **이슈가 오래 전부터 열려 있었다면** 내용이 다른 곳에서 논의되고 있거나 이미 해결됐을 수도 있으므로 작업을 시작하기 전에 확인을 요청하세요. +* **이슈를 열었지만 나중에 해결법을 알아냈다면** 이슈에 댓글을 달아 사람들에게 알리고 이슈를 닫으세요. 그 결과에 대한 문서화도 프로젝트에의 기여가 됩니다. -### pull request 열기 +### PR 열기 -일반적으로 다음 상황에서 pull request를 열어야합니다: +일반적으로 다음 상황에서 PR을 열어야 합니다. -* 사소한 수정 사항 제출 (예 : 오타, 깨진 링크 또는 분명한 오류) -* 이미 이슈를 열었거나 이미 논의한 내용을 기여로 시작하기 +* 오타, 깨진 링크, 명백한 오류 등 사소한 수정 사항 제출 +* 요구되고 있거나 이슈에서 논의한 내용에 대한 작업 시작 -pull request은 완료된 작업을 나타내지 않아도됩니다. 일반적으로 초기에 pull request을 열면 다른 사람이 진행 상황을 보거나 피드백을 줄 수 있습니다. 제목 줄에 "WIP"(진행중인 작업)이라고 표시하십시오. 나중에 커밋을 더 추가 할 수 있습니다. +PR이 반드시 완료된 작업을 포함할 필요는 없습니다. 보통 다른 사람들이 여러분의 진행 상황을 확인하거나 피드백을 줄 수 있도록 PR을 일찍 여는 것이 좋습니다. 제목 줄에 "WIP"(Work In Progress; 진행 중인 작업)라고 표시하세요. 나중에 얼마든지 커밋을 더 추가해도 됩니다. -프로젝트가 GitHub에 있는 경우, pull request을 제출하는 방법은 다음과 같습니다: +프로젝트가 GitHub에 있는 경우 PR을 제출하는 방법은 다음과 같습니다. -* **[저장소를 포크하고](https://guides.github.com/activities/forking/)** 로컬에 클론합니다. 리모트로 추가하여 로컬을 원래의 "업스트림"저장소에 연결하십시오. "업스트림"의 변경 사항을 자주 가져 와서 최신 상태로 유지하면 pull request을 제출할 때, 병합 충돌이 덜 발생할 수 있습니다. ([이 곳](https://help.github.com/articles/syncing-a-fork/)에서 더 자세한 지침보기.) -* 수정을 위한 **[브랜치 생성하기](https://guides.github.com/introduction/flow/)**. -* **모든 관련있는 이슈** 혹은 PR에서 지원중인 문서 참조하기 (ex. "#37 닫음.") -* **전후의 스크린 샷 포함합니다** 변경 사항에 HTML/CSS의 차이가 포함되어있는 경우, pull request의 본문에 이미지를 끌어다 놓습니다. -* **변경점을 테스트합니다!** 기존 테스트가 있는 경우 변경 사항을 실행하고 필요한 경우 새 테스트를 작성하십시오. 테스트의 존재 여부와 상관없이 변경 사항이 기존 프로젝트를 손상시키지 않는지 확인하십시오. -* 당신의 능력을 최대한 발휘하여 **프로젝트 스타일에 기여하십시오.** 이는 들여 쓰기, 세미콜론 또는 주석을 자신의 저장소에서와 다르게 사용하는 것을 의미 할 수 있지만, 메인테이너가 병합하기 쉽고, 다른 사람들이 나중에 이해하고 유지할 수 있게 해줍니다. +* **[저장소를 포크](https://guides.github.com/activities/forking/)**하고 로컬에 복제(Clone)합니다. 리모트로 추가하여 로컬을 원래의 "업스트림" 저장소에 연결하세요. PR을 제출할 때 충돌이 발생할 가능성을 낮추기 위해 "업스트림"의 변경 사항을 자주 가져 와서 최신 상태로 유지하세요. (자세한 내용은 [여기](https://help.github.com/articles/syncing-a-fork/)를 참조하세요.) +* 수정을 위한 **[브랜치를 생성](https://guides.github.com/introduction/flow/)**하세요. +* **모든 관련 이슈** 혹은 지원 문서를 참조하세요. (ex. "Closes #37.") +* 변경 사항에 HTML/CSS가 포함되어 있는 경우 **적용 전/후 스크린샷을 첨부**하세요. PR의 본문에 이미지를 끌어다 놓으면 됩니다. +* **변경 사항을 테스트**하세요! 변경 사항에 대해 이미 있는 테스트를 수행하고 필요한 경우 새 테스트를 작성하세요. 테스트의 존재 여부와 상관없이 변경 사항이 기존 프로젝트를 손상시키지 않는지 확인하세요. +* 최선을 다해 **프로젝트 스타일에 기여**하세요. 들여쓰기, 세미콜론 또는 주석을 여러분의 평소 스타일과 다르게 사용해야 할 수도 있지만, 관리자가 PR을 병합하기 더 용이하고 향후의 유지보수가 쉬워질 것입니다. -만약 이것이 첫 pull request 라면, @kentcdodds가 무료 walkthrough 리소스로 생성한 [Make a Pull Request](http://makeapullrequest.com/)를 확인하십시오. +만약 첫 PR을 열려고 한다면 @kentcdodds가 무료 영상 튜토리얼로 공개한 [Make a Pull Request](http://makeapullrequest.com/)를 참조하세요. @Roshanjossey의 [First Contributions](https://github.com/Roshanjossey/first-contributions) 저장소에서 연습해볼 수도 있습니다. ## What happens after you submit a contribution -훌륭합니다! 오픈소스 기여자가 되신 것을 축하드립니다. 우리는 그것이 많은 사람들 중 첫번째가 되기를 바랍니다. +해내셨군요! 오픈소스 기여자가 되신 것을 축하드립니다. 앞으로도 많이 기여하실 수 있기를 바랍니다. -기여를 제출하면 다음 중 하나가 발생합니다. +기여를 제출하면 다음 중 하나의 일이 일어날 것입니다. -### 😭 당신은 응답을 얻지 못합니다. +### 😭 답변을 받지 못했어요. -기여를 하기 전에, [활동의 징조가 있는지 프로젝트를 확인](#a-checklist-before-you-contribute)했기를 바랍니다. 그러나 활발한 프로젝트에서도 기여가 응답을 받지 못할 수도 있습니다. +기여하기 전에 [활동의 징조가 있는지 프로젝트를 확인](#기여하기-전-확인할-사항)했기를 바랍니다. 그러나 활발한 프로젝트에서도 기여가 반응을 얻지 못할 수도 있습니다. -1주일 이내에 응답을 받지 못했다면, 같은 쓰레드에서 정중하게 응답하여 누군가에게 검토를 요청하는 것이 좋습니다. 기여자를 검토할 수있는 적절한 사람의 이름을 아는 경우, 해당 스레드에서 이름을 @로 표기할 수 있습니다. +일주일 넘게 답변을 받지 못했다면 누군가에게 검토를 부탁하며 공손하게 대응하는 것이 좋습니다. 여러분의 기여를 검토할 수 있는 적절한 사람의 이름을 안다면 골뱅이표(@)를 이용한 멘션으로 리뷰를 요청할 수 있습니다. -**절대** 그 사람에게 개인적으로 연락하지 마세요; 공개적인 의사소통은 오픈소스 프로젝트에서 필수적이라는 것을 기억하십시오. +**절대** 그 사람에게 개인적으로 연락하지 마세요. 공개적인 의사소통은 오픈소스 프로젝트에서 필수적이라는 것을 기억하세요. -정중한 충돌을 하고도 아직 아무도 응답하지 않으면, 아무도 응답하지 않을 가능성이 있습니다. 그것은 큰 감정이 아니지만, 그것이 당신을 낙담하게 하지마십시오. 모두에게 일어난 일입니다! 귀하가 통제 할 수 없는 개인적 상황을 포함하여 응답을 받지 못한 이유는 여러 가지가 있을 수 있습니다. 다른 프로젝트나 기여 방법을 찾으십시오. 다른 커뮤니티 구성원들이 참여하고 반응하기 전에 기여에 많은 시간을 투자하지 않는 것이 좋은 이유입니다. +여러분이 예의 있게 행동했음에도 아무도 답변을 주지 않을 수도 있습니다. 기분이 좋지는 않겠지만 너무 낙담하지 마세요. 누구나 겪는 일입니다! 답변을 받지 못하는 데에는 어쩔 수 없는 개인적인 사정 등 다양한 이유가 있을 수 있습니다. 기여할 다른 방법이나 프로젝트를 찾아보세요. 다른 커뮤니티 구성원들이 참여하고 반응하기 전에 기여에 너무 많은 시간을 투자하지 않는 게 오히려 좋습니다. -### 🚧 누군가 기여를 변경 요청해야합니다. +### 🚧 기여에 대한 수정을 요청받았어요. -아이디어의 범위에 대한 피드백이든 코드의 변경 사항이든, 기여 내용을 변경하라는 메시지가 표시되는 것이 일반적입니다. +아이디어에 대한 피드백이든 코드의 수정이든 기여 내용을 수정해 달라는 요청을 받는 경우가 많습니다. -누군가 변경 사항을 요청하면, 반응적입니다. 그들은 당신의 기여를 검토할 시간을 가졌습니다. PR을 열고 멀리두는 것은 나쁜 형태입니다. 만약 변경 방법을 모르는 경우, 문제를 조사한 다음 필요한 경우 도움을 요청하십시오. +누군가 수정을 요청하면 적극적으로 그에 응답하세요. 그들은 여러분의 기여를 리뷰하기 위해 기꺼이 시간을 들였습니다. PR을 열고 내버려 두는 것은 좋지 않습니다. 어떻게 수정해야 할지 모르겠다면 문제에 대해 조사하고 필요한 경우 도움을 요청하세요. -만약 더 이상 문제를 해결할 시간이 없다면 (예를 들어, 대화가 몇 달 동안 계속되고 상황이 변경된 경우), 메인테이너에게 알려서 응답을 기대하지 않도록 하십시오. 다른 사람이 기꺼이 받아 들일 수 있습니다. +대화가 몇 달 동안 진행되다가 상황이 변한 경우처럼, 더 이상 문제를 해결할 시간이 없다면 관리자에게 알리세요. 누군가 다른 사람이 기꺼이 작업을 맡아줄 지도 모릅니다. -### 👎 귀하의 기여가 받아지지 않았습니다. +### 👎 기여가 받아들여지지 않았어요. -귀하의 기여는 결국 받아지거나 수락되지 않을 수도 있습니다. 다행히도 이미 너무 많은 작업을 하지 않았으면 합니다. 왜 그것이 받아들여지지 않았는지 확신할 수 없다면, 메인테이너 담당자에게 피드백과 설명을 요청하는 것이 합리적입니다. 그러나 궁극적으로 이것이 자신의 결정임을 존중해야합니다. 논쟁하거나 적대적인 태도를 취하지 마십시오. 동의하지 않으면, 항상 자신의 버전을 포크하고 작업할 수 있습니다! +여러분의 기여는 받아들여질 수도 있고 그렇지 않을 수도 있습니다. 이미 너무 많은 작업을 하지 않았으면 합니다. 왜 그것이 받아들여지지 않았는지 잘 모르겠다면 관리자에게 피드백과 설명을 요청하는 것이 합리적입니다. 그러나 궁극적으로는 이것이 그들의 결정이라는 것을 존중할 필요가 있습니다. 논쟁하거나 적대적인 태도를 취하지 마세요. 동의하지 않으면 언제든 여러분의 버전을 포크하고 따로 작업할 수 있습니다! -### 🎉 귀하의 기여가 받아졌습니다. +### 🎉 기여가 받아들여졌어요. -만세! 성공적으로 오픈소스 기여를 만들었습니다! +만세! 오픈소스에 기여하는 데 성공했습니다! ## You did it! -처음으로 오픈소스에 기여한 사람이든, 새로운 방식으로 기여할 사람을 찾고 있든, 우리는 이 행동에 영감을 얻으시기 바랍니다. 기여가 승인되지 않더라도, 관리자가 당신을 돕기 위해 노력할 때 감사하다는 말을 잊지 마십시오. 오픈소스는 당신과 같은 사람들이 만듭니다: one issue, pull request, comment, or high-five at a time. +처음으로 오픈소스에 기여한 사람이든, 기여할 새로운 방법을 찾고 있든, 이 문서가 그것을 행동에 옮길 수 있는 계기가 되었길 바랍니다. 비록 기여가 받아들여지지 않더라도, 관리자가 당신을 도우려 할 때 감사의 말을 하는 것을 잊지 마세요. 오픈소스의 이슈, PR, 댓글 하나하나는 여러분에 의해 만들어집니다. diff --git a/ko.html b/_articles/ko/index.html similarity index 39% rename from ko.html rename to _articles/ko/index.html index 760284dcdf528c8672168310d0f55debf18d86e9..a3cbad5909aa05b748e6d43def1f039b458cfa7e 100644 --- a/ko.html +++ b/_articles/ko/index.html @@ -1,4 +1,6 @@ --- layout: index +title: 오픈 소스 가이드 lang: ko +permalink: /ko/ --- diff --git a/_articles/ko/leadership-and-governance.md b/_articles/ko/leadership-and-governance.md index 6420010863d380d7f1958996a80536fbb9af85f3..e2c107b53dfda1e4f5a1e87dd72162837d7cbcdd 100644 --- a/_articles/ko/leadership-and-governance.md +++ b/_articles/ko/leadership-and-governance.md @@ -1,16 +1,8 @@ --- lang: ko -title: 리더십과 정치 -description: 오픈소스 프로젝트가 성장하면서 공식적인 의사 결정 규칙의 혜택을 볼 수 있습니다. +title: 리더십과 관리 +description: 결정을 위한 공식적인 규칙을 정하면 오픈소스 프로젝트의 성장에 이익을 얻을 수 있습니다. class: leadership -toc: - what-are-examples-of-formal-roles-used-in-open-source-projects: "오픈소스 프로젝트에서 사용되는 공식 역할의 예시로는 무엇입니까?" - how-do-i-formalize-these-leadership-roles: "이러한 리더십 역할을 어떻게 공식화할 수 있습니까?" - when-should-i-give-someone-commit-access: "누군가에게 언제 커밋 권한을 부여해야합니까?" - what-are-some-of-the-common-governance-structures-for-open-source-projects: "오픈소스 프로젝트의 공통적인 관리 구조에는 어떤 것들이 있습니까?" - do-i-need-governance-docs-when-i-launch-my-project: "프로젝트를 시작할 때 거버넌스 문서가 필요합니까?" - what-happens-if-corporate-employees-start-submitting-contributions: "기업 직원이 기여를 제출하기 시작하면 어떻게됩니까?" - do-i-need-a-legal-entity-to-support-my-project: "내 프로젝트를 지원하기 위해 법인이 필요합니까?" order: 6 image: /assets/images/cards/leadership.png related: @@ -18,148 +10,147 @@ related: - metrics --- -## Understanding governance for your growing project +## 성장하는 프로젝트 관리 이해하기 -프로젝트가 성장하고 있고, 사람들이 종사하고 있으며, 당신은 이 일을 계속 지키려고합니다. 이 단계에서 누군가가 프로젝트에 커밋하거나 커뮤니티 토론을 해결할 때, 정기적인 프로젝트 참여자를 워크플로우에 통합하는 방법에 대해 궁금해 할 수 있습니다. 질문이 있으시면 답변을 드리겠습니다. +프로젝트는 성장하고, 사람들은 바쁘게 활동하고, 여러분은 계속 이끌어 나가고 싶습니다. 이 단계에서 여러분은 어떻게 일의 흐름에 기여자들을 모을지 알고자 합니다. 누군가에게 커밋 권한을 주거나 커뮤니티 토론을 해결하는 식으로 말입니다. 질문이 있다면 대답해드리겠습니다. -## What are examples of formal roles used in open source projects? +## 오픈소스 프로젝트에서 공식적인 역할은 어떤 식으로 적용되나요? -많은 프로젝트가 기여자 역할과 인식을 위해 유사한 구조를 따릅니다. +대부분 프로젝트는 비슷한 기여자 역할 구조를 갖습니다. -이 역할들이 실제로 의미하는 바는 전적으로 당신에게 달렸습니다. 다음과 같은 몇 가지 유형의 역할을 인식 할 수 있습니다: +역할이 실제로 의미하는 것이 무엇인지는 전적으로 여러분에게 달렸습니다. 여러분이 이미 아실 만한 역할은 다음과 같습니다. -* **메인테이너** -* **기여자** -* **커미터** +* **관리자(Maintainer)** +* **기여자(Contributor)** +* **커미터(Committer)** -**약간의 예시로, "메인테이너"**는 커밋 권한이있는 프로젝트의 유일한 사람입니다. 다른 프로젝트에서는 단순히 README에 메인테이너로 올라온 사람들입니다. +**몇몇 프로젝트에서 "관리자"**는 커밋 권한을 가진 사람들만을 의미하지만, 어떤 프로젝트에서는 단순히 README 파일에 관리자로서 나열되어 있는 사람들을 가리킵니다. -메인테이너는 반드시 프로젝트에 코드를 작성하는 사람일 필요는 없습니다. 그것은 프로젝트를 전파하는 많은 일을 한 사람일 수도 있고, 프로젝트를 다른 사람들이 더 쉽게 이용할 수 있도록 작성한 문서일 수도 있습니다. 메인테이너가 매일 수행하는 업무와 관계없이 메인테이너는 프로젝트 방향에 대한 책임감을 느끼고, 이를 개선하기 위해 최선을 다하는 사람입니다. +관리자가 반드시 코드를 작성하는 사람일 필요는 없습니다. 프로젝트를 홍보하는 데 큰 몫을 한 사람일 수도 있고, 프로젝트 접근성을 높이기 위해 문서화를 맡은 사람일 수도 있습니다. 그들이 무슨 일을 하든, 관리자는 보통 프로젝트의 방향에 책임감을 가지고 이를 개선하고자 노력하는 사람일 것입니다. -**모든 사람이 될 수 있는 "기여자"**는 이슈 혹은 pull request에 대한 의견을 말하거나, 프로젝트에 가치를 부여하는 사람 (이슈를 다루거나, 코드 작성 혹은 이벤트 구성), 또는 병합된 pull request을 소유한 사람(아마도 기여자의 가장 좁은 정의)이 될 수 있습니다. +**"기여자"**는 이슈나 풀 리퀘스트에 댓글을 작성하는 모든 사람이라고 볼 수 있습니다. 이슈에 우선 순위를 매기는 사람, 코드를 작성하는 사람, 행사를 조율하는 사람에서부터 (가장 좁은 의미로는) 병합된 풀 리퀘스트를 가진 사람까지 모두가 기여자인 셈입니다. -**"커미터"**라는 용어는 특정 유형의 책임인 커밋 액세스를 다른 형태의 기여와 구별하는 데 사용될 수 있습니다. +**"커미터"**라는 용어는 다른 기여 유형에 대비해 커밋이라는 특정 권한과 책임을 가진 사람을 구분하고자 사용합니다. -원하는 방식으로 프로젝트 역할을 정의할 수 있지만, [보다 폭 넓은 정의를 사용하여](../how-to-contribute/#what-it-means-to-contribute) 더 많은 기여 양식을 권장하십시오. 리더십 역할을 사용하여 기술 능력에 관계없이 프로젝트에 뛰어난 기여를 한 사람을 공식적으로 인정할 수 있습니다. +프로젝트 역할은 여러분이 원하는 대로 정의할 수 있지만, 다양한 유형의 기여를 이끌어내기 위해 되도록 [넓은 정의를 사용하세요](../how-to-contribute/#what-it-means-to-contribute). 전문적인 기술 수준과 별개로 프로젝트에 대단한 기여를 한 사람들에게 리더십 역할을 부여하며 그들에게 답례를 표할 수 있습니다. -## How do I formalize these leadership roles? +## 어떻게 리더십 역할을 구성해야 할까요? -리더십 역할을 공식화하면 사람들이 소유권을 느끼게되고 도움이 필요한 다른 커뮤니티 회원에게도 도움이 됩니다. +리더십 역할을 잘 갖추고 형식화하면 사람들이 소유감을 느끼고, 다른 커뮤니티 구성원들에게 도움을 줄 수 있습니다. -소규모 프로젝트의 경우, 리더 지정은 README 또는 CONTRIBUTORS 텍스트 파일에 이름을 추가하는 것처럼 간단할 수 있습니다. +작은 프로젝트에서는 README 파일이나 CONTRIBUTORS 파일에 이름을 추가하는 것 정도로 간단하게 리더를 지정할 수 있습니다. -대규모 프로젝트의 경우,만약 웹사이트를 가지고있다면, 팀 페이지를 만들거나 거기에 프로젝트 리더를 나열하십시오. 예시로, [Postgres](https://github.com/postgres/postgres/)는 각각 기여자를 위한 짧은 프로필을 [포괄적인 팀 페이지](https://www.postgresql.org/community/contributors/)에 넣었습니다. +큰 프로젝트에서는, 웹사이트가 있다면 팀 페이지를 만들거나 프로젝트 리더들을 사이트에 나열하세요. [Postgres](https://github.com/postgres/postgres/)는 각 기여자의 짧은 프로필을 담은 [팀 페이지](https://www.postgresql.org/community/contributors/)를 가지고 있습니다. -만약 프로젝트에 매우 활발하게 기여한 커뮤니티가 있는 경우, 메인테이너 또는 다른 이슈 영역(예시. 보안, 이슈 security, 시위, 커뮤니티 행동)의 소유권을 가진 사람들의 소위원회로 "핵심 팀"을 구성 할 수 있습니다. 사람들이 자신을 할당하는 것이 아니라, 가장 흥분되는 역할에 대해 스스로 조직하고 자원 봉사하게 하십시오. +매우 활성화된 기여자 커뮤니티를 가진 프로젝트라면 관리자들이나 각 분야(보안, 이슈 분류, 커뮤니티 관리 등)의 기여자들로 "핵심 팀"을 구성하는 방법이 있습니다. 사람들에게 역할을 부여하기보다 사람들이 스스로 역할을 구성하고 자원할 수 있게 하세요. -리더십 팀은 IRC와 같이 지정된 채널을 만들거나 프로젝트를 토론하기 위해 정기적으로 (Gitter 또는 Google 행 아웃과 같은)모임을 갖기를 원할 수 있습니다. 다른 사람들이 들을 수 있도록 그 모임을 공개할 수도 있습니다. -예시로, [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby)는, [매주 근무 시간에 가졌습니다](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs). +리더 팀은 IRC 등 지정된 채널을 만들거나 Gitter나 Google Hangout 등에서 정기적으로 프로젝트 토론 시간을 가지는 것이 좋습니다. 다른 사람들도 참관할 수 있게 채널이나 토론을 공개해도 됩니다. 예컨대 [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby)는 [매주 토론 시간을 갖습니다](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs). -리더십 역할을 확립한 후에는 사람들이 어떻게 달성할 수 있는지 문서화하는 것을 잊지 마십시오! 누군가가 어떻게 메인테이너나 프로젝트의 소위원회에 참여할 수 있는지에 대한 명확한 프로세스를 수립하고 GOVERNANCE.md에 기록합시다. +리더십 역할을 구성한 후에는 사람들이 어떻게 그 역할을 부여받을 수 있는지 문서화하는 것을 잊지 마세요! 관리자나 특정 분야 전문 기여자가 되는 방법을 명확하게 정하고 GOVERNANCE 파일에 기록하세요. -[Vossibility](https://github.com/icecrime/vossibility-stack)와 같은 도구는 프로젝트에 기여한 사람(또는 참여하지 않은 사람)을 공개적으로 추적하는 데 도움이 될 수 있습니다. 이 정보를 문서화하면, 메인테이너가 사적인 결정을 내리는 그들만의 커뮤니티라는 인식을 피할 수 있습니다. +누가 프로젝트에 기여하고 누가 그렇지 않은지 공개적으로 파악하는 데 [Vossibility](https://github.com/icecrime/vossibility-stack) 같은 툴이 도움을 줍니다. 이런 정보를 문서화하면 관리자들이 불공평한 결정을 내린다는 인식을 피할 수 있습니다. -마지막으로, 프로젝트가 GitHub에 있을 경우, 프로젝트를 개인 계정에서 조직으로 옮기고 적어도 하나의 백업 관리자를 추가하는 것을 고려하십시오. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/)에서는 권한 및 여러 저장소를 쉽게 관리하고 [공유 소유권](../building-community/#share-ownership-of-your-project)을 통해 프로젝트의 유산을 보호합니다. +마지막으로, 여러분의 프로젝트가 GitHub에서 진행되고 있다면 프로젝트를 여러분의 개인 계정에서 조직 계정으로 이동하는 것을 고려해 보세요. [조직 계정](https://help.github.com/articles/creating-a-new-organization-account/) 기능이 여러 저장소의 권한 관리, [공동 소유](../building-community/#프로젝트를-공동으로-소유하세요)를 통한 프로젝트 정책 보호를 쉽게 만들어 줍니다. -## When should I give someone commit access? +## 커밋 권한은 언제 부여해야 하나요? -어떤 사람들은 당신이 기여하는 모든 사람에게 헌신적으로 접근해야한다고 생각합니다. 그렇게하면 더 많은 사람들이 프로젝트 소유권을 느낄 수 있습니다. +몇몇 사람들은 여러분이 모든 기여자에게 커밋 권한을 줘야 한다고 생각합니다. 그렇게 한다면 더 많은 사람들이 프로젝트 소유감을 느끼게 할 수 있을 것입니다. -반면에, 특히 더 크고 복잡한 프로젝트의 경우, 자신의 의지를 입증한 사람들에게만 커밋 액세스 권한을 부여할 수 있습니다. 그렇게하는 데 올바른 방법이 없습니다 - 당신을 가장 편안하게 만드는 것은 무엇입니까! +반면, 특히 크고 복잡한 프로젝트에서는 노력을 보인 사람들에게만 커밋 권한을 부여할 수도 있습니다. 정해진 방법은 없습니다. 가장 편한 방법을 선택하세요! -만약 GitHub에 프로젝트가 있다면, [protected branches](https://help.github.com/articles/about-protected-branches/)를 사용하여 특정 브랜치로 푸시 할 수있는 사람과 상황을 관리할 수 있습니다. +여러분의 프로젝트가 GitHub에서 진행되고 있다면 [보호 브랜치](https://help.github.com/articles/about-protected-branches/) 기능을 사용해 누가 어떠한 상황에 특정 브랜치에 푸시할 수 있는지 지정할 수 있습니다. -## What are some of the common governance structures for open source projects? +## 오픈소스의 관리 구조로는 어떤 것이 있나요? -오픈소스 프로젝트와 관련된 세 가지 공통 관리 구조가 있습니다. +오픈소스 프로젝트에서 적용되는 세 가지 일반적인 관리 구조가 있습니다. -* **BDFL:** BDFL은 "생명을 위한 자비로운 독재자"(Benevolent Dictator for Life)의 약자입니다. 이 구조하에서 한 사람(보통 프로젝트의 초기 저자)은 모든 주요 프로젝트 결정에 대해 최종 결정권을 갖습니다. [파이썬](https://github.com/python)은 고전적인 예시입니다. 작은 프로젝트는 한명 또는 두명의 관리자가 있기 때문에 기본적으로 BDFL일 것입니다. 한 회사에서 시작된 프로젝트도 BDFL 범주에 속할 수도 있습니다. +* **BDFL:** BDFL은 "자비로운 종신독재자"(Benevolent Dictator for Life)의 약자입니다. 이 구조 아래에서는 (주로 프로젝트 창시자) 한 사람이 주요 사안의 최종 결정권을 갖습니다. [Python](https://github.com/python)이 그 대표적인 예입니다. 작은 프로젝트는 한두 명의 관리자만이 존재하므로 BDFL이라 할 수 있습니다. 기업에 의해 시작된 프로젝트도 보통 BDFL의 범주에 들어갑니다. -* **실력주의:** **(Note: "능력주의"라는 용어는 일부 지역 사회에 부정적인 의미를 지니며 [복잡한 사회 정치적 역사](http://geekfeminism.wikia.com/wiki/Meritocracy)를 가지고있습니다.)** 능력있는 사회에서 활동적인 프로젝트 기여가 ("공로"를 입증하는 사람들)에게 공식적인 의사 결정 역할이 부여됩니다. 결정은 일반적으로 순수한 투표 컨센서스를 기반으로합니다. 실력주의 개념은 [Apache Foundation](http://www.apache.org/)에 의해 개척되었습니다; [모든 아파치 프로젝트](http://www.apache.org/index.html#projects-list)는 장점이 있습니다. 기여는 회사가 아니라 집단을 대표하는 개인이 할 수 있습니다. +* **능력주의(Meritocracy):** **(참고: "능력주의"라는 용어는 일부 커뮤니티에서는 부정적 의미를 내포하며, [복잡한 사회·정치적 역사](http://geekfeminism.wikia.com/wiki/Meritocracy)를 가지고 있습니다.)** 능력주의 구조 아래에서는 ("능력"을 보이는) 활동적인 프로젝트 기여자들이 공식 결정권을 갖습니다. 사안 결정은 주로 투표를 통한 합의로 이루어집니다. 능력주의라는 개념은 [Apache Foundation](https://www.apache.org/)에 의해 만들어졌습니다. [모든 Apache 프로젝트](https://www.apache.org/index.html#projects-list)가 능력주의 구조입니다. 기여는 반드시 기업이 아닌 각각의 개인에 의해 이루어집니다. -* **자유주의 기여:** 자유주의 기여 모델하에서, 가장 많은 일을 하는 사람들이 가장 영향력있는 사람으로 인식되지만, 이것은 역사적인 기여가 아니라 현재의 일을 기반으로합니다. 주요 프로젝트 결정은 순수한 표결보다는 합의를 모색하는 과정(주요 불만 사항을 논의)을 토대로 이루어지며, 가능한 많은 공동체 관점을 포함하기 위해 노력합니다. 프로젝트의 인기있는 예제는 [Node.js](https://nodejs.org/en/foundation/)와 [Rust](https://www.rust-lang.org/en-US/)에 포함된 자유주의 기여 모델을 사용합니다. +* **자유주의 기여(Liberal contribution):** 자유주의 기여 구조에서는 가장 많은 일을 하는 사람이 가장 영향력 있는 사람으로 받아들여집니다. 하지만 이는 과거의 기여가 아닌 현재 작업 내용에 따라 판단합니다. 주요 사안은 투표보다는 (불만 사항에 대해 토론하는) 합의 도출 과정을 기반으로 하며, 가능한 많은 관점을 포함하려 합니다. 자유주의 기여 구조의 유명한 프로젝트로는 [Node.js](https://foundation.nodejs.org/)와 [Rust](https://www.rust-lang.org/)가 있습니다. -어느 것을 사용해야합니까? 그것은 당신에게 달렸습니다! 모든 모델에는 장점과 절충점이 있습니다. 처음에는 전혀 다른 것처럼 보일 수 있지만, 세 모델 모두 공통적으로 보입니다. 이 모델 중 하나를 채택하는 데 관심이 있다면 다음 템플릿을 확인하십시오: +어느 구조를 채택해야 할까요? 그건 여러분의 손에 달려 있습니다! 모든 구조는 각각의 장단점을 가지고 있습니다. 그리고 얼핏 보기에는 제법 달라 보여도 세 구조 모두 실제로는 보기보다 비슷합니다. 위 구조들 중 하나를 도입하고자 한다면 아래 템플릿을 참조하세요. -* [BDFL 모델 템플릿](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) -* [실력주의 모델 템플릿](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) -* [Node.js의 자유주의 기여 정책](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951#.m9ht26e79) +* [BDFL 구조 템플릿](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) +* [능력주의 구조 템플릿](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) +* [Node.js의 자유주의 기여 정책](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) -## Do I need governance docs when I launch my project? +## 프로젝트를 출시하려면 관리 문서가 있어야 하나요? -프로젝트 관리 방식을 작성할 적절한 시기는 없지만, 커뮤니티 역학 관계가 성립했다면 정의하는 것이 훨씬 쉽습니다. 오픈소스 관리에 대한 가장 좋은(그리고 가장 어려운) 부분은 그것이 커뮤니티에 의해 형성된다는 것입니다! +프로젝트 관리 문서를 작성하는 데에 정해진 시기는 없습니다. 하지만 커뮤니티의 역학이 작용하는 모습을 직접 보고 나서 작성하면 더 쉽습니다. 오픈소스 관리의 가장 좋은 (그리고 어려운) 점은 그것이 커뮤니티에 의해 형성된다는 점입니다! -일부 초기 문서는 필연적으로 프로젝트 관리에 기여할 것이므로, 가능하다면 글을 써내려가는 것을 시작하십시오. 예를 들어, 프로젝트 시작시에도 동작에 대한 명확한 기대치 또는 기여 프로세스가 어떻게 작동하는지 정의할 수 있습니다. +하지만 이른 문서화는 프로젝트 관리에 필연적으로 도움이 됩니다. 그러니 적을 수 있는 것부터 적으며 시작하세요. 프로젝트 출시 단계에서도 어떤 기여를 기대하는지 명시하거나 기여 과정이 어떻게 되는지 등을 정의할 수 있습니다. -오픈소스 프로젝트를 시작한 회사의 일원이라면, 회사가 앞으로 나아갈 프로젝트에 대한 결정을 유지하고 결정할 방법에 대해 공개하기 전에 내부 토론을 가질 필요가 있습니다. 귀사가 프로젝트에 참여하는 방법에 대해 공개적으로 설명하고 싶을 수도 있습니다. +여러분이 오픈소스 프로젝트를 출시하는 기업의 일원이라면, 출시 전에 앞으로 어떻게 프로젝트를 유지하고 사안을 결정할지에 대한 내부 토론 시간을 가지세요. 또한 기업이 프로젝트에 어떤 식으로 관여할지 (또는 관여하지 않을지!) 공개적으로 설명하는 것이 좋습니다. -## What happens if corporate employees start submitting contributions? +## 기업 직원들이 기여하기 시작하면 어떤 일이 일어나나요? -성공적인 오픈소스 프로젝트는 많은 사람들과 회사에서 사용되며, 결국 일부 회사는 궁극적으로 프로젝트에 묶인 수익원을 갖게 될 것입니다. 예를 들어, 회사는 상용 서비스에서 프로젝트 코드를 하나의 구성 요소로 사용할 수 있습니다. +성공적인 오픈소스 프로젝트는 많은 사람과 기업에서 사용됩니다. 그러다 보면 어떤 기업의 수익 흐름이 프로젝트와 엮이기도 합니다. 예컨대, 기업이 상업적 서비스 제공을 위한 한 요소로서 프로젝트 코드를 사용하는 경우가 있습니다. -프로젝트가 널리 사용됨에 따라 전문 지식을 보유한 사람들은 더 많은 수요가 생깁니다. - 때로는 프로젝트에서 수행하는 일에 대해 보수를 받습니다. +프로젝트가 널리 쓰이면 해당 프로젝트에 전문적인 사람들(여러분일 수도 있습니다!)의 수요도 증가합니다. 때로는 프로젝트에서 맡는 작업에 대한 보수를 받기도 합니다. -상업 활동을 평범하고 또 다른 개발 에너지 원으로 간주하는 것이 중요합니다. 유료 개발자는 물론 지불하지 않은 애플리케이션에 대해서는 특별한 대우를 받아서는 안됩니다. 각 기부금은 기술적 장점으로 평가되어야합니다. 그러나 사람들은 상업 활동에 익숙해져야하며, 특정 향상이나 기능을 선호할 때 자신의 use cases에 대해 쉽게 알 수 있어야합니다. +영리 활동을 다른 개발 원동력과 같이 평범하게 여기는 것이 중요합니다. 보수를 받는 개발자들은 그렇지 않은 개발자들에 비해 특별한 대우를 받아서는 안 됩니다. 물론 그들이 만드는 기여는 기술적인 가치에 따라 평가받아야 하겠지만 말입니다. 사람들은 영리 활동에 대해 이야기하거나, 특정 기능 개선이 필요하다고 주장하며 용례를 다루는 데 불편이 없어야 합니다. -"상용"은 "오픈소스"와 완전히 호환됩니다. "상업적"이란 말은 어딘가에 돈이 들어 있다는 의미입니다. 소프트웨어가 상용으로 사용되고 있다는 것이고, 프로젝트가 채택되면서 점점 더 많이 이용 될 가능성이 높습니다. 오픈소스 소프트웨어가 비 오픈소스 제품의 일부로 사용될 때, 전체 제품은 여전히 "독점"소프트웨어이지만, 오픈소스와 마찬가지로 상업적 또는 비상업적 용도로 사용될 수 있습니다. +"영리" 또는 "상용"이라는 단어는 "오픈소스"와 완벽히 어울리는 단어입니다. "영리"는 그저 어딘가에 돈이 연관되어 있다는 뜻입니다. 소프트웨어가 시장에서 사용되면 자연스럽게 프로젝트 채용률도 오릅니다. (오픈소스 소프트웨어가 비공개 소프트웨어의 일부분에 사용된다면 전체 소프트웨어는 여전히 "독점" 소프트웨어입니다. 이는 오픈소스처럼 영리적 용도로든 비영리적 용도로든 사용될 수 있습니다.) -다른 사람들과 마찬가지로, 상업적 동기를 부여받은 개발자는 기여도의 질과 양을 통해 프로젝트에 영향력을 행사합니다. 분명히 일정한 시간동안 돈을 지불한 개발자는 돈을 지불하지 않은 사람보다 더 많은 것을 할 수 있지만, 괜찮습니다. 지불은 누군가가 얼마나 많은 영향을 줄 수 있는지에 대한 많은 요인 중 하나일뿐입니다. 사람들이 그 기여를 할 수 있게 해주는 외적 요인이 아닌, 기여에 초점을 맞춘 프로젝트 토론을 유지하십시오. +다른 누구나와 마찬가지로, 이윤을 얻는 개발자들은 기여의 양과 질을 통해 프로젝트에서 영향력을 얻습니다. 투자한 시간에 대한 보상을 받는 개발자가 그렇지 않은 이들보다 많은 일을 할 수 있는 것은 분명한 사실이지만, 괜찮습니다. 보수는 누군가의 역량에 영향을 미치는 여러 요인 중 하나일 뿐입니다. 사람들이 기여하게 만들기 위한 외적 요인이 아닌 기여 자체에 토론을 집중하세요. -## Do I need a legal entity to support my project? +## 제 프로젝트를 지원하려면 법인이 필요한가요? -돈을 처리할 필요가 없다면, 오픈소스 프로젝트를 지원하는 법인이 필요하지 않습니다. +금전을 다루는 게 아니라면 오픈소스 프로젝트를 지원하는 데 법인은 필요하지 않습니다. -예시로, 상업용 비즈니스를 만들고 싶다면 C Corp 또는 LLC(미국에 거주하는 경우)를 설정해야합니다. 오픈소스 프로젝트와 관련된 계약 업무를 수행하는 중이라면, 독점 주인으로 돈을 받거나 LLC (미국에있는 경우)를 설립할 수 있습니다. +예컨대 영리 사업을 하고 싶다면 (미국 기준) C Corp이나 LLC를 설립해야 할 것입니다. 오픈소스 프로젝트에 관한 계약만 받고 있는 것이라면 독점 대표로서 돈을 수령하거나, 역시 (미국 기준) LLC를 설립할 수 있습니다. -만약 오픈소스 프로젝트에 대한 기부를 받고 싶다면, (예를 들어 PayPal 또는 Stripe을 사용하여)기부 버튼을 설정할 수 있지만, 하지만 자격이 되는 비영리 단체(미국에 거주하는 경우 501c3)가 아닌 이상 돈은 세금 공제되지 않습니다. +오픈소스 프로젝트에 대한 기부를 받고 싶다면 PayPal이나 Stripe 등을 이용해 기부 버튼을 마련해둘 수 있습니다. 하지만 여러분이 비영리(미국 기준 501c3)를 증명하지 못한다면 세금 공제는 받지 못합니다. -많은 프로젝트가 비영리 단체를 설립하는 문제를 겪고 싶어하지 않으므로, 대신 비영리 재정 스폰서를 찾습니다. 재정 보증인은 귀하를 대신하여 기부금을 수령합니다. [Software Freedom Conservancy](https://sfconservancy.org/), [아파치 재단](http://www.apache.org/), [이클립스 재단](https://eclipse.org/org/foundation/), [리눅스 재단](https://www.linuxfoundation.org/projects) 그리고 [Open Collective](https://opencollective.com/opensource)는 오픈소스 프로젝트를 위한 회계 스폰서 역할을하는 조직의 예시입니다. +대부분 프로젝트는 비영리 단체를 설립하는 번거로운 절차를 따르고 싶어하지 않습니다. 대신 비영리 회계 스폰서를 찾는 방법을 택합니다. 회계 스폰서는 보통 기부금의 일정 비율을 대가로 여러분을 대신하여 기부금을 수령합니다. 오픈소스 프로젝트를 위한 회계 스폰서 역할을 하는 조직은 [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects), [Open Collective](https://opencollective.com/opensource) 등이 있습니다. -프로젝트가 특정 언어 또는 생태계와 밀접하게 관련되어 있다면, 함께 작업할 수 있는 관련 소프트웨어 기반이 있을겁니다. 예시로, [파이썬 소프트웨어 재단](https://www.python.org/psf/)은 파이썬 패키지 관리자인 [PyPI](https://pypi.python.org/pypi)를 돕고, [Node.js 재단](https://nodejs.org/en/foundation/)은 노드 기반 프레임워크인 [Express.js](http://expressjs.com/)를 돕습니다. +여러분의 프로젝트가 특정 언어 또는 생태계와 밀접하게 관련되어 있다면 협업할 수 있는 관련 소프트웨어 재단 또한 있을 것입니다. 예를 들어 [Python Software Foundation](https://www.python.org/psf/)은 Python 패키지 관리자인 [PyPI](https://pypi.org/) 프로젝트를 지원하고, [Node.js Foundation](https://foundation.nodejs.org/)은 Node 기반 프레임워크인 [Express.js](https://expressjs.com/) 프로젝트를 지원합니다. diff --git a/_articles/ko/legal.md b/_articles/ko/legal.md index 97b9f443878278ab27044ee5c34aa824d6ff3fe1..a29e73a35adf445427f346a862bd2cea34897c6c 100644 --- a/_articles/ko/legal.md +++ b/_articles/ko/legal.md @@ -3,14 +3,6 @@ lang: ko title: 오픈소스의 법적 측면 description: 오픈소스의 법적 측면과 당신이 하지 않은 몇가지 사항에 대해 궁금해하는 모든 것입니다. class: legal -toc: - why-do-people-care-so-much-about-the-legal-side-of-open-source: "왜 사람들은 오픈소스의 법적 측면에 많은 관심을 보이고 있습니까?" - are-public-github-projects-open-source: "공개 GitHub 프로젝트는 오픈소스입니까?" - just-give-me-the-tldr-on-what-i-need-to-protect-my-project: "내 프로젝트를 보호하기 위해 필요한 DR;TL 제공해주기" - which-open-source-license-is-appropriate-for-my-project: "내 프로젝트에 적합한 오픈소스 라이선스는 무엇입니까?" - what-if-i-want-to-change-the-license-of-my-project: "프로젝트 라이선스를 변경하려면 어떻게해야합니까?" - does-my-project-need-an-additional-contributor-agreement: "내 프로젝트에 추가 기여자 계약이 필요합니까?" - what-does-my-companys-legal-team-need-to-know: "우리 회사의 법률 팀은 무엇을 알아야합니까?" order: 10 image: /assets/images/cards/legal.png related: @@ -20,17 +12,17 @@ related: ## Understanding the legal implications of open source -세계와 창의적인 작업을 공유하는 것은 흥미롭고 보람있는 경험이 될 수 있습니다. 그것은 또한 당신이 모른다고 걱정해야한다는 것을 합법적이라는 걸로 의미 할 수 있습니다. 고맙게도 처음부터 다시 시작할 필요는 없습니다. 귀하의 법적 요구 사항이 있습니다. (이 내용을 파기전에, [면책조항](/notices/)을 읽으십시오.) +세계와 창의적인 작업을 공유하는 것은 흥미롭고 보람있는 경험이 될 수 있습니다. 그것은 또한 당신이 걱정해야 했지만 잘 몰랐던 여러 법적 문제를 의미할 수도 있습니다. 고맙게도 처음부터 다시 시작할 필요는 없습니다. 귀하의 법적 요구 사항이 있습니다. (이 내용을 파기전에, [면책조항](/notices/)을 읽으십시오.) ## Why do people care so much about the legal side of open source? -물어봤다는건 다행입니다! 창의적인 작업(작성, 그래픽 또는 코드)을 할 때, 그 저작물은 기본적으로 독점적인 저작권하에 있습니다. 즉, 법은 귀하의 저작물의 작성자로서 다른 사람들이 할 수 있는 것에 대해 귀하가 말하고있는 것으로 간주합니다. +물어봤다는건 다행입니다! 창의적인 작업(작성, 그래픽 또는 코드)을 할 때, 그 저작물은 기본적으로 독점적인 저작권하에 있습니다. 즉, 법은 귀하를 저작물의 작성자로서 다른 사람들이 할 수 있는 것에 대해 귀하가 말하고있는 것으로 간주합니다. -일반적으로, 이는 타인이 인계, 훼손 또는 소송의 위험이 없이 작업을 사용, 복사, 배포 또는 수정할 수 있음을 의미합니다. +일반적으로, 이는 타인이 인계, 훼손 또는 소송의 위험이 없이 작업을 사용, 복사, 배포 또는 수정할 수 없음을 의미합니다. 그러나 오픈소스는 다른 사람들이 작업을 사용, 수정 및 공유하기를 기대하기 때문에 드문 경우입니다. 그러나 법적 기본값은 독점적인 저작권이므로 명시적으로 이러한 사용 권한을 명시한 사용권이 필요합니다. -오픈소스 라이선스를 신청하지 않으면, 프로젝트에 기여한 모든 사람도 자신의 저작물의 독점적인 저작권자가 됩니다. 즉, 아무도 자신의 기여를 사용, 복사, 배포 또는 수정할 수 없으며 "아무도"에서는 귀하를 포함하지 않는다는 의미입니다. +오픈소스 라이선스를 적용하지 않으면, 프로젝트에 기여한 모든 사람도 자신의 저작물의 독점적인 저작권자가 됩니다. 즉, 아무도 자신의 기여를 사용, 복사, 배포 또는 수정할 수 없으며 "아무도"에서는 귀하를 포함하지 않는다는 의미입니다. 마지막으로, 프로젝트는 사용자가 알지 못하는 라이선스 요구 사항과의 종속성을 가질 수 있습니다. 프로젝트의 커뮤니티 또는 고용주의 정책에 따라 프로젝트에서 특정 오픈소스 라이선스를 사용해야 할 수도 있습니다. 아래에서 이러한 상황을 다룰 것입니다. @@ -40,9 +32,9 @@ related:  -**GitHub 프로젝트를 공개하는 것은 프로젝트 라이센싱과 동일하지 않습니다.** 공개 프로젝트는 [GitHub의 서비스 약관](https://help.github.com/articles/github-terms-of-service/#f-copyright-and-content-ownership)에 명시되어 있으며, 다른 사람들이 프로젝트를 포크화할 수는 있지만, 그렇지 않은 경우에는 권한이 없습니다. +**GitHub 프로젝트를 공개하는 것은 프로젝트 라이센싱과 동일하지 않습니다.** 공개 프로젝트는 [GitHub의 서비스 약관](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants)에 명시되어 있으며, 다른 사람들이 프로젝트를 보거나 포크할 수는 있지만, 다른 권한은 없습니다. -다른 사람들이 프로젝트를 사용, 복사, 수정 또는 다시 사용할 수 있게하려면, 오픈소스 라이선스를 포함해야합니다. 예를 들어, 권한을 부여하지 않는다는 조건에서는 공개적으로 GitHub 프로젝트의 일부를 코드에 명시적으로 사용할 수는 없습니다. +다른 사람들이 프로젝트를 사용, 복사, 수정 또는 다시 사용할 수 있게하려면, 오픈소스 라이선스를 포함해야합니다. 예를 들어, GitHub 프로젝트가 공개되어 있다 하더라도 명시적으로 권한을 부여하지 않는다면, 그 코드의 어느 부분도 사용할 수 없습니다. ## Just give me the TL;DR on what I need to protect my project. @@ -56,15 +48,15 @@ GitHub에서 새로운 프로젝트를 만들 때, [라이선스를 추가할
A standardized license serves as a proxy for those without legal training to know precisely what they can and can't do with the software. Unless absolutely required, avoid custom, modified, or non-standard terms, which will serve as a barrier to downstream use of the agency code.
-— @benbalter, ["정부 변호인이 오픈소스 소프트웨어 라이선스에 대해 알아야할 모든 것"](http://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/) +— @benbalter, ["정부 변호인이 오픈소스 소프트웨어 라이선스에 대해 알아야할 모든 것"](https://ben.balter.com/2014/10/08/open-source-licensing-for-government-attorneys/)
## Which open source license is appropriate for my project? -빈 슬레이트에서 시작한다면, [MIT 라이선스](https://choosealicense.com/licenses/mit/)를 잘못 읽는 것은 어렵습니다. 짧고 이해하기 쉽기 때문에 저작권 고지를 포함하여 라이선스 사본을 보관하는 한 누구나 아무 것도 할 수 없습니다. 필요한 경우 다른 라이선스로 프로젝트를 릴리스 할 수 있습니다. +빈 슬레이트에서 시작한다면, [MIT 라이선스](https://choosealicense.com/licenses/mit/)를 잘못 읽는 것은 어렵습니다. MIT 라이선스는 짧고 이해하기 쉬우며, 저작권 고지를 포함하여 라이선스 사본을 보관하는 한 누구나 모든 것을 할 수 있도록 허락합니다.필요한 경우 다른 라이선스로 프로젝트를 릴리스 할 수 있습니다. -그렇지 않으면 프로젝트에 적합한 오픈소스 라이선스를 선택하는 것이 목표에 달려 있습니다. +그렇지 않으면 프로젝트에 적합한 오픈소스 라이선스를 선택하는 것이 목적에 달려 있습니다. 프로젝트에 **의존성**이 있을 가능성이 큽니다. 예를 들어, Node.js 프로젝트를 오픈소스로 사용하는 경우 노드 패키지 관리자(npm)의 라이브러리를 사용할 수 있습니다. 의존하는 각 라이브러리에는 자체 오픈소스 라이선스가 있습니다. 각 라이선스가 "허용"(다운스트림 라이선스의 조건없이 공용 사용, 수정 및 공유할 수 있는 권한 부여)되어 있으면, 원하는 라이선스를 사용할 수 있습니다. 일반적인 허용 라이선스에는 MIT, Apache 2.0, ISC 및 BSD가 포함됩니다. @@ -72,7 +64,7 @@ GitHub에서 새로운 프로젝트를 만들 때, [라이선스를 추가할 프로젝트를 사용하고 기여할 수 있는 **커뮤니티**를 고려해보십시오: -* **프로젝트를 다른 프로젝트의 종속성으로 사용 하시겠습니까?** 관련 커뮤니티에서 가장 많이 사용되는 라이선스를 사용하는 것이 가장 좋습니다. 예시로, [MIT](https://choosealicense.com/licenses/mit/)는 [npm libraries](https://libraries.io/npm)에서 가장 인기있는 라이선스입니다. +* **프로젝트를 다른 프로젝트의 종속성으로 사용 하시겠습니까?** 관련 커뮤니티에서 가장 많이 사용되는 라이선스를 사용하는 것이 가장 좋습니다. 예시로, [MIT](https://choosealicense.com/licenses/mit/)는 [npm libraries](https://libraries.io/search?platforms=NPM)에서 가장 인기있는 라이선스입니다. * **프로젝트를 대기업에 어필하고 싶습니까?** 대기업은 모든 참여자의 명시적인 특허 라이선스를 원할 것입니다. 이 경우, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/)는 귀하(그리고 그들)을 커버해 줄것 입니다. * **독점 소스 소프트웨어에서 기여를 사용하고 싶지 않은 기여자에게 프로젝트를 어필하고 싶습니까?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) 혹은 (또한 독점 소스 서비스에 기여하지 않으려는 경우) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/)은 잘될 것 입니다. @@ -96,7 +88,7 @@ GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는 ## Does my project need an additional contributor agreement? -아마도 그렇지 않습니다. 대다수의 오픈소스 프로젝트에서 공개 소스 라이선스는 인바운드(기여자)와 아웃바운드(다른 참여자 및 사용자) 라이선스로 암묵적으로 사용됩니다. 프로젝트가 GitHub에 있는 경우, GitHub 서비스 약관은 "인바운드 = 아웃 바운드"[명시적 기본값](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license)로 지정합니다. +아마도 그렇지 않습니다. 대다수의 오픈소스 프로젝트에서 공개 소스 라이선스는 인바운드(기여자)와 아웃바운드(다른 참여자 및 사용자) 라이선스로 암묵적으로 사용됩니다. 프로젝트가 GitHub에 있는 경우, GitHub 서비스 약관은 "인바운드 = 아웃 바운드" [명시적 기본값](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license)으로 지정합니다. 기여자 라이선스 계약(CLA)이라고도 부르는 추가 기여자 계약은 프로젝트 메인테이너를 위한 관리 작업을 생성할 수 있습니다. 계약서에 얼마나 많은 작업을 추가할지는 프로젝트와 구현에 달려 있습니다. 간단한 동의는 프로젝트 참여자가 프로젝트 오픈소스 라이선스하에 기여할 수 있는 권리를 클릭으로 확인해야 할 수도 있습니다. 보다 복잡한 합의는 법적 검토와 기여자 고용주의 서명을 요구할 수 있습니다. @@ -133,7 +125,7 @@ GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는 * **특허:** 귀하의 회사가 귀하의 프로젝트를 [공개](https://en.wikipedia.org/wiki/Public_disclosure)하여 특허를 신청할 계획입니까? 안타깝게도, 기다려달라는 요청을 받을 수 있습니다 (또는 회사에서 애플리케이션의 지혜를 재고 할 수도 있음). 대규모 특허 포트폴리오를 보유한 회사의 직원으로부터 프로젝트에 대한 기여가 기대되는 경우, 법무팀은 기여자(Apache 2.0 또는 GPLv3 등)의 명시적인 특허 지원 또는 추가 기부자 동의서를 사용하여 라이선스를 사용하기를 원할 수 있습니다(위 참조). -* **상표:** 프로젝트 이름이 [기존 상표와 충돌하지 않는지](../starting-a-project/#avoiding-name-conflicts) 다시 확인하십시오. 만약 프로젝트에서 자신의 회사 상표를 사용하는 경우에 충돌이 발생하지 않는지도 확인하십시오. [FOSSmarks](http://fossmarks.org/)는 무료 및 오픈소스 프로젝트의 맥락에서 상표를 이해하는 실질적인 가이드입니다. +* **상표:** 프로젝트 이름이 [기존 상표와 충돌하지 않는지](../starting-a-project/#이름-중복-피하기) 다시 확인하십시오. 만약 프로젝트에서 자신의 회사 상표를 사용하는 경우에 충돌이 발생하지 않는지도 확인하십시오. [FOSSmarks](http://fossmarks.org/)는 무료 및 오픈소스 프로젝트의 맥락에서 상표를 이해하는 실질적인 가이드입니다. * **개인 정보:** 프로젝트가 사용자에 대한 데이터를 수집합니까? 법률팀은 회사 정책 및 외부 규정을 준수하도록 도울 수 있습니다. @@ -152,7 +144,7 @@ GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는 * **공개 할 내용:** [(거의) 다?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) 귀하의 법무팀이 귀하의 회사 오픈소스 전략을 이해하고 투자한다면, 귀하의 노력을 방해하는 것보다 최선을 다 할 수 있습니다. -* **준수:** 회사가 오픈소스 프로젝트를 공개하지 않더라도, 다른 회사의 오픈 소스 소프트웨어를 사용합니다. [Awareness and process](https://www.linux.com/blog/why-companies-use-open-source-need-compliance-program)는 두통, 제품 지연 및 법적 소송을 예방할 수 있습니다. +* **준수:** 회사가 오픈소스 프로젝트를 공개하지 않더라도, 다른 회사의 오픈 소스 소프트웨어를 사용합니다. [Awareness and process](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/)는 두통, 제품 지연 및 법적 소송을 예방할 수 있습니다. * **특허:** 귀사는 회원사의 주요 오픈소스 프로젝트 사용을 보호하거나 다른 대체 특허 라이센싱을 모색하기 위해, [Open Invention Network](http://www.openinventionnetwork.com/)에 가입 할 수 있습니다. -* **가버넌스:** 특히 프로젝트를 [회사 외부의 법인](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project)으로 옮기는 것이 이치에 맞을 경우에 할 수 있습니다. +* **가버넌스:** 특히 프로젝트를 [회사 외부의 법인](../leadership-and-governance/#제-프로젝트를-지원하려면-법인이-필요한가요)으로 옮기는 것이 이치에 맞을 경우에 할 수 있습니다. diff --git a/_articles/ko/metrics.md b/_articles/ko/metrics.md index 4db7c4cb4aeba501cef13ea091832b2eb69be5f1..19d657dbf9553edc493c1bb6f8cba7f9149667c6 100644 --- a/_articles/ko/metrics.md +++ b/_articles/ko/metrics.md @@ -3,12 +3,6 @@ lang: ko title: 오픈소스 측정항목 description: 성공을 측정하고 추적함으로써 오픈소스 프로젝트가 성공할 수 있도록 정보에 입각한 의사 결정을 하십시오. class: metrics -toc: - why-measure-anything: "왜 무엇이든지 측정합니까?" - discovery: "발견" - usage: "사용" - retention: "보유" - maintainer-activity: "메인테이너 활동" order: 9 image: /assets/images/cards/metrics.png related: diff --git a/_articles/ko/starting-a-project.md b/_articles/ko/starting-a-project.md index feea1b2bf068d3078cf9cf720166e797960b0cea..4581cd52132d3e0f8d6c073702bfa1137496d3b0 100644 --- a/_articles/ko/starting-a-project.md +++ b/_articles/ko/starting-a-project.md @@ -1,14 +1,8 @@ --- lang: ko title: 오픈소스 프로젝트 시작하기 -description: 오픈소스의 세계에 대해 자세히 알아보고 자신만의 프로젝트를 시작할 준비를 하십시오. +description: 오픈소스의 세계에 대해 자세히 알아보고 여러분의 프로젝트를 시작할 준비를 해보세요. class: beginners -toc: - the-what-and-why-of-open-source: "오픈소스의 목적 및 이유" - should-i-launch-my-own-open-source-project: "나 자신의 오픈소스 프로젝트를 시작해야합니까?" - launching-your-own-open-source-project: "나만의 오픈소스 프로젝트 시작하기" - naming-and-branding-your-project: "프로젝트 네이밍 및 브랜딩" - your-pre-launch-checklist: "출시 전 체크리스트" order: 2 image: /assets/images/cards/beginner.png related: @@ -18,285 +12,285 @@ related: ## The "what" and "why" of open source -따라서 오픈소스를 시작하는 것에 대해 생각하고 있습니까? 축하합니다! 세상은 당신의 기여를 높이 평가합니다. 오픈소스란 무엇이며, 왜 사람들이 그렇게하는지 이야기해 봅시다. +오픈소스를 시작하려고 하시나요? 축하합니다! 세상이 여러분의 기여를 높이 살 것입니다. 오픈소스란 무엇이며, 왜 사람들이 오픈소스를 사용하는지 알아봅시다. -### "오픈소스"란 무엇을 의미합니까? +### "오픈소스"란 무엇인가요? -즉 **누구나 프로젝트를 보고, 사용하고, 수정하고, 배포 할 수 있습니다.** 이러한 권한은 [오픈소스 라이선스](https://opensource.org/licenses)를 통해 시행됩니다. +오픈소스 프로젝트에서는 **누구나 어떤 목적으로든 프로젝트를 보고, 사용하고, 수정하고, 배포할 수 있습니다.** 이러한 권한은 [오픈소스 라이선스](https://opensource.org/licenses)를 통해 적용됩니다. -오픈소스는 채택의 장벽을 낮추어 아이디어가 빠르게 확산될 수 있기 때문에 강력합니다. +오픈소스는 채택의 장벽을 낮춰 아이디어를 신속하게 퍼뜨릴 수 있기 때문에 강력합니다. -그것이 어떻게 작동하는지 이해하려면, 친구가 potluck을 가지고 있다고 상상해보고, 체리 파이를 가지고 오십시오. +오픈소스가 어떻게 돌아가는지 이해하기 위해, 친구가 솥밥을 먹고 있는데 여러분이 체리 파이를 가지고 간다고 생각해 보세요. -* 모두가 파이를 먹습니다 (_사용_) -* 파이가 히트를 쳤습니다! 그들은 당신에게 파이 제조법을 묻습니다 (_보기_) -* 한 친구인, 제과점 주방장 Alex는 설탕을 줄이는 것이 좋다고 조언합니다 (_수정_) -* 다른 친구인, Lisa는 다음 주 저녁 식사에 그것을 사용할 것을 요청합니다 (_배포_) +* 모두가 파이를 먹을 수 있습니다. (_사용_) +* 파이가 히트를 쳤습니다! 그들은 여러분이 만들어 공개한 파이의 레시피를 찾아봅니다. (_소스 뷰_) +* 제과점 주방장인 한 친구 알렉스가 설탕을 줄이는 게 좋겠다고 조언합니다. (_수정_) +* 다른 친구인 리사는 다음 주 저녁 식사에 그 파이를 준비하고 싶다고 요청합니다. (_배포_) -비교해 보면, 독점 소스 과정은 식당에 가서 체리 파이 한 조각을 주문할 것입니다. 당신은 파이를 먹기 위해 수수료를 지불해야하며, 레스토랑은 아마도 당신에게 요리 방법을 알려주지 않을 것입니다. 만약 파이를 정확하게 복사하여 같은 이름으로 팔면, 레스토랑이 당신을 상대로 고소할 수도 있습니다. +비교해 보면, 독점 소스 과정은 레스토랑에 가서 체리 파이 한 조각을 주문할 것과 같습니다. 여러분은 파이를 먹기 위해 요금을 지불해야 하며 레스토랑은 아마 여러분에게 레시피를 알려주지 않을 것입니다. 만약 파이를 똑같이 베껴 여러분의 이름을 달고 판다면 레스토랑에서 여러분을 고소할 지도 모르죠. -### 왜 사람들은 자신의 작업을 오픈소스로 공개합니까? +### 왜 사람들은 자기 작업을 오픈소스로 공개하나요? -사람이나 조직이 프로젝트 소스를 공개하려는 데는 [여러 가지 이유](http://ben.balter.com/2015/11/23/why-open-source/)가 있습니다. 몇 가지 예는 다음과 같습니다: +사람이나 조직이 프로젝트 소스를 공개하려는 데에는 [여러 가지 이유](http://ben.balter.com/2015/11/23/why-open-source/)가 있습니다. 몇 가지 예는 다음과 같습니다. -* **협업:** 오픈소스 프로젝트는 전 세계 누구나 변화를 수용 할 수 있습니다. [Exercism](https://github.com/exercism/)를 예시로 들면, 350명이 넘는 기여자가 참여하는 프로그래밍 연습 플랫폼입니다. +* **협업:** 오픈소스 프로젝트는 전 세계 누구에게서든 수정을 받을 수 있습니다. 예를 들어 [Exercism](https://github.com/exercism/)은 350명이 넘는 기여자가 참여하는 프로그래밍 연습 플랫폼입니다. -* **채택과 재가공:** 오픈소스 프로젝트는 거의 모든 목적으로 누구나 사용할 수 있습니다. 사람들은 그것을 사용하여 다른 것을 만들 수도 있습니다. [WordPress](https://github.com/WordPress)를 예시로 들면, [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md)라는 기존 프로젝트의 포크로 시작되었습니다. +* **채택과 재가공:** 오픈소스 프로젝트는 거의 모든 용도로 누구나 사용할 수 있습니다. 심지어 사람들이 그 프로젝트를 기반으로 다른 프로젝트를 만들 수도 있습니다. 예컨대 [WordPress](https://github.com/WordPress)는 [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md)라는 기존 프로젝트의 포크로 시작했습니다. -* **투명도:** 누구나 오픈소스 프로젝트에서 오류나 불일치를 검사 할 수 있습니다. 투명성은 [불가리아](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) 또는 [미국](https://sourcecode.cio.gov/)과 같은 정부, 은행 또는 건강 관리와 같은 규제 대상 산업, Let's Encrypt와 같은 보안 소프트웨어와 관련이 있습니다. +* **투명성:** 누구나 오픈소스 프로젝트에서 오류나 불일치를 검사 할 수 있습니다. 투명성은 [불가리아](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a)나 [미국](https://sourcecode.cio.gov/) 같은 정부, 은행 또는 의료 같은 규제 대상 산업, Let's Encrypt 등의 보안 소프트웨어에는 투명성이 중요합니다. -오픈소스는 소프트웨어만을 위한 것이 아닙니다. 데이터 세트에서부터 서적에 이르기까지 모두 오픈소스할 수 있습니다. [GitHub Explore](https://github.com/explore)에서 다른 오픈소스 아이디어를 확인하십시오. +오픈소스는 소프트웨어만을 위한 것이 아닙니다. 데이터 세트에서부터 서적에 이르기까지 모두 오픈소스로 만들 수 있습니다. [GitHub Explore](https://github.com/explore)에서 다른 오픈소스 아이디어를 확인해 보세요. -### 오픈소스는 "무료"를 의미합니까? +### 오픈소스는 "무료"를 의미하나요? -오픈소스의 가장 큰 매력 중 하나는 비용이 들지 않는다는 것입니다. 그러나 "무료 비용"은 오픈소스의 전반적인 가치의 부산물입니다. +오픈소스의 가장 큰 매력 중 하나는 비용이 들지 않는다는 것입니다. 그러나 "무료"는 오픈소스의 전반적인 가치의 부산물에 불과합니다. -[오픈소스 라이선스](https://opensource.org/osd-annotated)는 누구나 거의 모든 목적으로 프로젝트를 사용, 수정 및 공유 할 수 있어야 하므로 프로젝트 자체는 무료입니다. 만약 프로젝트에 사용할 비용이 들었다면, 누구나 합법적으로 복사본을 만들어 무료 버전을 사용할 수 있습니다. +[오픈소스 라이선스](https://opensource.org/osd-annotated)는 누구나 거의 모든 목적으로 프로젝트를 사용, 수정, 공유할 수 있어야 하므로 프로젝트 자체는 무료입니다. 만약 프로젝트에서 비용을 청구한다면 누구나 합법적으로 복사본을 만들어 무료 버전을 사용할 수 있습니다. -결과적으로 대부분의 오픈소스 프로젝트는 무료이지만, "무료"는 오픈소스 정의의 일부가 아닙니다. 오픈소스의 공식적인 정의를 계속 준수하면서 이중 라이선스 또는 제한된 기능을 통해 간접적으로 오픈소스 프로젝트를 청구할 수있는 방법이 있습니다. +결론적으로 대부분의 오픈소스 프로젝트는 무료이지만, "무료"는 오픈소스 정의의 일부가 아닙니다. 오픈소스의 공식적인 정의를 계속 준수하면서도 이중 라이선스 또는 제한된 기능을 통해 간접적으로 오픈소스 프로젝트 사용에 비용을 청구할 수 있는 방법이 있습니다. ## Should I launch my own open source project? -짧은 결과는 예입니다. 결과에 관계없이, 자신의 프로젝트를 시작하는 것이 오픈소스의 작동 방식을 배우기위한 훌륭한 방법이기 때문입니다. +짧게 답하자면 그렇습니다. 결과가 어떻든 여러분 자신의 프로젝트를 시작하는 것이 오픈소스가 돌아가는 방식을 배우기 위한 훌륭한 방법이 되기 때문입니다. -이전에 프로젝트의 소스를 공개 한 적이 없다면, 다른 사람이 의견을 말하지 않거나 전혀 눈치채지 못할거라고 불안해 할 수 있습니다. 이게 당신의 이야기처럼 들린다면, 당신은 혼자가 아닙니다! +이전에 프로젝트 소스를 공개해본 적이 없다면 누군가 뭐라고 하거나 소스를 보는 것 자체가 긴장될지도 모릅니다. 이게 여러분의 이야기처럼 들리나요? 여러분은 혼자가 아닙니다! -오픈소스 작품은 글쓰기나 페인팅과 비슷한 다른 창의적인 활동과 같습니다. 전세계에 당신의 작품을 공유하는 것이 무섭다는 생각이 들지만, 청중이 없는 경우에도 연습하는 것이 유일한 방법입니다. +오픈소스 작업은 글을 쓰거나 그림을 그리는 활동과 같습니다. 여러분의 작업을 세상과 공유하기가 두려울 수도 있지만, 발전하는 방법은 연습 뿐입니다. 설령 봐주는 사람이 없더라도요. -아직 확신하지 못했다면, 잠시 시간을 내어 목표가 무엇인지 생각해보십시오. +아직 확신이 서지 않는다면 여러분의 목표가 무엇인지 잠시 생각해 보세요. ### 목표 설정하기 -목표는 어떤 일을 해야할 건지, 어떤 말을 하지 않을건지, 다른 사람들에게 도움이 필요한 곳을 파악하는 것에 도움이 될 수 있습니다. 스스로에게 물어보십시오, _왜 내가 이 프로젝트를 오픈 소스로 만들었습니까?_ +목표는 여러분이 무엇을 해야 하는지, 무엇을 하지 말아야 하는지, 어디서 도움을 받아야 하는지 찾는 데 도움이 될 수 있습니다. 먼저 왜 프로젝트를 오픈소스화하려고 하는지 자문해 보세요. -이 질문에 대한 정답은 아무도 없습니다. 한 프로젝트에 대해 여러 가지 목표를 가질 수도 있고, 다른 목표를 가진 다른 프로젝트를 가질 수도 있습니다. +이 질문에 대해 정해진 정답은 없습니다. 한 프로젝트에 대해 여러 가지 목표를 가질 수도 있고, 각기 다른 목표를 가진 여러 프로젝트를 진행할 수도 있습니다. -귀하의 유일한 목표가 귀하의 업무를 과시하는 것이라면, 귀하는 README에 기여를 원한다고 말할 수 없습니다. 다른 한편으로는, 기여자를 원한다면 명확한 문서화에 시간을 투자를 통해 신규 방문자가 환영받는다고 느끼게 될 것입니다. +여러분의 유일한 목표가 여러분의 성과를 보여주는 것이라면 기여를 원하지 않을 수도 있고 README 파일에 그렇게 적어둘 수도 있습니다. 반대로 기여자를 원한다면 명확한 문서화에 시간을 투자하고 방문자들을 환영해야 합니다. -프로젝트가 성장함에 따라 커뮤니티는 단순한 코드 그 이상을 필요로 할 수 있습니다. 이슈에 대응하고, 코드를 검토하고, 프로젝트를 홍보하는 것은 오픈소스 프로젝트에서 중요한 작업입니다. +프로젝트가 성장함에 따라 커뮤니티에는 단순한 코드 이상의 것이 필요할 수 있습니다. 이슈에 대응하고, 코드를 검토하고, 프로젝트를 홍보하는 것은 오픈소스 프로젝트에서 중요한 작업입니다. -비코딩 작업에 소요되는 시간은 프로젝트의 크기와 범위에 따라 다르지만, 직접 해결하거나 도움을 줄 담당자를 준비해야합니다. +코딩이 아닌 작업에 소요되는 시간은 프로젝트의 크기와 범위에 따라 다르지만, 여러분이 직접 관리자로서 문제를 해결하거나 도움을 줄 사람을 찾아야 합니다. -**만약 프로젝트를 오픈소스화하는 회사의 일원이라면,** 프로젝트가 번창하기 위해 필요한 내부 자원이 있는지 확인하십시오. 시작한 후에 프로젝트를 유지 관리 할 책임이 있는 사람과 해당 작업을 커뮤니티와 공유하는 방법을 식별해야합니다. +**만약 프로젝트를 오픈소스화하는 회사의 일원이라면** 프로젝트의 성공을 위해 필요한 내부 자원이 있는지 확인하세요. 공개 후 누가 프로젝트 관리 책임이 있는지, 어떻게 작업들을 커뮤니티와 공유할 것인지 파악하고 정해야 합니다. -홍보, 운영 및 프로젝트 유지를 위해 전담 예산이나 인력이 필요하다면 일찍 대화를 시작하십시오. +홍보, 운영 및 프로젝트 유지를 위해 전담 예산이나 인력이 필요한 경우 이런 대화를 조기에 시작하세요. ### 다른 프로젝트에 기여하기 -다른 사람들과 협력하거나 오픈소스가 어떻게 작동하는지 이해하는 방법을 배우는 것이 목표라면, 기존 프로젝트에 기여하는 것을 고려하십시오. 이미 사용하고 사랑하는 프로젝트부터 시작하십시오. 프로젝트에 기여하는 것은 오타를 수정하거나 문서를 업데이트하는 것만큼 간단합니다. +사람들과 협업하는 방법을 배우거나 오픈소스가 어떻게 돌아가는지 이해하는 것이 목표라면 기존 프로젝트에 기여하는 것을 고려해 보세요. 여러분이 이미 애용하고 있는 프로젝트에서부터 시작하세요. 오타를 수정하거나 문서를 업데이트하는 것처럼 간단한 것으로도 기여할 수 있습니다. -기여자로 시작하는 방법을 모르는 경우에는, [오픈소스에 기여하는 방법 가이드](../how-to-contribute/)를 확인하십시오. +기여를 시작하는 법을 잘 모르겠다면 [오픈소스에 기여하는 방법 가이드](../how-to-contribute/)를 확인해 보세요. ## Launching your own open source project -당신의 일을 오픈 소스화 할 완벽한 시간은 없습니다. 아이디어, 진행중인 작업 또는 독점 소스가 된 이후의 수년이 지난 뒤에도 오픈소스화 할 수 있습니다. +프로젝트를 오픈소스화할 정해진 타이밍은 없습니다. 아이디어, 진행중인 작업 혹은 수년이 지난 비공개 소스도 오픈소스화할 수 있습니다. -일반적으로 말하면, 다른 사람들이 보기에 편하게 느끼고 프로젝트에 대한 피드백을 주려면 프로젝트를 오픈소스화 해야합니다. +일반적으로 다른 사람이 여러분의 작업을 보고 피드백을 제공해도 불편할 만한 점이 없을 때 프로젝트를 오픈소스화하면 됩니다. -프로젝트를 오픈소스로 결정한 단계에 관계없이, 모든 프로젝트에는 다음과 같은 문서가 포함되어야합니다: +프로젝트를 오픈소스화하기로 결정한 시점에 상관없이 모든 프로젝트에는 다음과 같은 문서가 포함되어 있어야 합니다. * [오픈소스 라이선스](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) * [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) * [기여 가이드라인](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) -* [Code of conduct](../code-of-conduct/) +* [행동 강령](../code-of-conduct/) -메인테이너는 이러한 구성 요소를 사용하여 기대를 전달하고, 기여를 관리하고, (자신의 권리를 포함한) 모든 사람의 법적 권리를 보호 할 수 있습니다. 그들은 긍정적인 경험을 가질 기회를 상당히 증가시킵니다. +관리자는 이러한 구성 요소로 기대치를 전달하고, 기여를 관리하고, (여러분을 포함한) 모두의 법적 권리를 보호할 수 있습니다. 위 문서들은 여러분이 긍정적인 경험을 하게 될 가능성을 크게 증가시킵니다. -프로젝트가 GitHub에 있는 경우, 권장 파일 이름을 사용하여 이러한 파일을 루트 디렉토리에 저장하면 GitHub에서 해당 파일을 인식하여 자동으로 사용자에게 보여줍니다. +프로젝트가 GitHub에 있는 경우, 권장 파일 이름을 적용해 이러한 파일들을 최상위 폴더에 저장해 두면 GitHub에서 해당 파일을 인식해 자동으로 사람들에게 보여줍니다. ### 라이선스 선택하기 -오픈소스 라이선스는 타인이 영향을 주지 않고 프로젝트에서 사용, 복사, 수정 및 기여할 수 있음을 보증합니다. 또한 복잡하게 얽혀있는 법적 상황으로부터 당신을 보호합니다. **오픈소스 프로젝트를 시작할 때 라이선스를 포함해야합니다.** +오픈소스 라이선스는 사람들이 여러분의 프로젝트에 영향을 주지 않고 사용, 복사, 수정 및 기여할 수 있도록 보장합니다. 또한 복잡하게 얽혀 있는 법적 상황으로부터 당신을 보호합니다. **오픈소스 프로젝트를 시작한다면 반드시 라이선스를 포함해야 합니다.** -법률 업무는 재미 없습니다. 좋은 소식은 기존 라이선스를 복사하여 저장소에 붙여 넣을 수 있다는 것입니다. 당신의 노력을 보호하는 데 단지 1분 정도만 소요됩니다. +법률에 관한 일은 즐겁지 않습니다. 좋은 소식은 기존 라이선스를 복사해 저장소에 붙여넣을 수 있다는 것입니다. 여러분의 노력을 보호하는 데 1분이면 충분할 것입니다. -[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), 그리고 [GPLv3](https://choosealicense.com/licenses/gpl-3.0/)는 가장 인기있는 오픈소스 라이선스입니다, 그러나 선택할 수있는 [다른 옵션](https://choosealicense.com)도 있습니다. +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), 그리고 [GPLv3](https://choosealicense.com/licenses/gpl-3.0/)가 가장 인기있는 오픈소스 라이선스지만 선택할 수있는 [다른 옵션](https://choosealicense.com)도 있습니다. -GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는 옵션이 제공됩니다. 오픈소스 라이선스를 포함하면 GitHub 프로젝트를 오픈소스로 만들 수 있습니다. +GitHub에서 새 프로젝트를 만들면 라이선스를 선택할 수 있는 옵션이 제공됩니다. 오픈소스 라이선스를 포함하면 GitHub 프로젝트를 오픈소스로 만들 수 있습니다.  -만약 오픈소스 프로젝트를 관리하는 법적 측면에 대해 다른 질문이나 우려 사항이 있으시면, [이 내용은 귀하를 대상으로합니다](../legal/). +오픈소스 프로젝트 관리의 법적 측면에 대해 다른 질문이나 우려되는 점이 있다면 [이 내용을 참조하세요](../legal/). -### Writing a README +### README 파일 작성하기 -README는 프로젝트 사용 방법을 설명하는 것 이상을 수행합니다. 또한 프로젝트가 중요한 이유와 사용자가 수행 할 수 있는 작업에 대해 설명합니다. +README는 프로젝트 사용 방법을 설명하는 것 이상의 일을 수행합니다. 프로젝트가 중요한 이유와 사용자가 프로젝트를 이용해 할 수 있는 작업에 대해서도 설명합니다. -README에 다음 질문에 답하십시오: +README에서 다음 질문에 답해 보세요. -* 이 프로젝트는 무엇을 합니까? -* 이 프로젝트는 왜 유용합니까? -* 어떻게 시작합니까? -* 필요할 경우, 어디에서 더 많은 도움을 받을 수 있습니까? +* 이 프로젝트는 무슨 일을 하나요? +* 이 프로젝트가 유용한 이유는 무엇인가요? +* 어떻게 시작해야 하나요? +* 필요하다면 어디에서 더 많은 도움을 받을 수 있을까요? -README를 사용하여 기여를 처리하는 방법, 프로젝트의 목표가 무엇인지, 라이선스 및 속성에 대한 정보와 같은 다른 질문에 답할 수 있습니다. 기여를 받고 싶지 않거나, 프로젝트가 아직 준비되지 않은 경우에는 이 정보를 적어 두십시오. +README를 사용하여 여러분이 기여를 받아들이는 방식, 프로젝트의 목표, 라이선스 및 속성에 대한 정보와 같은 다른 질문에 답할 수 있습니다. 기여를 받고 싶지 않거나, 프로젝트가 아직 준비되지 않았다면 그렇게 적어 두세요. -때로는, 사람들이 프로젝트가 끝나지 않았거나 기부를 원치 않기 때문에 README를 쓰지 않는 경우가 있습니다. 이것은 모두 하나를 쓰는 아주 좋은 이유입니다. +때때로 사람들은 프로젝트가 완성되지 않았거나 기여를 원치 않기 때문에 README를 작성하지 않는 경우가 있습니다. 그것도 README를 작성할 좋은 이유입니다. -더 많은 영감을 얻으려면, @18F의 ["Making READMEs Readable"](https://pages.18f.gov/open-source-guide/making-readmes-readable/) 혹은 @PurpleBooth의 완전한 README를 작성하는[README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2)를 사용해보십시오. +@18F의 ["Making READMEs Readable"](https://pages.18f.gov/open-source-guide/making-readmes-readable/)에서 더 많은 영감을 얻거나 @PurpleBooth의 [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2)을 이용해 전체 README를 작성해 보세요. -README 파일을 루트 디렉토리에 포함시키면, GitHub가 자동으로 저장소 홈페이지에 표시합니다. +README 파일을 최상위 폴더에 포함시키면, GitHub가 자동으로 저장소 홈페이지에 내용을 표시합니다. -### Writing your contributing guidelines +### 기여 가이드라인 작성하기 -CONTRIBUTING 파일은 잠재 고객에게 프로젝트 참여 방법을 알려줍니다. 예를 들어 다음 정보를 포함 할 수 있습니다: +CONTRIBUTING 파일은 잠재 기여자들에게 프로젝트에 기여하는 방법을 알려줍니다. 예를 들어 다음 정보를 포함할 수 있습니다. -* 버그 보고서를 제출하는 방법 ([이슈와 pull request 템플릿](https://github.com/blog/2111-issue-and-pull-request-templates)을 사용해보십시오) +* 버그 보고서를 제출하는 방법 ([이슈와 PR 템플릿](https://github.com/blog/2111-issue-and-pull-request-templates)을 사용해 보세요) * 새로운 기능을 제안하는 방법 * 환경 설정 및 테스트 실행 방법 -기술적 세부 사항 외에도, CONTRIBUTING 파일은 기여에 대한 귀하의 기대를 전달할 수 있는 기회입니다, 예로 들면 : +기술적 세부 사항과 더불어 여러분이 어떤 기여를 기대하는지 전달할 수도 있습니다. -* 당신이 찾고있는 기여의 종류 +* 원하는 기여 유형 * 프로젝트 로드맵 또는 비전 -* 참여자가 귀하와 연락해야 (또는 하지 말아야) 하는 방법 +* 기여자가 여러분과 연락하는 데 사용할 (혹은 사용하지 말아야 할) 방법 -따뜻하고 친숙한 분위기의 음색을 사용하고, 기여에 대한 구체적인 제안 (예를 들어 문서 작성 또는 웹 사이트 만들기)을 제공하면 신규 방문자가 참여하고 환영하게 될 것입니다. +따뜻하고 친근한 어조를 사용하고, 문서나 웹사이트 작성 등 기여에 대한 구체적인 제안을 제공하는 것은 새로운 사람들이 기꺼이 기여를 만들게 하는 데 도움이 될 수 있습니다. -예시로, [Active Admin](https://github.com/activeadmin/activeadmin/)은 다음과 함께 [기여 가이드](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md)를 시작합니다: +예를 들어 [Active Admin](https://github.com/activeadmin/activeadmin/)은 다음과 같이 [기여 가이드](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md)를 시작합니다. -> 먼저 Active Admin에 기여 해 주셔서 감사합니다. Active Admin을 훌륭한 도구로 만드는 것은 여러분과 같은 사람들입니다. +> 먼저, Active Admin에 기여해 주셔서 감사합니다. 여러분의 기여가 Active Admin을 이렇게 훌륭한 툴로 만듭니다. -프로젝트의 가장 초기 단계에서, CONTRIBUTING 파일을 간단하게 만들 수 있습니다. 버그 또는 파일 문제를 보고하는 방법과 (테스트에 필요한) 기술적 요구 사항을 항상 설명하여 기여를 해야합니다. +프로젝트의 초기 단계에서는 CONTRIBUTING 파일이 단순할 수 있습니다. 항상 버그 또는 파일 이슈를 보고하는 방법과 기여에 필요한 테스트 등 기술적 요구 사항을 설명해야 합니다. -시간이 지나면, 다른 자주 묻는 질문을 CONTRIBUTING 파일에 추가 할 수 있습니다. 이 정보를 적어두면 같은 질문을 반복해서 하는 사람들이 줄어들 것입니다. +시간이 지나면 자주 묻는 질문을 CONTRIBUTING 파일에 추가할 수 있습니다. 이 정보를 적어두면 같은 질문을 반복해서 하는 사람들이 줄어들 것입니다. -CONTRIBUTING 파일을 작성하는 데 도움이 필요하면, check out @nayafia의 [contributing guide template](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) 혹은 @mozilla의 ["How to Build a CONTRIBUTING.md"](http://mozillascience.github.io/working-open-workshop/contributing/)를 보십시오. +CONTRIBUTING 파일을 작성하는 데 도움이 필요하면 @nayafia의 [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) 또는 @mozilla의 ["How to Build a CONTRIBUTING.md"](http://mozillascience.github.io/working-open-workshop/contributing/)을 참조하세요. -README에 CONTRIBUTING 파일을 링크하면 더 많은 사람들이 볼 수 있습니다. 만약 당신이 [CONTRIBUTING 파일을 프로젝트의 저장소에 두면](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub는 참여자가 이슈를 생성하거나 pull request를 열면 자동으로 파일에 연결됩니다. +README에 CONTRIBUTING 파일을 링크하면 더 많은 사람들이 읽게 할 수 있습니다. [CONTRIBUTING 파일을 프로젝트의 저장소에 두면](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) 기여자가 이슈를 생성하거나 PR를 열 때 GitHub가 자동으로 링크를 생성합니다.  -### 행동강령 세우기 +### 행동 강령 세우기 -마지막으로, 행동강령은 프로젝트 참가자의 행동에 대한 기본 규칙을 설정하는 데 도움이 됩니다. 이는 커뮤니티나 회사를 위해 오픈소스 프로젝트를 시작하는 경우 특히 유용합니다. 행동강령은 건강하고 건설적인 커뮤니티 행동을 촉진하도록 권한을 부여하며, 이는 메인테이너로서의 스트레스를 감소시킵니다. +마지막으로 행동 강령은 프로젝트 참가자의 행동에 대한 기본 규칙을 정하는 데 도움이 됩니다. 이는 커뮤니티나 회사의 오픈소스 프로젝트를 시작할 때 특히 유용합니다. 행동 강령은 건강하고 건설적인 커뮤니티 행동을 촉진할 수 있게 해 주는데, 이는 관리자 여러분의 스트레스를 줄여줄 것입니다. -자세한 정보를 확인하려면, [행동강령 가이드](../code-of-conduct/)를 보십시오. +자세한 내용은 [행동강령 가이드](../code-of-conduct/)를 참조하세요. -행동강령은 참여자가 _어떻게_ 행동 할 것으로 기대하는지 의사 소통하는 것 외에도, 이러한 기대 사항이 적용되는 대상, 적용시기, 위반이 발생할 경우 수행 할 작업을 설명하는 경향이 있습니다. +행동 강령은 참여자가 _어떻게_ 행동하기를 기대하는지 전달하는 것 외에, 이러한 기대가 누구에게 적용되는지, 언제 적용되는지, 위반할 경우 어떻게 하는지 등을 다루기도 합니다. -오픈소스 라이선스와 마찬가지로 행동강령에 대한 새로운 기준도 있으므로, 사용자가 직접 작성할 필요는 없습니다. [Contributor Covenant](http://contributor-covenant.org/)는 Kubernetes, Rails 및 Swift를 포함하여 [40,000개 이상의 오픈소스 프로젝트](http://contributor-covenant.org/adopters/)에서 사용되는 행동 강령입니다. 어떤 텍스트를 사용하든 필요에 따라 행동강령을 시행 할 준비가 되어 있어야합니다. +오픈소스 라이선스와 마찬가지로 행동 강령에 대한 새로운 표준도 있으므로 직접 작성할 필요는 없습니다. [Contributor Covenant](https://www.contributor-covenant.org/)는 Kubernetes, Rails 및 Swift를 포함한 [40,000개 이상의 오픈소스 프로젝트](https://www.contributor-covenant.org/adopters)에서 사용되는 행동 강령입니다. 어느 것을 사용하든, 필요에 따라 행동 강령을 시행할 준비가 되어 있어야 합니다. -텍스트를 저장소의 CODE_OF_CONDUCT 파일에 직접 붙여 넣으십시오. 프로젝트의 루트 디렉토리에 파일을 보관하여 찾기 쉽도록 하고, README에서 링크를 연결하십시오. +행동 강령을 저장소의 CODE_OF_CONDUCT 파일에 직접 붙여넣으세요. 파일을 쉽게 찾을 수 있게 프로젝트 최상위 폴더에 저장하고 README에 링크를 첨부하세요. ## Naming and branding your project -브랜딩은 화려한 로고 또는 재미있는 프로젝트 이름 이상입니다. 그것은 당신의 프로젝트에 대해 어떻게 이야기하고, 당신의 메시지를 가지고 도달했는지에 관한 것입니다. +브랜딩은 화려한 로고나 매력적인 프로젝트 이름 그 이상입니다. 브랜딩은 여러분이 프로젝트를 어떻게 생각하는지, 누구에게 여러분의 메시지를 전달하고자 하는지에 대한 것입니다. -### 올바른 이름 고르기 +### 올바른 이름 짓기 -기억하기 쉬운 이름을 골라야하며, 이상적으로 프로젝트가 하는 일에 대한 아이디어를 제공하십시오. 예시입니다: +기억하기 쉬운 이름을 짓고 프로젝트가 어떤 일을 하는지 알 수 있게 하는 것이 이상적입니다. 아래의 예시를 보세요. -* [Sentry](https://github.com/getsentry/sentry)는 충돌보고를 위해 앱을 모니터링합니다 -* [Thin](https://github.com/macournoyer/thin)은 빠르고 간단한 Ruby 웹 서버입니다 +* [Sentry](https://github.com/getsentry/sentry)는 충돌 보고를 위해 앱을 모니터링합니다. +* [Thin](https://github.com/macournoyer/thin)은 빠르고 간단한 Ruby 웹 서버입니다. -기존 프로젝트를 기반으로 하는 경우, 그 이름을 접두사로 사용하면 프로젝트가 수행하는 작업을 분명히 알 수 있습니다 (예시. [node-fetch](https://github.com/bitinn/node-fetch)는 Node.js에서 `window.fetch`를 가져옵니다). +기존 프로젝트를 기반으로 하는 경우 그 이름을 접두사로 사용하면 프로젝트가 수행하는 작업을 쉽게 파악할 수 있습니다. 예컨대 [node-fetch](https://github.com/bitinn/node-fetch)는 `window.fetch`를 Node.js에 가져옵니다. -무엇보다 명확성을 고려하십시오. 농담은 재미 있지만, 일부 농담은 다른 문화나 다른 경험을 가진 사람들로 번역되지 않을 수도 있음을 기억하십시오. 잠재적인 사용자 중 일부는 회사 직원일 수 있습니다: 그들이 직장에서 당신의 프로젝트를 설명해야 할 때 불편하게 하고 싶지는 않습니다! +무엇보다 명확성을 고려하세요. 농담은 재미있지만, 어떤 농담은 다른 문화나 다른 경험을 가진 사람들에게는 이해되지 않을 수도 있음을 기억하세요. 잠재적인 사용자 중 일부는 회사 직원일 수 있습니다. 그들이 직장에서 여러분의 프로젝트를 설명하기 어렵게 만들고 싶지는 않을 것입니다! -### Avoiding name conflicts +### 이름 중복 피하기 -[비슷한 이름의 오픈소스 프로젝트가 있는지 확인하십시오](http://ivantomic.com/projects/ospnc/), 특히 동일한 언어 또는 같은 생태계를 공유하는 경우, 이름이 기존의 인기있는 프로젝트와 겹치면 잠재적인 고객을 혼동시킬 수 있습니다. +[비슷한 이름의 오픈소스 프로젝트가 있는지 확인하세요](http://ivantomic.com/projects/ospnc/). 특히 동일한 언어 또는 같은 생태계를 공유하는 경우, 이름이 기존의 인기 있는 프로젝트와 겹치면 사람들이 헷갈려 할 것입니다. -웹 사이트, Twitter 핸들 또는 프로젝트를 나타내는 다른 속성을 원하면 원하는 이름을 가져올 수 있는지 확인하십시오. 이상적으로는, 아직 사용하지 않으려는 경우에도 마음의 평화를 위해 [지금 해당 이름을 예약하십시오](https://instantdomainsearch.com/). +웹 사이트, Twitter 핸들 또는 다른 속성이 프로젝트를 표현하기를 원한다면 원하는 이름을 사용할 수 있는지 확인하세요. 이상적으로는, 그 이름을 아직 사용할 생각이 없더라도 마음의 평화를 위해 [이름을 차지해 두는 것이 좋습니다](https://instantdomainsearch.com/). -프로젝트 이름이 상표를 침해하지 않는지 확인하십시오. 회사는 나중에 프로젝트를 중단하거나, 법적 조치를 취할 것을 요구할 수 있습니다. 위험 부담이 되지 않습니다. +프로젝트 이름이 상표를 침해하지 않는지 확인하세요. 회사 측에서 프로젝트를 중단하거나 법적 조치를 취할 것을 요구할 수 있습니다. 리스크를 부담할 가치는 없습니다. -You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) for trademark conflicts. If you're at a company, this is one of the things your [legal team can help you with](../legal/). +[WIPO Global Brand Database](http://www.wipo.int/branddb/en/) 에서 상표명이 있는지 확인할 수 있습니다. 여러분이 회사에서 일을 하고 있다면 [법률팀이 도와줄 수 있을 것입니다](../legal/). -마지막으로, 프로젝트 이름에 대한 빠른 Google 검색을 수행하십시오. 사람들이 프로젝트를 쉽게 찾을 수 있습니까? 검색 결과에 표시하고 싶지 않은 것이 있습니까? +마지막으로, 프로젝트 이름을 구글에 검색해 보세요. 사람들이 프로젝트를 쉽게 찾을 수 있을까요? 검색 결과에 여러분이 원치 않는 것이 나타나지는 않나요? -### 당신이 쓰는 방법(그리고 코드)은 당신의 브랜드에도 영향을 미칩니다! +### 당신의 글(과 코드)도 브랜드에 영향을 미칩니다! -프로젝트가 진행되는 동안, 많은 글을 쓸 것입니다: README, 튜토리얼, 커뮤니티 문서, 이슈에 대한 회신, 뉴스레터 및 메일링 리스트 등. +프로젝트가 진행되는 동안 여러분은 README, 튜토리얼, 커뮤니티 문서, 이슈에 대한 답변, 뉴스레터 및 메일링 리스트까지 많은 글을 쓸 것입니다. -그것이 공식적인 문서이건 캐주얼 이메일이건, 당신의 작문 스타일은 프로젝트의 브랜드의 일부입니다. 잠재 고객에게 도달하는 방법과 전달하려는 톤인지 여부를 고려하십시오. +그것이 공식적인 문서든 평범한 이메일이든 여러분의 글 스타일은 프로젝트 브랜드의 일부입니다. 어떻게 청중에게 다가가야 좋을지, 여러분이 전달하고자 하는 어조는 무엇인지 고려하세요. -따뜻하고 포괄적인 언어 (예를 들어 한 사람을 언급 할 때도 "그들"과 같이)를 사용하면, 이 프로젝트가 새로운 참여자에게 환영받는 느낌을 줄 수 있습니다. 많은 독자가 원어민이 아니기 때문에 간단한 언어에 충실하십시오. +따뜻하고 포괄적인 언어(한 사람을 언급 할 때도 "그들"이라고 하듯)를 사용하면 이 프로젝트가 새로운 기여자에게 환영받는 느낌을 줄 수 있습니다. 많은 독자가 영어를 모국어로 사용하지 않을 수 있으므로 간단한 언어 사용에 충실하세요. -단어 작성 방법 이외에도, 코딩 스타일이 프로젝트 브랜드의 일부가 될 수도 있습니다. [Angular](https://github.com/johnpapa/angular-styleguide)와 [jQuery](http://contribute.jquery.org/style-guide/js/)는 엄격한 코딩 스타일과 가이드 라인을 가진 프로젝트의 두 가지 예시입니다. +작문 스타일 뿐 아니라 코딩 스타일도 프로젝트 브랜드의 일부가 될 수 있습니다. [Angular](https://github.com/johnpapa/angular-styleguide)와 [jQuery](http://contribute.jquery.org/style-guide/js/)는 엄격한 코딩 스타일과 가이드라인을 가진 프로젝트의 두 가지 예입니다. -프로젝트를 시작할 때 스타일 가이드를 작성할 필요가 없으며, 어쨌든 다른 코딩 스타일을 프로젝트에 통합하는 것을 즐긴다는 것을 알 수 있습니다. 그러나 글쓰기와 코딩 스타일이 다른 유형의 사람들을 끌어 모으거나 방해 할 수있는 방법을 예상해야합니다. 프로젝트의 가장 초기 단계는 보고자하는 선례를 설정할 기회입니다. +프로젝트를 시작할 때 스타일 가이드를 작성할 필요는 없으며, 여러분은 오히려 프로젝트에 여러 코딩 스타일이 혼재하는 것을 좋아할 수도 있습니다. 하지만 글과 코딩 스타일이 서로 다른 유형의 사람들을 끌어모으거나 단념시킬 수도 있다는 점을 예상해야 합니다. 프로젝트의 가장 초기 단계는 여러분이 원하는 선례를 만들 기회입니다. ## Your pre-launch checklist -프로젝트를 오픈소스로 할 준비가 되셨습니까? 다음은 도움이 되는 체크리스트입니다. 모든 체크박스를 확인하시겠습니까? 이제 갈 준비가 되었습니다! ["공개"를 클릭](https://help.github.com/articles/making-a-private-repository-public/)하고 등 뒤에서 몸을 담그십시오. +프로젝트를 오픈소스화할 준비가 되셨습니까? 다음은 도움이 되는 체크리스트입니다. 모든 칸에 체크하셨나요? 이제 출발할 준비가 되었습니다! ["공개"를 클릭](https://help.github.com/articles/making-a-private-repository-public/)하고 등을 토닥이세요. **문서**
Our goal is to provide an infrastructure that communities can use to be self sustainable, thus creating an environment where everyone — contributors, backers, sponsors — get concrete benefits out of it.
-— @piamancini, ["Moving beyond the charity framework"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141#.vgsbj9um9) +— @piamancini, ["Moving beyond the charity framework"](https://medium.com/open-collective/moving-beyond-the-charity-framework-b1191c33141)
-If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.python.org/pypi), the Python package manager, and the [Node.js Foundation](https://nodejs.org/en/foundation/) helps support [Express.js](https://expressjs.com/), a Node-based framework. +If your project is closely associated with a certain language or ecosystem, there may also be a related software foundation you can work with. For example, the [Python Software Foundation](https://www.python.org/psf/) helps support [PyPI](https://pypi.org/), the Python package manager, and the [Node.js Foundation](https://foundation.nodejs.org/) helps support [Express.js](https://expressjs.com/), a Node-based framework. diff --git a/_articles/legal.md b/_articles/legal.md index cb4f018463d44a8cc1cda9987f721c73d9b560f2..ed6cf093fd5a601059cedb92d49ffe2d6c280afa 100644 --- a/_articles/legal.md +++ b/_articles/legal.md @@ -40,7 +40,7 @@ When you [create a new project](https://help.github.com/articles/creating-a-new-  -**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://help.github.com/articles/github-terms-of-service/#f-copyright-and-content-ownership), which allows others to view and fork your project, but your work otherwise comes with no permissions. +**Making your GitHub project public is not the same as licensing your project.** Public projects are covered by [GitHub's Terms of Service](https://help.github.com/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions. If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so. @@ -72,7 +72,7 @@ On the other hand, if any of your dependencies' licenses are "strong copyleft" ( You may also want to consider the **communities** you hope will use and contribute to your project: -* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/npm). +* **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM). * **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered. * **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well. @@ -84,9 +84,9 @@ When you create a new project on GitHub, you are given the option to select a li Most projects never need to change licenses. But occasionally circumstances change. -For example, as your project grows it adds dependencies or users, or your company changes strategies, any of which could require or want a different license. Also, if you neglected to license your project from the start, adding a license is effectively the same as changing licenses. There are three fundamental things to consider when adding or changing a your project's license: +For example, as your project grows it adds dependencies or users, or your company changes strategies, any of which could require or want a different license. Also, if you neglected to license your project from the start, adding a license is effectively the same as changing licenses. There are three fundamental things to consider when adding or changing your project's license: -**It's complicated.** Determining license compatibility and compliance and who holds copyright can get complicated and confusing very quickly. Switching to a new but compatible license for new releases and contributions is different from relicensing all existing contributions. Involve your legal team the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception! +**It's complicated.** Determining license compatibility and compliance and who holds copyright can get complicated and confusing very quickly. Switching to a new but compatible license for new releases and contributions is different from relicensing all existing contributions. Involve your legal team at the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception! **Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses. @@ -96,7 +96,7 @@ Alternatively, you can have contributors agree in advance (via an additional con ## Does my project need an additional contributor agreement? -Probably not. For the vast majority of open source projects, an open source license implicitly serves as both the inbound (from contributors) and outbound (to other contributors and users) license. If your project is on GitHub, the GitHub Terms of Service make "inbound=outbound" the [explicit default](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license). +Probably not. For the vast majority of open source projects, an open source license implicitly serves as both the inbound (from contributors) and outbound (to other contributors and users) license. If your project is on GitHub, the GitHub Terms of Service make "inbound=outbound" the [explicit default](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license). An additional contributor agreement -- often called a Contributor License Agreement (CLA) -- can create administrative work for project maintainers. How much work an agreement adds depends on the project and implementation. A simple agreement might require that contributors confirm, with a click, that they have the rights necessary to contribute under the project open source license. A more complicated agreement might require legal review and sign-off from contributors' employers. @@ -112,7 +112,8 @@ Also, by adding "paperwork" that some believe is unnecessary, hard to understand Some situations where you may want to consider an additional contributor agreement for your project include: -* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement. For some projects, a [Developer Certificate of Origin](https://github.com/probot/dco) can be an alternative. +* Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement. +* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco). * Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0. * Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement. * You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes. @@ -152,7 +153,7 @@ Longer term, your legal team can do more to help the company get more from its i * **What to release:** [(Almost) everything?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) If your legal team understands and is invested in your company's open source strategy, they'll be best able to help rather than hinder your efforts. -* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linux.com/blog/why-companies-use-open-source-need-compliance-program) can prevent headaches, product delays, and lawsuits. +* **Compliance:** Even if your company doesn't release any open source projects, it uses others' open source software. [Awareness and process](https://www.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits. @@ -49,7 +42,7 @@ By comparison, a closed source process would be going to a restaurant and orderi * **Collaboration:** Open source projects can accept changes from anybody in the world. [Exercism](https://github.com/exercism/), for example, is a programming exercise platform with over 350 contributors. -* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md). +* **Adoption and remixing:** Open source projects can be used by anyone for nearly any purpose. People can even use it to build other things. [WordPress](https://github.com/WordPress), for example, started as a fork of an existing project called [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md). * **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt). @@ -85,7 +78,7 @@ If your only goal is to show off your work, you may not even want contributions,
At some point I created a custom UIAlertView that I was using...and I decided to make it open source. So I modified it to be more dynamic and uploaded it to GitHub. I also wrote my first documentation explaining to other developers how to use it on their projects. Probably nobody ever used it because it was a simple project but I was feeling good about my contribution.
-— @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576#.zhwo5krlq) +— @mavris, ["Self-taught Software Developers: Why Open Source is important to us"](https://medium.com/rocknnull/self-taught-software-engineers-why-open-source-is-important-to-us-fe2a3473a576)
@@ -101,7 +94,7 @@ If you need a dedicated budget or staffing for promotion, operations and maintai
As you begin to open source the project, it's important to make sure that your management processes take into consideration the contributions and abilities of the community around your project. Don't be afraid to involve contributors who are not employed in your business in key aspects of the project — especially if they are frequent contributors.
-— @captainsafia, ["So you wanna open source a project, eh?"](https://writing.safia.rocks/2016/12/06/so-you-wanna-open-source-a-project-eh/) +— @captainsafia, ["So you wanna open source a project, eh?"](https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779)
@@ -156,16 +149,16 @@ In your README, try to answer the following questions: You can use your README to answer other questions, like how you handle contributions, what the goals of the project are, and information about licenses and attribution. If you don't want to accept contributions, or your project is not yet ready for production, write this information down. Sometimes, people avoid writing a README because they feel like the project is unfinished, or they don't want contributions. These are all very good reasons to write one. -For more inspiration, try using @18F's ["Making READMEs Readable"](https://pages.18f.gov/open-source-guide/making-readmes-readable/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) to write a complete README. +For more inspiration, try using @dguo's ["Make a README" guide](https://www.makeareadme.com/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) to write a complete README. When you include a README file in the root directory, GitHub will automatically display it on the repository homepage. @@ -185,7 +178,7 @@ In addition to technical details, a CONTRIBUTING file is an opportunity to commu Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate. -For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) with: +For example, [Active Admin](https://github.com/activeadmin/activeadmin/) starts [its contributing guide](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) with: > First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool. @@ -193,7 +186,7 @@ In the earliest stages of your project, your CONTRIBUTING file can be simple. Yo Over time, you might add other frequently asked questions to your CONTRIBUTING file. Writing down this information means fewer people will ask you the same questions over and over again. -For more help with writing your CONTRIBUTING file, check out @nayafia's [contributing guide template](https://github.com/nayafia/contributing-template/blob/master/CONTRIBUTING-template.md) or @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/). +For more help with writing your CONTRIBUTING file, check out @nayafia's [contributing guide template](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) or @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/). Link to your CONTRIBUTING file from your README, so more people see it. If you [place the CONTRIBUTING file in your project's repository](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub will automatically link to your file when a contributor creates an issue or opens a pull request. @@ -205,7 +198,7 @@ Link to your CONTRIBUTING file from your README, so more people see it. If you [
We’ve all had experiences where we faced what was probably abuse either as a maintainer trying to explain why something had to be a certain way, or as a user...asking a simple question. (...) A code of conduct becomes an easily referenced and linkable document that indicates that your team takes constructive discourse very seriously.
-— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f#.v4qhl7t7v) +— @mlynch, ["Making Open Source a Happier Place"](https://medium.com/ionic-and-the-mobile-web/making-open-source-a-happier-place-3b90d254f5f)
@@ -215,7 +208,7 @@ For more information, check out our [Code of Conduct guide](../code-of-conduct/) In addition to communicating _how_ you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs. -Much like open source licenses, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](http://contributor-covenant.org/adopters/), including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary. +Much like open source licenses, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters), including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary. Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the file in your project's root directory so it's easy to find, and link to it from your README. @@ -256,13 +249,13 @@ Whether it's official documentation or a casual email, your writing style is par
I tried to be involved with every thread on the mailing list, and showing exemplary behaviour, being nice to people, taking their issues seriously and trying to be helpful overall. After a while, people stuck around not to only ask questions, but to help with the answering as well, and to my complete delight, they mimicked my style.
-— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](http://writing.jan.io/2015/11/20/sustainable-open-source.html) +— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source"](https://writing.jan.io/2015/11/20/sustainable-open-source.html)
Using warm, inclusive language (such as "them", even when referring to the single person) can go a long way in making your project feel welcoming to new contributors. Stick to simple language, as many of your readers may not be native English speakers. -Beyond how you write words, your coding style may also become part of your project's brand. [Angular](https://github.com/johnpapa/angular-styleguide) and [jQuery](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines. +Beyond how you write words, your coding style may also become part of your project's brand. [Angular](https://angular.io/guide/styleguide) and [jQuery](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines. It isn't necessary to write a style guide for your project when you're just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see. diff --git a/_articles/ta/best-practices.md b/_articles/ta/best-practices.md new file mode 100644 index 0000000000000000000000000000000000000000..1bed55f9bbf20485a79bb2ba3fefa1d40d90d34f --- /dev/null +++ b/_articles/ta/best-practices.md @@ -0,0 +1,276 @@ +--- +lang: ta +title: பராமரிப்பாளர்களுக்கான சிறந்த நடைமுறைகள் +description: திறந்த மூல பராமரிப்பாளராக உங்கள் வாழ்க்கையை எளிதாக்குவது, உங்கள் சமூகத்தை செயல்படுத்துவதற்கான செயல்முறைகளை ஆவணப்படுத்துதல். +class: best-practices +order: 5 +image: /assets/images/cards/best-practices.png +related: + - metrics + - leadership +--- + +## ஒரு பராமரிப்பாளராக இருப்பது எதை அர்த்தப்படுத்துகிறது? + +நிறைய மக்கள் பயன்படுத்தும் திறந்த மூல திட்டத்தை நீங்கள் பராமரித்தால், நீங்கள் குறைவாக குறியிடுவதையும் சிக்கல்களுக்கு அதிகமாக பதிலளிப்பதையும் கவனித்திருக்கலாம். + +ஒரு திட்டத்தின் ஆரம்ப கட்டங்களில், நீங்கள் புதிய கருத்துக்களை பரிசோதித்து, நீங்கள் விரும்பியவற்றை அடிப்படையாக கொண்ட முடிவுகளை எடுப்பீர்கள். உங்கள் திட்டம் பிரபலமடையும்போது, உங்கள் பயனர் மற்றும் பங்களிப்பாளர்களுடன் மேலும் நீங்கள் வேலை செய்வீர்கள். + +ஒரு திட்டத்தை பராமரிக்க, நிரலாக்கத்தை விட அதிக ஈடுபாடு வேண்டும். இந்த பணிகள் பெரும்பாலும் எதிர்பாராதவை, ஆனால் அவை வளரும் திட்டத்திற்கு முக்கியம். செயல்முறைகளை ஆவணப்படுத்துவதிலிருந்து சமூகத்தை மேம்படுத்துவதுவரை, சில எளிய வழிமுறைகளை நாங்கள் சேகரித்துள்ளோம். + +## உங்கள் செயல்முறைகளை ஆவணப்படுத்துதல் + +ஆவணப்படுத்துதல், ஒரு பராமரிப்பாளராக நீங்கள் செய்ய வேண்டிய முக்கிய கடமையாகும். + +ஆவணம் உங்கள் சொந்த சிந்தனையை தெளிவுபடுத்துவதோடு மட்டுமல்லாமல், உங்களுடைய தேவை அல்லது எதிர்பார்ப்பை அடுத்தவர்கள் கேட்கும்முன் சொல்ல உதவுகிறது. + +உங்கள் நோக்குடன் ஏதாவது பொருந்தாதபோது, இல்லை என்று சொல்வதை ஆவணப்படுத்துதல் எளிதாகிறது. அது மட்டுமல்லாமல் மற்றவர்கள் உதவி செய்ய முன்வரும்போது, இது அவர்களின் பணியை எளிமையாக்குகிறது. யார் உங்கள் திட்டத்தை வாசிப்பார்கள் அல்லது பயன்படுத்துகிறார்களோ என்பது உங்களுக்குத் தெரியாது. + +நீங்கள் முழு பத்திகளாக எழுதாவிட்டாலும், புல்லட் புள்ளிகளைக் கொண்டு எழுதுவது, எழுதாமல் இருப்பதைவிட மேலாகும். + +உங்கள் ஆவணங்களை புதுப்பித்த நிலையில் வைக்க நினைவில் கொள்ளுங்கள். நீங்கள் இதை எப்போதும் செய்ய இயலாவிட்டால், உங்கள் காலாவதியான ஆவணங்களை நீக்குங்கள் அல்லது காலாவதியானது என்பதைக் குறிப்பிடுக. அதனால் பங்களிப்பாளர்கள் புதுப்பிப்புகளுக்கு வரவேற்பு உள்ளதாக அறிவார்கள். + +### உங்கள் திட்டத்தின் பார்வையை எழுதுங்கள் + +உங்கள் திட்டத்தின் இலக்குகளை எழுதுவதன் மூலம் தொடங்கவும். அவற்றை உங்கள் README இல் சேர்க்கவும், அல்லது VISION எனப்படும் ஒரு தனி கோப்பை உருவாக்கவும். ஒரு செயல்திட்டத் திட்டத்தின் வழியே உதவக்கூடிய பிற கைவினைப்பொருட்கள் இருந்தால், அதை பொதுவெளியில் வைக்கவும். + +தெளிவான, ஆவணப்படுத்தப்பட்ட பார்வை உங்களின் கவனத்தை ஒருமுகபடுத்துவதோடு மற்றவர்களின் பங்களிப்புகளில் இருந்து "வரையெல்லை தொய்வை" தவிர்க்க உதவுகிறது. + +எடுத்துக்காட்டாக, @lord ஒரு திட்டத்தின் பார்வை கொண்டிருப்பதால், நேரம் செலவிட வேண்டிய கோரிக்கைகளை அவர் கண்டுபிடித்தார். ஒரு புதிய பராமரிப்பாளராக, [Slate](https://github.com/lord/slate) க்கு தனது முதல் அம்ச கோரிக்கை கிடைத்தபோது, அவர் தனது திட்டத்தின் நோக்குடன் ஒட்டவில்லை என்று வருத்தப்பட்டார். + + + +### உங்கள் எதிர்பார்ப்புகளை தெரிவிக்கவும் + +விதிகள் எழுதுவதற்கு கடினமாக இருக்கலாம். மற்றவர்களின் நடத்தைகளை நீங்கள் கண்காணிப்பதைப்போல சில நேரங்களில் நீங்கள் நினைக்கலாம். + +நன்கு எழுதப்பட்டு, செயல்படுத்தப்படும் விதிகள், பராமரிப்பவர்களுக்கு அதிகாரம் அளிக்கிறது. நீங்கள் செய்ய விரும்பாத விஷயங்களைச் செய்வதில் இழுக்கப்படுவதை அவர்கள் தடுக்கிறார்கள். + +உங்கள் திட்டத்தைச் சந்திக்கும் பெரும்பான்மையானவர்கள் உங்களுக்கு அல்லது உங்களுடைய சூழ்நிலைகளை பற்றி எதுவும் தெரியாது. அவர்கள் வழக்கமாக பயன்படுத்துவதாலும், சார்ந்துஇருப்பதாலும், திட்டப்பணியில் நீங்கள் செய்யும் வேலைக்கு பணம் பெறுகிறீர்கள் என அவர்கள் எண்ணலாம். ஒருவேளை ஒரு கட்டத்தில் உங்கள் திட்டத்தில் நிறைய நேரம் போடலாம், ஆனால் இப்போது நீங்கள் ஒரு புதிய வேலை அல்லது குடும்ப அங்கத்தினருடன் ஓய்வில்லாமல் இருக்கலாம். + +இந்த அனைத்து நன்றாக இருக்கிறது! மற்றவர்கள் அதைப் பற்றி அறிந்திருப்பதை உறுதிப்படுத்தவும். + +உங்கள் திட்டத்தை பராமரிப்பது பகுதியாக அல்லது முற்றிலும் தன்னார்வமாக இருந்தால், நீங்கள் எவ்வளவு நேரம் செலவு செய்வீர்கள் என்பது பற்றி நேர்மையாக இருக்க வேண்டும். இந்த நேரமென்பது திட்டப்பணிக்கு தேவையான நேரமோ அல்லது நீங்கள் திட்டப்பணிக்காக எவ்வளவு நேரம் செலவிட வேண்டும் என்று மற்றவர்கள் விரும்பும் அளவிற்கு இணையாக இருக்கவேண்டுமென்பதில்லை. + +ஆவணப்படுத்த வேண்டிய முக்கிய விதிமுறைகளில் சில: + +* ஒரு பங்களிப்பு எவ்வாறு மதிப்பாய்வு செய்யப்படுகிறது மற்றும் ஏற்றுக்கொள்ளப்படுகிறது (_அவைகளுக்கு சோதனைகள் தேவையா? இடுவு வார்ப்புரு?_) +* நீங்கள் ஏற்கும் பங்களிப்பு வகைகள் (_உங்கள் குறியீட்டின் ஒரு பகுதியுடன் மட்டுமே உதவி வேண்டுமா?_) +* எப்பொழுது பின்தொடர்வது பொருத்தமாக இருக்கும் (_உதாரணமாக, "7 நாட்களுக்குள் ஒரு பராமரிப்பாளரின் பதிலை எதிர்பார்க்கலாம். அதற்குமேலும் எந்த பதிலும் இல்லாமலிருந்தால், பிரியில் எனக்கு செய்தி அனுப்பவும்."_) +* நீங்கள் திட்டத்தில் எவ்வளவு நேரம் செலவு செய்கிறீர்கள் (_உதாரணமாக, "இந்த திட்டத்தில் வாரத்திற்கு 5 மணிநேரம் மட்டுமே செலவிடுகிறோம்"_) + +[ஜெகில்](https://github.com/jekyll/jekyll/tree/master/docs), [கோகோபாட்ஸ்](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), மற்றும் [ஹோம்புருவ்](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) பராமரிப்பாளர்களுக்கும் பங்களிப்பாளர்களுக்கும் தரவின் விதிகள் கொண்ட பல திட்டங்களுக்கான உதாரணங்கள். + +### கருத்துப்பரிமாற்றத்தை பொதுவில் வைக்கவும் + +உங்கள் கருத்துப்பரிமாற்றத்தை ஆவணப்படுத்த மறக்காதீர்கள். முடிந்தவரை திட்டப்பணி குறித்த கருத்துப்பரிமாற்றங்களை பொதுவில் வைக்கவும். ஒரு அம்ச கோரிக்கையை அல்லது ஆதரவு தேவை பற்றி விவாதிக்க தனிப்பட்ட முறையில் உங்களைத் தொடர்பு கொள்ள முயற்சித்தால், ஒரு அஞ்சல் முகவரி அல்லது சிக்கல் தடமி போன்ற பொதுத் தொடர்புத் தலையீட்டை அவர்களை அமைதியாக வழிநடத்துகிறது. + +நீங்கள் மற்ற பராமரிப்பாளர்களுடன் சந்தித்தால், அல்லது தனிப்பட்ட முறையில் ஒரு பெரிய முடிவை எடுத்தால், உங்கள் உரையை இடுகையிடும் போதும், இந்த உரையாடல்களை பொதுவில் ஆவணப்படுத்துங்கள். + +அவ்வாறே, உங்கள் சமூகத்தில் சேருகின்ற எவருக்கும் பல வருடங்களாக இருக்கின்றவருக்கு கிடைத்த அதே தகவலை அணுக முடியும். + +## இல்லை என சொல்ல கற்றல் + +நீங்கள் விஷயங்களை எழுதிவிட்டீர்கள். பெரும்பாலும், எல்லோரும் உங்கள் ஆவணங்கள் படிக்க வேண்டும், ஆனால் உண்மையில், நீங்கள் இந்த அறிவு உள்ளது என்று மற்றவர்களுக்கு ஞாபகப்படுத்த வேண்டும். + +எவ்வாறாயினும், உங்கள் விதிகளை நடைமுறைப்படுத்த வேண்டிய அவசியம் ஏற்பட்டால், சூழ்நிலைகளைத் தனிமைப்படுத்த உதவுகிறது. + +இல்லை என்று சொல்வது எளிதானது இல்லை, ஆனால் _"உங்கள் பங்களிப்பு இந்த திட்டத்தின் அளவுகோல்களுடன் பொருந்தவில்லை"_ என்பது _"உங்கள் பங்களிப்பு எனக்கு பிடிக்கவில்லை"_ என்பதைவிட தனிப்பட்டமுறையில் இல்லாமல் உள்ளது. + +ஒரு பராமரிப்பாளராக இல்லை என கூறும் பல சூழ்நிலைகளை நீங்கள் எதிர்கொள்வீர்கள்: நோக்கம் பொருந்தாத அம்ச கோரிக்கைகள், ஒருவர் கலந்துரையாடலைத் தடம்புரள செய்தல், மற்றவர்களுக்கு தேவையற்ற வேலையைச் செய்வது. + +### உரையாடலை நட்புணர்வுடன் வைத்துக் கொள்ளுங்கள் + +இடுவு மற்றும் இழு கோரிக்கை வரிசை ஆகியவை இல்லை என சொல்ல வேண்டிய இடங்களில் முக்கியமானவையாகும். ஒரு திட்ட பராமரிப்பாளராக, நீங்கள் தவிர்க்க விரும்பாத பரிந்துரைகளை பெறுவீர்கள். + +பங்களிப்பு உங்கள் திட்டத்தின் நோக்கத்தை மாற்றுகிறது அல்லது உங்கள் பார்வைக்கு பொருந்தவில்லை. ஒருவேளை நல்ல யோசனை, ஆனால் செயல்படுத்துதலில் சரியின்மை. + +காரணம் எதுவாயினும், உங்கள் திட்டத்தின் தரத்தைச் சந்திக்காத பங்களிப்புகளை சமாளிப்பதற்கு இது சாத்தியமாகும். + +நீங்கள் ஏற்றுக்கொள்ள விரும்பாத பங்களிப்பைப் பெற்றால், உங்கள் முதல் பிரதிபலிப்பு அதை புறக்கணிக்கலாம் அல்லது நீங்கள் அதைப் பார்க்கவில்லை என்று பாசாங்கு செய்யலாம். அவ்வாறு செய்வது மற்றவரின் உணர்ச்சிகளை காயப்படுத்தி, உங்கள் சமூகத்தின் பிற முக்கிய பங்களிப்பாளர்களைத் தடுக்கலாம். + + + +நீங்கள் தேவையற்ற பங்களிப்பை மூடுவதற்காக வருத்தம் கொள்ள தேவையில்லை. காலப்போக்கில், உங்கள் திட்டத்தில் பதிலளிக்கப்படாத இடுவுகள் மற்றும் இழு கோரிக்கைகள் மனஅழுத்தத்தையும், அச்சுறுத்தலையும் அதிகரிக்கிறது. + +நீங்கள் ஏற்க விரும்பாத பங்களிப்புகளை உடனடியாக மூடிவிடுதல் நல்லது. உங்கள் திட்டத்தில் ஏற்கனவே வேலைகள் நிறைய இருந்தால், [திறம்பட சிக்கல்களை எவ்வாறு தீர்க்க முடியும்](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) @steveklabnik சொல்லும் சில பரிந்துரைகள். + +இரண்டாவதாக, பங்களிப்புகளை புறக்கணிப்பது உங்கள் சமூகத்திற்கு ஒரு எதிர்மறை சமிக்ஞையை அனுப்புகிறது. ஒரு திட்டத்திற்கு பங்களிப்பது அச்சுறுத்தலாக இருக்கலாம், குறிப்பாக ஒருவரின் முதல் முறை. நீங்கள் அவர்களின் பங்களிப்பை ஏற்றுக் கொள்ளாவிட்டாலும், அதன் பின்னால் உள்ள நபரிடம் ஒப்புக்கொள்வதோடு, அவர்களின் ஆர்வத்திற்கு நன்றி தெரிவிக்கவும். இது ஒரு பெரிய பாராட்டு! + +பங்களிப்பை ஏற்றுக்கொள்ள விரும்பவில்லை எனில்: + +* **நன்றி சொல்லுங்கள்** அவர்களின் பங்களிப்புக்காக +* **திட்டத்தின் வரம்பிற்குள் ஏன் இது பொருந்தாது** என்பதை விளக்கவும், முன்னேற்றத்துக்கான தெளிவான பரிந்துரைகளை வழங்கவும். பரிவுடன் அதே சமயம் உறுதியுடன் இருங்கள். +* **தொடர்புடைய ஆவணங்களுடன் இணையுங்கள்**, உங்களிடம் இருந்தால். நீங்கள் ஏற்றுக்கொள்ள விரும்பாத விடயங்களுக்கு மீண்டும் மீண்டும் கோரிக்கைகளை நீங்கள் கண்டால், தவிர்க்கவேண்டிய ஆவணத்தில் அவற்றைச் சேர்க்கவும். +* **கோரிக்கையை மூடவும்** + +நீங்கள் பதிலளிப்பதற்கு 1-2 க்கும் மேற்பட்ட வாக்கியங்கள் தேவையில்லை. உதாரணமாக, [செலரியின்](https://github.com/celery/celery/) ஒரு பயனரின் விண்டோஸ் தொடர்பான பிழை அறிக்கைக்கு, @berkerpeksag [மறு மொழி](https://github.com/celery/celery/issues/3383): + + + +இல்லை என கூறுவதற்கு அச்சமிருந்தால், நீங்கள் மட்டும் தனித்து இல்லை. @jessfraz [கூறுவதுபோல்](https://blog.jessfraz.com/post/the-art-of-closing/): + +> பல திறந்த மூல திட்டங்கள், மெசோஸ், குபெர்னிஸ், குரோமியம் ஆகியவற்றின் பராமரிப்பாளர்களிடம் நான் பேசியபோது, அவர்கள் அனைவருக்கும் நீங்கள் விரும்பாத இணைப்புகளை "இல்லை" என்று கூறுவது ஒரு பராமரிப்பாளரின் கடினமான பகுதிகளில் ஒன்று என்று ஓப்புக்கொண்டனர். + +ஒருவரின் பங்களிப்பை ஏற்றுக்கொள்ள விரும்பாதது பற்றி குற்றவுணர்வு கொள்ளவேண்டிய அவசியமில்லை. திறந்த மூலத்தின் முதல் விதி, @shykes [கூற்றுப்படி](https://twitter.com/solomonstre/status/715277134978113536) : _"இல்லை என்பது தற்காலிகம், ஆம் என்பது நிரந்தரம்."_ மற்றொரு நபரின் உற்சாகத்துடன் சமரசம் செய்வது ஒரு நல்ல விஷயம், ஒரு பங்களிப்பை நிராகரிப்பது என்பது பின்னால் உள்ள நபரை நிராகரிப்பது போலவே அல்ல. + +இறுதியில், ஒரு பங்களிப்பு போதுமானதாக இல்லையென்றால், அதை ஏற்றுக்கொள்வதற்கான எந்த கடமையும் இல்லை. உங்கள் திட்டத்தில் மக்கள் பங்களிக்கும் போது, தயவுசெய்து பதிலளிக்கவும், ஆனால் நீங்கள் உண்மையிலேயே நம்பும் மாற்றங்களை ஏற்கவும். இல்லை என அடிக்கடி சொல்வதால், அது எளிமையாகிறது. உண்மை. + +### செயல்திறனுடன் இருங்கள் + +முதல் இடத்தில் தேவையற்ற பங்களிப்புகளின் அளவு குறைக்க, உங்கள் பங்களிப்பு செயல்முறை உங்கள் பங்களிப்பு வழிகாட்டி பங்களிப்புகளை சமர்ப்பிக்கும் மற்றும் ஏற்றுக்கொள்வதையும் விளக்கவும். + +பல குறைந்த தரவரிசை பங்களிப்புகளைப் பெறுகிறீர்கள் என்றால், பங்களிப்பாளர்கள் பணிபுரியும் பணி செய்யும்முன் செய்யவேண்டியவைகளில் சில உள்ளன. உதாரணமாக: + +* ஒரு இடுவு அல்லது இழு கோரிக்கை வார்ப்புரு/பட்டியல் நிரப்புக +* ஒரு இழு கோரிக்கை சமர்ப்பிக்கும் முன் ஒரு இடுவு திறக்கவும் + +அவர்கள் உங்கள் விதிகள் பின்பற்றவில்லை என்றால், உடனடியாக இடுவை மூடிவிட்டு உங்கள் ஆவணத்தை சுட்டிக்காட்டவும். + +இந்த அணுகுமுறை முதலில் தவறாக உணரக்கூடும் என்றாலும், இரு கட்சிகளுக்கும் நன்மை பயக்கும். நீங்கள் ஏற்கெனவே பல மணிநேரம் வீணடிக்கப்பட்ட வேலைகளில் ஒருவரை இழுக்க வேண்டுமென்ற வாய்ப்பு குறைகிறது. அது உங்கள் பணிச்சுமையை எளிதாக நிர்வகிக்க உதவுகிறது. + + + +சில நேரங்களில், நீங்கள் இல்லை என சொல்லும்போது, உங்கள் பங்களிப்பாளருக்கு வருத்தமளிக்கலாம் அல்லது உங்கள் முடிவை விமர்சிக்கலாம். அவர்களின் நடத்தை விரோதமானது என்றால், [நிலைமையைத் தணிப்பதற்கான நடவடிக்கைகளை எடுக்கவும்](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) அல்லது ஆக்கபூர்வமாக ஒத்துழைக்க தயாராக இல்லை என்றால் அவர்களை உங்கள் சமூகத்திலிருந்து நீக்கவும். + +### வழிகாட்டுதலை அரவணையுங்கள் + +ஒருவேளை உங்கள் சமூகத்தில் உள்ளவர்கள் உங்கள் திட்டத்தின் தரத்தைச் சந்திக்காத பங்களிப்பைச் சமர்ப்பிக்கலாம். நிரந்தரமாக நிராகரிக்கப்படுவதன் மூலம் இரு கட்சிகளுக்கும் ஏமாற்றமளிக்கலாம். + +உங்கள் திட்டத்தை யாராவது ஆர்வத்துடன் பார்க்கிறார்களோ, ஆனால் சிறிது மெருகூற்றல் தேவைப்படுவதால், பொறுமையாக இருங்கள். ஒவ்வொரு சூழ்நிலையிலும் அவர்களின் பங்களிப்புகள் திட்டத்தின் எதிர்பார்ப்புகளை ஏன் பூர்த்தி செய்யவில்லை என்பதை தெளிவாக விளக்குங்கள். எளிமையான அல்லது குறைவான தெளிவற்ற பணியை சுட்டிக்காட்டும் முயற்சியில், "நல்ல முதல் பிழை" என்ற பெயரில், அவர்களுக்கு நல்ல தொடக்கத்தை ஊக்கப்படுத்தவேண்டும். உங்களிடம் நேரம் இருந்தால், அவர்கள் முதல் பங்களிப்பு மூலம் அவர்களை வழிகாட்டுதல், அல்லது உங்கள் சமூகத்தில் வழிகாட்ட வேறு யாரையேனும் ஒருவரை கண்டுபிடியுங்கள். + +## உங்கள் சமூகத்தை ஊக்குவிக்கவும் + +நீங்களே எல்லாவற்றையும் செய்ய வேண்டியதில்லை. உங்கள் திட்டத்தின் சமூகம் ஒரு காரணத்திற்காக உள்ளது! செயல்படும் பங்களிப்பாளர்களைக் கொண்டிராவிட்டாலும் கூட, நிறைய பயனர்கள் இருந்தால், அவர்களை கொண்டு வேலை செய்யுங்கள். + +### பணிச்சுமையை பகிர்ந்து கொள்ளுங்கள் + +நீங்கள் அடுத்தவர்கள் பங்களிக்க விரும்பினால், அவர்களிடம் உதவியை கேட்கவும். + +புதிய பங்களிப்பாளர்கள் மீண்டும் மீண்டும் பங்களிப்பதை நீங்கள் காணும்போது, அதிக பொறுப்புகளை வழங்குவதன் மூலம் அவர்களின் வேலைகளை அங்கீகரியுங்கள். மற்றவர்கள் தலைமைத்துவ பாத்திரங்களாக வர விரும்பினால், எவ்வாறு வளரலாம் என்பதை ஆவணப்படுத்தவும். + +[திட்டப்பணியின் முதலாளுமையை பகிர](../building-community/#share-ownership-of-your-project) அடுத்தவர்களை ஊக்கப்படுத்துவத்தின் மூலம் உங்கள் சொந்த பணிச்சுமையை பெரிதும் குறைக்க முடியும், என @lmccart தனது திட்டப்பணியில் கண்டறிந்தார், [p5.js](https://github.com/processing/p5.js?files=1). + + + +நீங்கள் உங்கள் திட்டத்திலிருந்து தற்காலிகமாகவோ அல்லது நிரந்தரமாக விலக வேண்டியிருந்தால், வேறு யாரிடமேனும் உங்கள் திட்டத்தை எடுத்துக்கொள்ளுமாறு கேட்டுக்கொள்வதில் எந்த வருத்தமும் கொள்ள தேவையில்லை. + +மற்றவர்கள் அதன் திசையைப் பற்றி ஆர்வத்துடன் இருந்தால், அவர்களுக்கு அணுகல் வழங்க அல்லது அதிகாரப்பூர்வமாக மற்றவர்களிடம் கட்டுப்பாட்டை ஒப்படைக்கவும். யாராவது உங்கள் திட்டத்தின் கிளையை, வேறு எங்காவது பராமரித்து வந்தால், உங்கள் அசல் திட்டத்திடமிருந்து பிணைப்பை இணைக்கவும். பல மக்கள் உங்கள் திட்டம் வாழ வேண்டும் என எண்ணுவது பெரிய விஷயம்! + +@progrium திட்டத்தின் நோக்கை ஆவணப்படுத்திருந்ததால், அவர் திட்டத்தில் இருந்து விலகி பின்னர் கூட [Dokku](https://github.com/dokku/dokku) அந்த இலக்குகளை வாழ உதவியது என [கண்டறிந்தார்](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) + +> நான் விரும்பியதை விவரிக்கும் ஒரு விக்கி பக்கத்தையும் நான் ஏன் விரும்பினேன் என்றும் எழுதினேன். சில காரணங்களால், பராமரிப்பாளர்கள் அந்த திசையில் திட்டத்தை நகர்த்தியதில் எனக்கு ஆச்சரியமாக இருந்தது! அது நான் நகர்த்துவதை போல இருந்ததா? எல்லா நேரத்திலும் இல்லை. ஆனால் நான் எழுதியதை நோக்கி திட்டத்தை கொண்டு சென்றது. + +### மற்றவர்களுக்குத் தேவையான தீர்வுகளை உருவாக்கவும் + +உங்களுடைய திட்டம் என்ன செய்ய வேண்டும் என்பதைப் பொறுத்து ஒரு பங்களிப்பாளருக்கு வித்தியாசமான அபிப்ராயம் இருந்தால், அவர்கள் தங்கள் சொந்த கிளையில் வேலை செய்ய மெதுவாக ஊக்குவிக்க வேண்டும். + +ஒரு திட்டத்தை நகலெடுப்பது ஒரு கெட்ட காரியம் அல்ல. திட்டங்களை நகலெடுத்து மாற்றியமைப்பது திறந்த மூலத்தில் உள்ள விஷயங்களில் ஒன்றாகும். உங்கள் சமூக உறுப்பினர்கள் தங்கள் சொந்த கிளையில் வேலை செய்ய ஊக்குவிப்பார்கள், உங்கள் திட்டத்தின் பார்வைக்கு முரணாக இல்லாமல், அவர்கள் தேவைப்படும் படைப்புக்கு வெளிச் செல்லும் வழியை வழங்க முடியும். + + + +அதேபோல், இது உங்களுக்கு அலைக்கற்றை இல்லாத பொழுது உங்கள் தீர்வை உண்மையில் விரும்பும் ஒரு பயனருக்கு இது பொருந்தும். APIகள் மற்றும் தனிப்பயனாக்குதல் கொக்கிகள் வழங்குவதன் மூலம், மற்றவர்கள் தங்கள் சொந்த தேவைகளை பூர்த்தி செய்ய முடியும், மூலத்தை நேரடியாக மாற்றியமைக்க முடியாது. கோகோபாட்களுக்கான கூடுதல் ஊக்குவிப்புகளை "மிகவும் சுவாரஸ்யமான சில கருத்துக்களுக்கு" வழிவகுத்தது என்று @orta [கண்டறிந்தார்](https://artsy.github.io/blog/2016/07/03/handling-big-projects/): + +> ஒரு திட்டம் பெரியதாகிவிட்டால், அவை புதிய குறியீட்டை அறிமுகப்படுத்துவது பற்றி மிகவும் பழமைவாதமாக இருக்க வேண்டும் என்பது கிட்டத்தட்ட தவிர்க்க முடியாதது. நீங்கள் "இல்லை" என்று சொல்வது நல்லது, ஆனால் நிறைய பேர் சட்டப்பூர்வ தேவைகளை கொண்டிருக்கிறார்கள். எனவே, அதற்கு பதிலாக நீங்கள் ஒரு கருவியாக உங்கள் மேடையாக மாற்ற முடிகிறது. + +## தானியங்கு பொறிகளை கொண்டு வாருங்கள் + +மற்றவர்கள் உங்களுக்கு உதவக்கூடிய பணிகளைச் செய்வது போலவே, எந்தவொரு மனிதனும் செய்ய வேண்டாத பணிகளும் உள்ளன. தானியங்கு பொறிகள் உங்கள் நண்பர்களே. ஒரு பராமரிப்பாளராக உங்கள் வாழ்வை எளிதாக்குவதற்கு அவற்றைப் பயன்படுத்துங்கள். + +### உங்கள் குறியீட்டின் தரத்தை மேம்படுத்துவதற்கு சோதனைகள் மற்றும் பிற சரிபார்ப்பு முறைகள் தேவை + +சோதனைகளை சேர்ப்பதன் மூலம் நீங்கள் உங்கள் திட்டத்தை தானியங்க செய்யக்கூடிய மிக முக்கியமான வழிகளில் ஒன்றாகும். + +சோதனைகள், பங்களிப்பாளர்களுக்கு அவர்கள் எதையும் உடைக்க மாட்டார்கள் என்று நம்பிக்கையை தருகிறது. விரைவாக பங்களிப்புகளை மதிப்பாய்வு செய்து ஏற்றுக்கொள்வதற்கும் அவை எளிதாக்குகின்றன. நீங்கள் துரிதமாக பதிலளிக்கிறீர்கள் என்றால், உங்கள் சமுதாயத்தை இன்னும் அதிகமாக ஈடுபடுத்தலாம். + +அனைத்து எதிர்வரும் பங்களிப்புகளை இயக்கும் தானியங்கு சோதனைகள் அமைக்கவும், உங்கள் சோதனைகளை எளிதில் பங்களிப்பவர்களால் இயக்க முடியும் என்பதை உறுதி செய்யவும். அனைத்து குறியீட்டு பங்களிப்புகளும் சமர்ப்பிக்கப்படுவதற்கு முன் உங்கள் சோதனைகளை கடக்க வேண்டும். எல்லா சமர்ப்பிப்புகளுக்குமான குறைந்தபட்ச தரமான தரத்தை அமைக்க உதவுவீர்கள். கிட்ஹப்-இல் [தேவைப்படும் நிலை சரிபார்ப்புக்கள்](https://help.github.com/articles/about-required-status-checks/) உங்கள் சோதனைகளை கடந்துசெல்லாமல் மாற்றம் எதுவும் சேர்க்கப்படாது என்பதை உறுதிப்படுத்த உதவுகிறது. + +நீங்கள் சோதனையைச் சேர்த்தால், உங்கள் பங்களிப்புக் கோப்பில் (CONTRIBUTING file) அவர்கள் எவ்வாறு வேலை செய்கின்றன என்பதை விளக்கிச் சொல்லுங்கள். + + + +### அடிப்படை பராமரிப்பு பணிகளை தானியங்குபடுத்துவதற்கு கருவிகளைப் பயன்படுத்துங்கள் + +ஒரு பிரபலமான திட்டத்தை பராமரிப்பது பற்றிய நற்செய்தி என்னவெனில் மற்ற பராமரிப்பாளர்கள் இதே போன்ற பிரச்சினைகளை எதிர்கொண்டு, அதற்காக ஒரு தீர்வை உருவாக்கினர். + +பராமரிப்பு பணியின் சில அம்சங்களை தானியங்குபடுத்துவதற்கு [பல்வேறு வகையான கருவிகள்](https://github.com/showcases/tools-for-open-source) உள்ளன. ஒரு சில உதாரணங்கள்: + +* [சொற்பொருள் வெளியீடு](https://github.com/semantic-release/semantic-release) உங்கள் வெளியீட்டை தானியங்குபடுத்துகிறது +* [குறிப்பிடு-செயலி](https://github.com/facebook/mention-bot) இழு கோரிக்கைகளுக்கு சாத்தியமான விமர்சகர்களை குறிப்பிடுகின்றது +* [இடர்](https://github.com/danger/danger) குறியீடு மதிப்பாய்வை தானியங்குபடுத்துவதற்கு உதவுகிறது + +பிழை அறிக்கைகள் மற்றும் பிற பொதுவான பங்களிப்புகளுக்கு, கித்ஹப்-இல் உள்ள [சிக்கல் வார்ப்புருக்கள் மற்றும் இழு கோரிக்கை சிக்கல் வார்ப்புருக்கள்](https://github.com/blog/2111-issue-and-pull-request-templates), நீங்கள் பெறும் தகவலை தடையின்றிப் பெருவதற்கு உதவும். @TalAter உங்கள் சிக்கல் மற்றும் PR வார்ப்புருக்கள் எழுதுவதற்கு உதவுவதற்கு [உங்கள் சொந்த சாதனை வழிகாட்டியைத் தேர்வுசெய்யவும்](https://www.talater.com/open-source-templates/#/) உருவாக்கினார். + +உங்கள் மின்னஞ்சல் அறிவிப்புகளை நிர்வகிக்க, [மின்னஞ்சல் வடிகட்டிகள்](https://github.com/blog/2203-email-updates-about-your-own-activity) மூலம் முன்னுரிமை கொடுத்து ஒழுங்குபடுத்தலாம். + +நீங்கள் இன்னும் சிறிது மேம்பட்ட பெற விரும்பினால், பாணி வழிகாட்டிகள் மற்றும் பிசிரிழை மூலம் திட்ட பங்களிப்புகளை தரப்படுத்தி அவற்றை ஆய்வு மற்றும் ஏற்க எளிதாக செய்ய முடியும். + +இருப்பினும், உங்கள் தரவுகள் மிக சிக்கலானதாக இருந்தால், அவர்கள் பங்களிப்புக்கு தடைகளை அதிகரிக்க முடியும். நீங்கள் எல்லோருடைய வாழ்க்கையையும் எளிதாக்கிக்கொள்ள போதுமான விதிகள் மட்டுமே சேர்க்கிறீர்கள் என்பதை உறுதிப்படுத்தவும். + +எந்த கருவிகளைப் பயன்படுத்துவது என்பது உங்களுக்குத் தெரியாவிட்டால், பிற பிரபலமான திட்டங்கள், குறிப்பாக உங்கள் சுற்றுச்சூழலில் உள்ளவை என்ன என்பதைப் பாருங்கள். உதாரணமாக, பங்களிப்பு செயல்முறை பிற முனை தொகுதிகள் எவ்வாறு இருக்கும்? இதேபோன்ற கருவிகள் மற்றும் அணுகுமுறைகளைப் பயன்படுத்துவதன் மூலம் உங்கள் இலக்கு பங்களிப்பாளர்களுக்கு உங்கள் செயல்முறை நன்கு அறியப்படும். + +## இடைநிறுத்தம் எடுப்பது பரவாயில்லை + +திறந்த மூல வேலை உங்களுக்கு மகிழ்ச்சியைக் கொடுத்தது. ஒருவேளை இப்போது நீங்கள் தனிமை அல்லது குற்ற உணர்வு கொள்ளலாம். + +உங்கள் திட்டங்களைப் பற்றி நீங்கள் யோசித்துக்கொண்டிருக்கும்போது ஒருவேளை நீங்கள் கவலைகள் அல்லது அச்சம் வளர்வதாக உணரலாம். இதற்கிடையில், பிரச்சினைகள் மற்றும் கோரிக்கைகளை இழுக்கின்றன. + +வெளிப்படையான மூல வேலைகளில், குறிப்பாக பராமரிப்பாளர்களிடையே, தீய்வு என்பது ஒரு உண்மையான மற்றும் பரவலான பிரச்சினையாகும். ஒரு பராமரிப்பாளராக, உங்களுடைய மகிழ்ச்சி என்பது திறந்த மூல திட்டத்தின் உயிர் பிழைப்பதற்கான ஒரு நிபந்தனையற்ற தேவையாகும். + +சொல்வதற்கு அவசியமில்லை, ஒரு இடைவெளி எடுத்துக்கொள்ளுங்கள்! ஒரு விடுமுறை எடுக்க எரிந்தொழியும் வரை நீங்கள் காத்திருக்க வேண்டியதில்லை. @brettcannon, ஒரு பைதான் உள்ளக மேம்பாட்டாளர், 14 வருடங்கள் திறந்த மூல தன்னார்வ பணிக்கு பிறகு [ஒரு மாத கால விடுமுறை](https://snarky.ca/why-i-took-october-off-from-oss-volunteering/) எடுத்து கொள்ள முடிவு செய்தார். + +வேறு எந்த வகையிலான பணிமுறையையும் போல, வழக்கமான இடைவெளிகளை எடுத்துக் கொண்டால், நீங்கள் உங்கள் வேலையைப் புதுப்பித்து, மகிழ்ச்சியுடன், உற்சாகமாக வைத்திருப்பீர்கள். + + + +சில நேரங்களில், எல்லோருக்கும் உங்கள் அவசியம் தேவைப்படுவது போல் உணர்ந்தால் திறந்த மூல வேலைகளில் இருந்து இடைவேளி எடுப்பது கடினம். நீங்கள் விலகிச் செல்லவதால் மக்கள் உங்களை குற்றவாளியாக உணர முயற்சி செய்யலாம். + +நீங்கள் ஒரு திட்டத்தில் இருந்து விலகி நிற்கையில், உங்கள் பயனர்களுக்கும் சமூகத்திற்கும் ஆதரவைக் கண்டறிய உதவுங்கள். உங்களுக்குத் தேவையான ஆதரவைக் கண்டுபிடிக்க முடியவில்லை என்றால், எப்படியாவது ஒரு இடைவெளியை எடுங்கள். நீங்கள் கிடைக்காதபோது தொடர்புகொள்வதை உறுதிப்படுத்திக் கொள்ளுங்கள், எனவே உங்கள் மறுமொழியின்மை காரணமாக மக்கள் குழப்பமடைவதில்லை. + +இடைவெளிகளை எடுத்துக்கொள்வது வெறும் விடுமுறையை விட அதிகமாகும். நீங்கள் வார இறுதிகளில் திறந்த மூல வேலை செய்ய விரும்பவில்லை என்றால், அல்லது வேலை நேரங்களில், அந்த எதிர்பார்ப்புகளை மற்றவர்களுக்கு தெரிவிக்க வேண்டும், எனவே அவர்கள் உங்களை தொந்தரவு செய்யக்கூடாது என அறிவர். + +## உங்களை முதலில் கவனித்துக் கொள்ளுங்கள்! + +ஒரு பிரபலமான திட்டத்தை பராமரிப்பது, முந்தைய வளர்ச்சியை விட வேறுபட்ட திறமைகளுக்குத் தேவை, ஆனால் அது குறைவான நன்மதிப்பும் இல்லை. ஒரு பராமரிப்பாளராக, சிலர் மட்டுமே அனுபவப்படும் தலைமை மற்றும் தனிப்பட்ட திறமைகளை நீங்கள் பயிற்சி செய்வீர்கள். நிர்வகிப்பது எப்போதும் எளிதல்ல, தெளிவான எல்லைகளை அமைத்தல் மற்றும் நீங்கள் வசதியாக உள்ளதை மட்டும் எடுத்துக்கொள்வது, மகிழ்ச்சியாக, புத்துணர்ச்சியுடனும், பயனுள்ளதாகவும் இருக்க உதவும். diff --git a/_articles/ta/building-community.md b/_articles/ta/building-community.md new file mode 100644 index 0000000000000000000000000000000000000000..63a8127852cc55275617bb203a789c62a728c4d2 --- /dev/null +++ b/_articles/ta/building-community.md @@ -0,0 +1,275 @@ +--- +lang: ta +title: வரவேற்பு சமூகங்களை உருவாக்குதல் +description: உங்கள் திட்டத்தை மக்களுக்கு பயன்படுத்தவும், பங்களிக்கவும், ஊக்கப்படுத்தவும் ஒரு சமூகத்தை உருவாக்குங்கள். +class: building +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +--- + +## வெற்றிக்கு உங்கள் திட்டத்தை அமைத்தல் + +நீங்கள் உங்கள் திட்டத்தைத் தொடங்கினீர்கள், நீங்கள் வார்த்தை பரப்பி வருகிறீர்கள், அதை பார்க்கிறார்கள். அற்புதம்! இப்போது, அவர்களை எப்படிக் அருகாமையில் வைத்திருப்பது? + +ஒரு வரவேற்பு சமூகம் உங்கள் திட்டத்தின் வருங்கால மற்றும் புகழ் முதலீடு ஆகும். உங்கள் திட்டம் அதன் முதல் பங்களிப்பைப் பார்க்க ஆரம்பித்தால், ஆரம்ப பங்களிப்பாளர்களுக்கு ஒரு நேர்மறையான அனுபவத்தை வழங்குவதன் மூலம் தொடங்கவும், மேலும் அவர்கள் மீண்டும் வருவதை எளிதாக்கவும் செய்யுங்கள். + +### மக்கள் வரவேற்பை உணர வேண்டும் + +உங்கள் திட்டத்தின் சமூகத்தைப் பற்றி சிந்திக்க ஒரு வழி @MikeMcQuaid [பங்களிப்பாளர் வடிகுழலி](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/) என அழைக்கிறார்.: + + + +நீங்கள் உங்கள் சமூகத்தை உருவாக்கும்போது, வடிகுழலியின் (ஒரு சாத்தியமான பயனர்) ஒருவரை கோட்பாட்டளவில் கீழ்தளத்திற்கு (செயலூக்கமுள்ள பராமரிப்பாளராக) எப்படிக் கொண்டு வரலாம் என்று கருதுங்கள். பங்களிப்பவர் அனுபவத்தின் ஒவ்வொரு கட்டத்திலும் உராய்வுகளை குறைப்பதே உங்கள் குறிக்கோள். மக்கள் எளிதாக வெற்றி காணும்போது, அவர்கள் இன்னும் செய்ய ஊக்கமளிக்கும். + +உங்கள் ஆவணங்களுடன் தொடங்கவும்: + +* **உங்கள் திட்டத்தை யாரேனும் பயன்படுத்த எளிதாக செய்தல்.** [ஒரு தோழமையான README](../starting-a-project/#readme-எழுதுவது) மற்றும் தெளிவான குறியீடு எடுத்துக்காட்டுகள் உங்கள் திட்டத்தில் தொடங்குவதற்கு எவருக்கும் எளிதாக இருக்கும். +* [உங்களின் CONTRIBUTING கோப்பு](../starting-a-project/#உங்கள்-பங்களிப்பு-வழிமுறைகளை-எழுதுதல்) உங்கள் சிக்கல்களை புதுப்பித்த நிலையில் வைத்திருப்பதன் மூலம், **எப்படி பங்களிக்க வேண்டும் என்பதை தெளிவுபடுத்துங்கள்**. + +[கிட்ஹப் இன் 2017 திறந்த மூல கருத்தாய்வு](http://opensourcesurvey.org/2017/) மிகப்பெரிய பிரச்சனையாக முழுமையடையாத அல்லது குழப்பமான ஆவணமாக்கலைக் திறந்த மூல பயனர்களுக்கு உள்ளது என காட்டியது. நல்ல ஆவணங்கள் உங்கள் திட்டத்துடன் தொடர்புகொள்வதற்கு மக்களை வரவேற்கின்றது. இறுதியில், யாராவது ஒரு சிக்கலைத் அல்லது இழு கோரிக்கையை திறக்கலாம். இந்த பரஸ்பரங்களைப் பயன்படுத்தி அவற்றை வடிகுழலின் கீழ் வரை நகர்த்துவதற்கான வாய்ப்பாக பயன்படுத்தவும். + +* **உங்கள் திட்டத்தில் யாரேனும் புதியதாக தொடங்கினால், அவர்களுடைய ஆர்வத்திற்கு நன்றி சொல்லுங்கள்!** ஒரே ஒரு எதிர்மறை அனுபவமானது ஒருவரை மறுபடியும் திரும்பி வர விரும்பாமல் செய்துவிடும். +* **மறுமொழி கூறுங்கள்.** ஒரு மாதம் தங்கள் பிரச்சனைக்கு நீங்கள் பதிலளிக்கவில்லை என்றால் அவர்கள் ஏற்கனவே உங்கள் திட்டத்தை மறந்துவிட வாய்ப்புகள் உள்ளன. +* **நீங்கள் ஏற்றுக் கொள்ள வேண்டிய பங்களிப்புகளை பற்றி திறந்த மனதுடன் இருங்கள்.**பல பங்களிப்பாளர்கள் ஒரு பிழை அறிக்கை அல்லது சிறு பிழைத்திருத்தத்துடன் தொடங்குகின்றனர். ஒரு திட்டத்திற்கு [பங்களிக்க பல வழிகள் உள்ளன](../how-to-contribute/#பங்களிப்பதின்-அர்த்தம்-என்ன). மக்கள் எவ்வாறு உதவ விரும்புகிறார்களோ அவ்வாறே உதவட்டும். +* **நீங்கள் உடன்படாத ஒரு பங்களிப்பு இருந்தால்,** அவர்கள் கருத்திற்கு நன்றி தெரிவிக்கவும் [ஏன்](../best-practices/#இல்லை-என-சொல்ல-கற்றல்) இது திட்டத்தின் நோக்கத்திற்கு ஏன் பொருந்தவில்லை என, ஆவணத்துடன் (இருந்தால்) சுட்டிக்காட்டவும். + + + +பெரும்பாலான திறந்த மூல பங்களிப்பாளர்கள் "தற்காலிக பங்களிப்பாளர்கள்": ஒரு திட்டத்தில் பங்களித்தவர்கள் எப்போதாவது மட்டுமே. ஒரு சாதாரண பங்களிப்பாளருக்கு உங்கள் திட்டத்தின்போது வேகத்தை அதிகரிக்க நேரம் கிடைக்காமல் போகலாம், எனவே உங்கள் வேலையை எளிதில் பங்களிக்க உதவும். + +பிற பங்களிப்பாளர்களை உற்சாகப்படுத்துவது உங்களுக்கு ஒரு முதலீடு ஆகும். நீங்கள் உற்சாகமாக பணிபுரியும் உங்கள் பெரிய ரசிகர்களை அதிகப்படுத்தும்போது, எல்லாவற்றையும் நீங்களே செய்வதற்கான அழுத்தம் குறைகிறது. + +### அனைத்தையும் ஆவணப்படுத்துங்கள் + + + +நீங்கள் ஒரு புதிய திட்டத்தை தொடங்கும்போது, உங்கள் வேலையைத் தனிப்பட்ட முறையில் வைத்திருக்க இயலும். உங்கள் செயல்முறையை பொதுவில் ஆவணப்படுத்தும்போது, திறந்த மூல திட்டங்கள் செழித்தோங்கும். + +விடயங்களை எழுதும்போது, ஒவ்வொரு அடியிலும் அதிகமானவர்கள் பங்கேற்பார்கள். நீங்கள் உங்களுக்குத் தெரியாத ஒன்றில் உங்களுக்கு உதவி கிடைக்கலாம். + +விடயங்களை எழுதுவது வெறும் தொழில்நுட்ப ஆவணங்களை விட அதிகமானது. எந்த நேரத்திலும் உங்கள் திட்டத்தை விவாதித்து அல்லது தனிப்பட்ட முறையில் கலந்துரையாடுவது எப்போது வேண்டுமானாலும் நீங்கள் உணரலாம், அதை பொதுவெளியில் வைக்கலாமா என்று உங்களை நீங்களே கேளுங்கள். + +உங்கள் திட்டத்தின் திட்ட வரைபடம், நீங்கள் தேடுகிற பங்களிப்புகள், பங்களிப்புகளை மதிப்பாய்வு செய்தல் அல்லது நீங்கள் ஏன் சில முடிவுகளை எடுத்தீர்கள் என்பதை பற்றி வெளிப்படையாக இருங்கள். + +பல பயனர்கள் அதே சிக்கலில் இயங்குவதை நீங்கள் கண்டால், README இல் பதில்களை ஆவணப்படுத்தவும். + +சந்திப்புகளுக்கு, உங்கள் குறிப்புகள் அல்லது எடுத்துக்காட்டுகளை ஒரு பொருத்தமான விவகாரத்தில் வெளியிடுங்கள். வெளிப்படையான இந்த மட்டத்திலிருந்து நீங்கள் பெறும் பின்னூட்டம் உங்களுக்கு ஆச்சரியமாக இருக்கலாம். + +எல்லாவற்றையும் ஆவணப்படுத்துவது என்பது நீங்கள் செய்யும் வேலைக்கும் பொருந்தும். உங்கள் திட்டத்திற்கு ஒரு கணிசமான புதுப்பிப்பை நீங்கள் செய்திருந்தால், அதை ஒரு மிகுதிக் கோரிக்கையுடன் போட்டு, அதை பணி முன்னேற்றத்தில் (WIP) என்று குறிக்கவும். அந்த வழியில், பிற மக்கள் ஆரம்பத்தில் இருந்தே செயல்முறையில் ஈடுபட்டு உணர முடியும். + +### பதிலளிக்க வேண்டும் + +நீங்கள் [உங்கள் திட்டத்தை ஊக்குவிக்க](../finding-users), மக்கள் உங்களுக்கு கருத்து தெரிவிக்க வேண்டும். விஷயங்கள் எவ்வாறு வேலை செய்கின்றன என்பதைப் பற்றிய கேள்விகள் இருக்கலாம் அல்லது தொடங்குவதற்கு உதவி தேவைப்படலாம். + +யாராவது ஒரு சிக்கலைப் பதிவுசெய்தால், இழு கோரிக்கையை சமர்ப்பித்தால் அல்லது உங்கள் திட்டத்தைப் பற்றிய கேள்வியை கேட்டால், பதிலளிக்கும் முயற்சியை மேற்கொள்ளுங்கள். நீங்கள் விரைவாக பதிலளிக்கும்போது, அவர்கள் ஒரு உரையாடலின் பகுதியாக இருப்பதாக மக்கள் உணருவார்கள், மேலும் அவர்கள் பங்கு பெறுவதில் ஆர்வம் காட்டுவார்கள். + +நீங்கள் கோரிக்கையை உடனடியாக மதிப்பாய்வு செய்யாவிட்டாலும், ஆரம்பத்தில் அதை ஒப்புக் கொள்ளுதல் என்பது பங்களிப்பை அதிகரிக்க உதவுகிறது. [மிடில்மேன்](https://github.com/middleman/middleman/pull/1466) இழு கோரிக்கைக்கு @tdreyno இவ்வாறு பதிலளித்தார்: + + + +[ஒரு மோசில்லா ஆய்வு](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) 48 மணி நேரத்திற்குள் குறியீட்டு மதிப்பீடுகளைப் பெற்ற பங்களிப்பாளர்கள் மிக அதிகமான எண்ணிக்கையில் திரும்பினர் மற்றும் மீண்டும் பங்களிப்பு செய்தனர் என்று கண்டறிந்தது. + +உங்கள் திட்டத்தைப் பற்றிய உரையாடல்கள், இணையம் முழுவதும் பிற இடங்களில் ஸ்டேக் ஓவர்ஃப்ளோ, ட்விட்டர் அல்லது ரெடிட் போன்றவைகளில் நடக்கலாம். இந்த இடங்களில் சில அறிவிப்புகளை நீங்கள் அமைக்கலாம், எனவே யாராவது உங்கள் திட்டத்தை குறிப்பிடுகையில் விழிப்பூட்டப்படுவீர்கள். + +### உங்கள் சமுதாயத்தைக் ஒன்று திரட்ட ஒரு இடம் கொடுங்கள் + +உங்கள் சமுதாயத்தை ஒன்று சேர்ப்பதற்கான இடம் கொடுப்பதற்கு இரண்டு காரணங்களாகும். + +முதல் காரணம் அவர்களுக்காக. ஒருவருக்கொருவர் தெரிந்துகொள்ள உதவுங்கள். பொதுவான நலன்களைக் கொண்ட மக்கள் தவிர்க்கவியலாமல் அதைப் பற்றி பேச ஒரு இடம் வேண்டும். தொடர்பு பொதுவிலும் மற்றும் அணுகத்தக்க வகையிலும் இருக்கும் போது, எவராலும் முந்தைய காப்பகங்களை படித்து வேகமாக பங்கு பெற முடியும். + +இரண்டாவது காரணம் உங்களுக்காக. உங்கள் திட்டத்தைப் பற்றி பேசுவதற்கு பொது மக்களுக்கு பொதுவெளியில் இடம் கொடுக்கவில்லை என்றால், அவர்கள் உங்களை நேரடியாக தொடர்புகொள்வார்கள். தொடக்கத்தில், இது தனிப்பட்ட செய்திகளுக்கு பதிலளிக்கும் போது "இது ஒரு முறை" மட்டுமே என எளிதானதாக தோன்றலாம். ஆனால் காலப்போக்கில், குறிப்பாக உங்கள் திட்டம் பிரபலமாகி விட்டால், நீங்கள் சோர்வாக உணருவீர்கள். தனிப்பட்ட முறையில் உங்கள் திட்டத்தைப் பற்றி மக்களுடன் தொடர்பு கொள்வதற்கான தூண்டுதலை எதிர்க்கவும். அதற்கு பதிலாக, ஒரு நியமிக்கப்பட்ட பொது அலைத்தடத்திற்கு அவர்களை வழிநடத்துங்கள். + +உங்கள் வலைப்பதிவில் நேரடியாகவோ அல்லது கருத்து தெரிவிப்பதற்கோ பதிலளிப்பதற்குப் பதிலாக, மக்களை திறந்த சிக்கலுக்கு வழிகாட்டுவதைப்போல பொது தகவல்தொடர்பு மிகவும் எளிது. நீங்கள் ஒரு அஞ்சல் பட்டியலை அமைக்கலாம் அல்லது ஒரு ட்விட்டர் கணக்கை உருவாக்கலாம், ஸ்லாக் அல்லது ஐ.ஆர்.சி சேனல் உங்கள் திட்டத்தை பற்றி பேசுவதற்கு. அல்லது மேலே கூறிய அனைத்தையும் முயற்சி செய்யலாம்! + +[குபெர்னீஸ் காப்ஸ்](https://github.com/kubernetes/kops#getting-involved) சமுதாய உறுப்பினர்களுக்கு உதவ ஒவ்வொரு வாரமும் அலுவலக நேரங்களை ஒதுக்கி வைக்கிறது: + +> சமூகத்திற்கு உதவி மற்றும் வழிநடத்துதலை வழங்குவதற்காக ஒவ்வொரு வாரமும் காப்ஸ் நேரத்தை ஒதுக்கியுள்ளது. காப்ஸ் பராமரிப்பாளர்கள் குறிப்பாக புதிதாக பணிபுரியும் பணியாளர்களுடன் பணிபுரிவதற்கு அர்ப்பணிக்கப்பட்ட நேரத்தை ஒதுக்கி, PR களுக்கு உதவுவது, புதிய அம்சங்களைப் பற்றி கலந்துரையாட ஒப்புக் கொண்டனர். + +பொது தொடர்புக்கு குறிப்பிடத்தக்க விதிவிலக்குகள்: 1) பாதுகாப்பு பிரச்சினைகள் மற்றும் 2) உணர்ச்சிமிக்க நடத்தை நெறிமுறைகளின் கட்டு மீருகைகள். இந்த சிக்கல்களைத் தனிப்பட்ட முறையில் தெரிவிக்க மக்களுக்கு எப்போதும் ஒரு வழி இருக்க வேண்டும். நீங்கள் உங்கள் தனிப்பட்ட மின்னஞ்சல் பயன்படுத்த விரும்பவில்லை என்றால், ஒரு பிரத்யேக மின்னஞ்சல் முகவரியை அமைக்கலாம். + +## உங்கள் சமூகத்தை வளர்த்தல் + +சமூகங்கள் மிகவும் சக்திவாய்ந்தவை. அந்த சக்தி உங்களுக்கு ஆசீர்வாதமாகவோ சாபமாகவோ இருக்கலாம், அதை எவ்வாறு செயலாட்சி செய்கிறோம் என்பதைப் பொறுத்து. உங்கள் திட்டத்தின் சமூகம் வளரும் போது, கட்டுமானத்திற்கு ஒரு சக்தியாக உதவுவதற்கான வழிகளாக இருக்கும், அழிக்கும் வழியாக அல்ல. + +### தீங்கு விளைவிப்பவர்களை பொறுத்துக் கொள்ளாதீர்கள் + +எந்தவொரு பிரபலமான திட்டமும் தவிர்க்க முடியாமல் தீங்கு விளைவிக்கும் நபர்களை ஈர்க்கும். அவர்கள் தேவையற்ற விவாதங்களைத் தொடங்கலாம், அற்பமான அம்சங்கள் மீது விவாதிக்கலாம் அல்லது மற்றவர்களுக்கு தொல்லை தரலாம். + +இந்த வகையான மக்களிடம் சகிப்பின்மையை கடைப்பிடிப்பது சிறந்தது. இதை தடுக்காமல் விட்டுவிட்டால், எதிர்மறையான மக்கள் உங்கள் சமூகத்தில் பிறருக்கு சங்கடத்தை ஏற்படுத்தலாம். அவர்கள் விலக கூட நேரிடலாம். + + + +உங்கள் திட்டத்தின் அற்பமான அம்சங்களைப் பற்றிய வழக்கமான விவாதங்கள் முக்கியமான விஷயங்களில் கவனம் செலுத்துவதில் இருந்து நீங்கள் உட்பட, மற்றவர்களை திசை திருப்ப கூடியவை. உங்கள் திட்டத்திற்கு வரும் புதிய நபர்கள் இந்த உரையாடல்களைக் காணலாம் மற்றும் பங்கேற்க விரும்பாமல் போகலாம். + +உங்கள் திட்டத்தில் எதிர்மறையான நடத்தை நடக்கும்போது, அதை வெளிப்படையாக அழைக்கவும். ஒரு வகையான ஆனால் உறுதியான தொனியில், அவர்களின் நடத்தை ஏற்றுக்கொள்ளத்தக்கது அல்ல என விளக்கவும். பிரச்சனை தொடர்ந்தால், நீங்கள் [அவர்களை விலகி விடுமாறு கேளுங்கள்](../code-of-conduct/#உங்கள்-நடத்தை-விதித்-தொகுப்பை-செயல்படுத்ததுதல்). உங்கள் [நடத்தை குறியீடு](../code-of-conduct/) இந்த உரையாடல்களுக்கு ஒரு ஆக்கபூர்வமான வழிகாட்டியாக இருக்கலாம். + +### பங்களிப்பவர்கள் எங்கிருந்தாலும் அவர்களை சந்திக்கவும் + +உங்கள் சமூகம் வளரும் போது நல்ல ஆவணங்கள் மிக முக்கியமானதாக மாறும். உங்கள் திட்டத்தினை நன்கு அறிந்திருக்காத சாதாரண பங்களிப்பாளர்கள், அவர்களுக்கு தேவையான சூழலை விரைவாக பெற உங்கள் ஆவணங்களைப் படிக்கவும். + +உங்கள் பங்களிப்புக் (CONTRIBUTING) கோப்பில், புதிய பங்களிப்பாளர்களை எவ்வாறு தொடங்குவது என்பதைத் தெளிவாக வெளிப்படுத்துங்கள். இந்த நோக்கத்திற்காக நீங்கள் ஒரு பிரத்யேக பிரிவை உருவாக்க விரும்பலாம்.[Django](https://github.com/django/django), உதாரணமாக, புதிய பங்களிப்பாளர்களை வரவேற்க ஒரு சிறப்பு இறங்கும் பக்கம் வைத்துள்ளார். + + + +உங்கள் பிரச்சினை வரிசையில், பல்வேறு வகை பங்களிப்பாளர்களுக்கு பொருத்தமான பிழைகளுக்கு விவரத்துணுக்கு கொடுக்கவும்: உதாரணத்திற்கு, [_"முதல் முறை பங்களிப்பாளர்களுக்கு மட்டும்"_](https://kentcdodds.com/blog/first-timers-only), _"நல்ல முதல் பிழை"_, அல்லது _"ஆவணங்கள்"_. [இந்த விவரத்துணுக்குகள்](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) யாராவது உங்கள் திட்டத்திற்கு புதியவர்கள் விரைவாக உங்கள் பிரச்சினைகளை பார்பதற்கும், தொடங்குவதற்கும் எளிதாக்குகின்றன. + +கடைசியாக, ஒவ்வொரு அடியிலும் மக்கள் வரவேற்பைப் பெற உங்கள் ஆவணங்களைப் பயன்படுத்தவும். + +உங்கள் திட்டத்தில் உள்ள பெரும்பாலான மக்களுடன் நீங்கள் தொடர்பு கொள்ள மாட்டீர்கள். நீங்கள் பெறாத பங்களிப்புகள் இருக்கலாம், ஏனெனில் யாரோ ஒருவர் பயமுறுத்தப்பட்டார் அல்லது எங்கு தொடங்குவது என தெரியாமல் இருக்கலாம். உங்கள் திட்டத்தை இருந்து யாரேனும் விலகுவதை உங்களின் ஒரு சில கனிவான வார்த்தைகளால் தடுக்கலாம். + +உதாரணமாக, [ரூபினிஸ்](https://github.com/rubinius/rubinius/) இங்கே எப்படி [அதன் பங்களிப்பு வழிகாட்டியை](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md) தொடங்குகியது: + +> ரூபினியஸைப் பயன்படுத்துவதற்கு நன்றி தெரிவிப்பதன் மூலம் நாம் துவங்க வேண்டும். இந்த திட்டம் காதலால் உருவானது, மற்றும் பிழைகள் பிடிக்க, செயல்திறன் மேம்பாடுகள், மற்றும் ஆவணங்களை உதவி என்று அனைத்து பயனர்களையும் பாராட்டுகிறோம். ஒவ்வொரு பங்களிப்பும் அர்த்தமுள்ளது, எனவே பங்கு பெறுவதற்கு நன்றி. இதனால் கூறப்படுவதன் என்னவெனில், உங்களுடைய பிரச்சினையை வெற்றிகரமாக தீர்க்க நாங்கள் பின்பற்றும் சில வழிகாட்டு நெறிகள் நீங்கள் பின்பற்ற வேண்டும் . + +### Share ownership of your project + + + +உரிமையாளர்களாக உணர்கையில் மக்கள் திட்டங்களுக்கு பங்களிப்பதில் உற்சாகமாக உள்ளனர். நீங்கள் உங்கள் திட்டத்தின் பார்வையிலிருந்து விலக வேண்டும் அல்லது நீங்கள் விரும்பாத பங்களிப்பை ஏற்க வேண்டும் என்று அர்த்தமில்லை. ஆனால் நீங்கள் மற்றவர்களை கௌரவப்படுத்தும் பொழுது, அவர்கள் இன்னும் அதிகமாகக் பங்களிப்பார்கள். + +உங்கள் சமூகத்துடன் உரிமையை எவ்வளவு பகிர முடியுமோ அந்தளவு வழிகளை நீங்கள் கண்டுபிடிக்க முடியுமா என்பதைப் பார்க்கவும். சில யோசனைகள்: + +* **எளிதாக (அல்லாத முக்கிய) பிழைகளை சரிசெய்வதை எதிர்க்கவும்.** அதற்கு மாறாக, புதிய பங்களிப்பாளர்களைப் பணியமர்த்துவதற்கான வாய்ப்பாக அவற்றைப் பயன்படுத்துங்கள் அல்லது பங்களிக்க விரும்பும் ஒரு வழிகாட்டியாக இருக்க வேண்டும். இது முதலில் இயற்கைக்கு மாறானதாக தோன்றலாம், ஆனால் உங்கள் முதலீடு காலப்போக்கில் திரும்பிவிடும். உதாரணமாக, @michaeljoseph சிக்கலைக் குறைக்க, தானே சரிசெய்யாமல், ஒரு பங்களிப்பாளரிடம் [Cookiecutter](https://github.com/audreyr/cookiecutter) இழு கோரிக்கை எழுப்புமாறு கேட்டார். + + + +* [சினாட்ரா](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) போன்று உங்கள் திட்டத்தில் பங்களித்த அனைவருக்கும் **உங்கள் திட்டத்தில் ஒரு பங்களிப்பாளர்கள்(CONTRIBUTORS) அல்லது நூலாசிரியர்கள்(AUTHORS) கோப்பைத் தொடங்கவும்.** + +* உங்கள் சமூகம் பெரியதாயிருந்தால், **ஒரு செய்திமடலை முடிக்க அல்லது வலைப்பதிவு இடுகையை எழுதுவதன் முலம்** பங்களிப்பாளர்களுக்கு நன்றி சொல்லுங்கள். ரஸ்ட்-ன் [இந்த வாரம் ரஸ்ட்](https://this-week-in-rust.org/) மற்றும் ஹூடி-ன் [கூச்சலிடுங்கள்](http://hood.ie/blog/shoutouts-week-24.html) இரண்டு நல்ல உதாரணங்களாகும். + +* **ஒவ்வொரு பங்களிப்பாளரும் ஒப்பவிக்கும் அனுமதி தரவும்.** இது மக்களை [அவர்களின் இணைப்புகளை மெருகூட்டுவதற்கு மிகவும் உற்சாகமாக இருக்கிறது](https://felixge.de/2013/03/11/the-pull-request-hack.html)என்று @felixge கண்டறிந்தார், மேலும் அவர் சமீபத்தில் வேலை செய்யாத திட்டங்களில் கூட புதிய பராமரிப்பாளர்களைக் கண்டார். + +* உங்கள் திட்டம் கிட்ஹப் இல் இருந்தால், **உங்கள் திட்டத்தை உங்கள் தனிப்பட்ட கணக்கிலிருந்து ஒரு [அமைப்பாக](https://help.github.com/articles/creating-a-new-organization-account/)** மாற்றவும் மற்றும் குறைந்தது ஒரு காப்பு நிர்வாகியை சேர்க்கவும். வெளிப்புற ஒத்துழைப்பாளர்களுடன் திட்டங்களில் வேலை செய்வதை நிறுவனங்கள் எளிதாக்குகின்றன. + +உண்மை என்னவென்றால், [பெரும்பாலான திட்டங்களுக்கு](https://peerj.com/preprints/1233.pdf) பெரும்பாலான வேலைகள் செய்யக்கூடிய ஒன்று அல்லது இரண்டு பராமரிப்பாளர்கள் இருப்பர். பெரிய திட்டம், மற்றும் உங்கள் சமூகம் பெரியதாக இருப்பின், எளிதாக உதவியை கண்டுபிடிக்க முடியும். + +அழைப்பிற்கு பதில் தெரிவிக்க யாரும் இல்லை என்றாலும், ஒரு சமிக்ஞையைத் தட்டினால், மற்றவர்கள் அதில் கலந்துகொள்ளும் வாய்ப்புகளை அதிகரிக்கிறது. எவ்வளவு முந்தி நீங்கள் ஆரம்பிக்கிறீர்களோ, விரைவில் மக்களால் உதவ முடியும். + + + +## முரண்பாடுகளை தீர்த்தல் + +உங்கள் திட்டத்தின் ஆரம்ப கட்டங்களில், பெரிய முடிவுகளை எடுப்பது எளிதானது. நீங்கள் ஏதாவது செய்ய விரும்பினால், நீங்கள் அதை செய்யலாம். + +உங்கள் திட்டம் மிகவும் பிரபலமாகும்போது, நீங்கள் செய்யும் தீர்மானங்களில் ஆர்வம் அதிகரிக்கும். உங்களுக்கு ஒரு பெரிய பங்களிப்பாளர் சமூகம் இல்லையெனிலும், உங்கள் திட்டத்தில் நிறைய பயனர்கள் இருந்தால், முடிவுகளை எடுப்பதில் அல்லது தங்கள் சொந்த பிரச்சினைகளை எழுப்புவதில் உங்களை எடை போடலாம். + +பெரும்பாலும், நீங்கள் ஒரு நட்பு, மரியாதைக்குரிய சமூகம் பயிரிட்டால் மற்றும் உங்கள் செயல்முறைகளை வெளிப்படையாக ஆவணப்படுத்தியிருந்தால், உங்கள் சமூகம் தீர்மானத்தைக் கண்டறிய முடியும். ஆனால் சில நேரங்களில் ஒரு சில சிக்கல்களில் நீங்கள் உரையாட சிறிது கடினமான இருக்கலாம். + +### இரக்கத்திற்கு கோல் வைக்கவும் + +உங்கள் சமூகம் கடினமான சிக்கலைக் கொண்டுவருகையில், கோபம் அதிகரிக்கும். மக்கள் கோபமாக அல்லது விரக்தியடைந்து, ஒருவருக்கொருவர் அல்லது உங்களிடத்தில் கோபம் கொள்ளலாம். + +ஒரு பராமரிப்பாளராக உங்கள் வேலை இந்த சூழ்நிலைகளை அதிகரிக்காமல் பார்க்க வேண்டும். உங்களுக்கு ஒரு தலைப்பில் ஒரு வலுவான கருத்து இருந்தால் கூட, போராட்டத்தில் குதித்து விடாமல் அல்லது உங்கள் கருத்துக்களை தள்ளி விடாமல், ஒரு நடுவராக நிலையை எடுக்க முயற்சிக்கவும். யாரோ ஒருவர் கலகலப்பாகவோ அல்லது உரையாடலை ஏகபோகமாகவோ செய்தால், [உடனடியாக செயல்பட்டு](../building-community/#தீங்கு-விளைவிப்பவர்களை-பொறுத்துக்-கொள்ளாதீர்கள்) விவாதங்களை பொறுப்புள்ளதாக மற்றும் ஆக்கமிக்கதாக செய்யுங்கள். + + + +மற்றவர்கள் வழிநடத்துதலுக்காக உங்களைத் தேடுகிறார்கள். ஒரு நல்ல உதாரணம் அமையுங்கள். நீங்கள் இன்னமும் ஏமாற்றம், துயரத்தை அல்லது கவலையை வெளிப்படுத்தலாம், ஆனால் அமைதியாக செய்யலாம். + +உங்களை சாந்தமாக வைத்துக்கொள்வது எளிதானது அல்ல, ஆனால் உங்கள் சமூகத்தின் ஆரோக்கியத்தை மேம்படுத்துவது என்பது தலைமைத்துவத்தை நிரூபிக்கிறது. இணையம் நன்றி சொல்லும். + +### உங்கள் README ஐ ஒரு அரசியலமைப்பாக நடத்துங்கள் + +உங்கள் README [வழிமுறைகளின் தொகுப்பை விடவும் மேலானது](../starting-a-project/#readme-எழுதுவது). இது உங்கள் இலக்குகள், தயாரிப்பு பார்வை, மற்றும் திட்ட வரைபடங்களைப் பற்றி பேசுவதற்கான இடமாகும். ஒரு குறிப்பிட்ட அம்சத்தின் தகுதியைப் பற்றி விவாதிக்க மக்கள் கவனம் செலுத்தினால், அது உங்கள் README ஐ மறுபரிசீலனை செய்ய மற்றும் உங்கள் திட்டத்தின் உயர்ந்த பார்வை பற்றி பேச உதவும். உங்கள் README இல் கவனம் செலுத்துவது உரையாடலைப் பயன்படுத்துகிறது, எனவே நீங்கள் ஒரு ஆக்கபூர்வமான விவாதம் செய்யலாம். + +### பயணத்தின் மீது கவனம் செலுத்துங்கள், இலக்கு அல்ல + +சில திட்டங்கள் பெரிய முடிவுகளை எடுக்க வாக்களிக்கும் செயல்முறையைப் பயன்படுத்துகின்றன. முதல் பார்வையில் புத்திசாலித்தனமாக, வாக்களிப்பது ஒருவரது கவலையைப் பேசுவதற்கும், பேசுவதற்கும் பதிலாக "பதில்" பெறுவதை வலியுறுத்துகிறது. + +வாக்களிப்பு அரசியல் ரீதியாக மாறலாம், அங்கு சமூக உறுப்பினர்கள் ஒருவருக்கொருவர் உத்வேகம் கொடுப்பதாக அல்லது ஒரு குறிப்பிட்ட வழியில் வாக்களிக்க அழுத்தம் கொடுக்கின்றனர். உங்கள் சமூகத்தில் எல்லோரும் வாக்குகளிப்பது இல்லை, அது [அமைதி பெரும்பான்மை](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) உள்ளவர்கள் அல்லது ஒரு வாக்களிக்க தெரியாத தற்போதைய பயனர்கள் யாராயினும். + +சில நேரங்களில், வாக்களிப்பது அவசியமான ஒரு தேவையான சமநிலை முறிகை ஆகும். இருப்பினும், உங்களால் முடிந்த அளவுக்கு, ஒருமித்த கருத்தை விட ["சமரசம் தேடுவதை"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) வலியுறுத்துகின்றன. + +ஒரு கருத்தொன்றைத் தேடும் செயல்முறையின் கீழ், சமுதாய உறுப்பினர்கள் தாங்கள் போதுமான அளவு கேட்டிருப்பதை உணரும் வரை முக்கிய கவலைகளை விவாதிக்கின்றனர். சிறிய கவலை மட்டுமே இருக்கும் போது, சமூகம் முன்னோக்கி நகர்கிறது. ஒரு சமூகம் ஒரு சரியான பதிலை அடைய முடியாது என்பதை ஒப்புக்கொள்கிறது. அதற்கு பதிலாக, அதை கேட்பதற்கும் மற்றும் விவாதிப்பதற்கு முன்னுரிமை கொடுக்கவும். + + + +நீங்கள் ஒரு கருத்தொன்றைத் தேடும் நடைமுறையை உண்மையில் பின்பற்றவில்லை என்றால், ஒரு திட்ட பராமரிப்பாளராக, நீங்கள் கவனிப்பதை மக்கள் அறிந்திருப்பது அவசியம். மற்றவர்கள் கேட்டதை உணர்ந்து, தங்கள் கவலைகளை தீர்ப்பதில் ஈடுபடுவதால், சிக்கலான சூழ்நிலைகளைத் தூண்டுவதற்கு நீண்ட தூரம் செல்கிறது. பிறகு, உங்கள் வார்த்தைகளை செயல்களோடு பின்பற்றுங்கள். + +ஒரு தீர்மானம் எடுப்பதற்காக விரைந்து முடிவை எடுக்க வேண்டாம். எல்லோரும் கேட்டதை உணர்ந்து கொள்ளுங்கள் மற்றும் அனைத்துத் தகவலும் ஒரு தீர்மானம் நோக்கி நகரும் முன் பகிரங்கமாக்கப்பட்டுள்ளது. + +### உரையாடலை நடவடிக்கைகளில் கவனம் செலுத்துக + +கலந்துரையாடல் முக்கியம், ஆனால் உற்பத்தி மற்றும் ஆக்கபூர்வமற்ற உரையாடல்களுக்கு இடையே வேறுபாடு உள்ளது. + +விவாதத்திற்கு ஊக்கமளிக்கும் வரை அது தீவிரமாக தீர்மானம் நோக்கி நகரும். உரையாடலைத் தாமதப்படுத்துவது அல்லது புறப்படுவது என்பது தெளிவாக இருந்தால், தனிப்பட்டவர்கள், அல்லது சிறு விவரங்களைப் பற்றி மக்கள் குற்றம் சாட்டுகிறார்கள், அதை மூடுவதற்கான நேரம். + +இந்த உரையாடல்களைத் தொடர அனுமதிப்பது நடப்பிலுள்ள பிரச்சினைக்குத் தீமை மட்டுமல்ல, உங்கள் சமூகத்தின் ஆரோக்கியத்திற்கு மோசமானது. இந்த வகையான உரையாடல்கள் அனுமதிக்கப்படுவதையோ, ஊக்கப்படுத்தினாலும், அது எதிர்கால பிரச்சினைகளை எழுப்புவதையோ அல்லது தீர்ப்பதிலோ இருந்து மக்களை ஊக்கங்கெடுக்கலாம். + +உங்களுக்கோ மற்றவர்களுக்கோ எவ்விதமான குறிப்பையும் கொண்டு, உங்களைக் கேட்டுக்கொள்ளுங்கள், _"இது எப்படி ஒரு தீர்மானத்திற்கு நெருக்கமாக உள்ளது?"_ + +உரையாடலை அவிழ்க்கத் தொடங்கினால், குழுவைக் கேட்கவும் _"அடுத்தடுத்து எடுக்கும் நடவடிக்கை என்ன?"_ உரையாடலை மறுசீரமைக்க. + +ஒரு உரையாடல் தெளிவாக போகவில்லை என்றால், எடுக்கும் தெளிவான நடவடிக்கைகள் எதுவும் இல்லை, அல்லது அதற்கான நடவடிக்கை ஏற்கனவே எடுக்கப்பட்டு விட்டது, சிக்கலை மூடிவிட்டு நீங்கள் ஏன் மூடினீர்கள் என்பதை விளக்குங்கள். + + + +### உங்கள் போர்களை புத்திசாலித்தனமாக எடுக்கவும் + +சூழல் முக்கியமானது. கலந்துரையாடலில் யார் ஈடுபட்டு உள்ளனர், எப்படி அவர்கள் மற்ற சமூகத்தை பிரதிநிதித்துவப்படுத்துகிறார்கள் என்பதையும் கவனியுங்கள். + +சமுதாயத்தில் எல்லோரும் சோகமாக இருக்கிறார்களா, அல்லது இந்த பிரச்சினையுடன் கூட ஈடுபடுகிறார்களா? அல்லது ஒரு தனி தொந்தரவு? செயலில் உள்ள குரல்களை மட்டுமல்ல, உங்கள் அமைதியான சமூக உறுப்பினர்களைக் கருத்தில் கொள்ள மறக்காதீர்கள். + +உங்கள் சமூகத்தின் பரந்த தேவைகளை சிக்கல் பிரதிநிதித்துவப்படுத்தவில்லை என்றால், சிலருடைய கவலையை நீங்கள் ஒப்புக் கொள்ள வேண்டும். இது ஒரு தெளிவான தீர்மானம் இல்லாமல் தொடர்ச்சியான பிரச்சினை என்றால், தலைப்பில் முந்தைய விவாதங்களை சுட்டிக்காட்டவும் மற்றும் பிரியை மூட வேண்டும். + +### ஒரு சமூக சமநிலை முறிகையாளரை அடையாளம் காணுங்கள் + +ஒரு நல்ல அணுகுமுறை மற்றும் தெளிவான தகவல்தொடர்புடன், மிகக் கடினமான சூழ்நிலைகள் தீர்க்கத்தக்கவை. இருப்பினும், ஒரு செயல்திறன் கொண்ட உரையாடலில் கூட, எப்படி நடந்துகொள்வது என்பது பற்றி கருத்து வேறுபாடு இருக்கும். இந்த சந்தர்ப்பங்களில், ஒரு சமநிலை முறிகையாளராக இருக்க ஒரு தனிநபரோ அல்லது குழுவோ அடையாளம் காணுங்கள். + +ஒரு சமநிலை முறிகையாளராக திட்டத்தின் முதன்மை பராமரிப்பாளர் இருக்க முடியும், அல்லது இது வாக்களிக்கும் அடிப்படையில் ஒரு முடிவை எடுக்க மக்கள் ஒரு சிறிய குழு இருக்க முடியும். சமநிலை முறிகையாளரை பயன்படுத்தவதற்கு முன், அடையாளம் கண்டு செயல்முறையை ஆட்சி முறை (GOVERNANCE) கோப்பில் இணைக்கவேண்டும். + +உங்கள் சமநிலை முறிகையாளர் ஒரு கடைசி போக்கிடமாக இருக்க வேண்டும். உங்கள் சமூகம் வளரவும் கற்றுக்கொள்ளவும் பிளவுபடும் பிரச்சினைகள் ஒரு வாய்ப்பாகும். இந்த வாய்ப்புகளைத் தழுவி, முடிந்தவரை ஒரு தீர்மானத்திற்கு நகர்த்துவதற்கு ஒரு கூட்டு செயல்முறையைப் பயன்படுத்துங்கள். + +## சமூகமானது ❤️ திறந்த மூலம் + +ஆரோக்கியமான, வளரும் சமுதாயங்கள் ஒவ்வொரு வாரமும் ஆயிரக்கணக்கான மணி நேரம் திறந்த மூலத்திற்கு ஊற்றப்படுகின்றன. பல பங்களிப்பாளர்கள் மற்றவர்களிடம் திறந்த மூலத்தில் - வேலை செய்வதற்கான - அல்லது ஏன் வேலை செய்யவில்லை காரணத்தை சுட்டிக்காட்டுகின்றனர். ஆக்கபூர்வமாக அந்த ஆற்றலை எவ்வாறு தட்டச்சு செய்வது என்பதைக் கற்றுக்கொள்வதன் மூலம், யாரோ ஒருவருக்கு மறக்கமுடியாத திறந்த மூல அனுபவத்தை பெற நீங்கள் உதவுவீர்கள். diff --git a/_articles/ta/code-of-conduct.md b/_articles/ta/code-of-conduct.md new file mode 100644 index 0000000000000000000000000000000000000000..8b8f8c1b78c91e4d5e8edca941a03329be74c4ec --- /dev/null +++ b/_articles/ta/code-of-conduct.md @@ -0,0 +1,114 @@ +--- +lang: ta +title: உங்கள் நடத்தை விதி +description: நடத்தை நெறிமுறைகளை பின்பற்றுவதன் மூலம், ஆரோக்கியமான மற்றும் ஆக்கபூர்வமான சமூக நடத்தைக்கு உதவுதல். +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## எனக்கு எதற்கு ஒரு நடத்தை விதித் தொகுப்பு வேண்டும்? + +நடத்தை விதித் தொகுப்பு என்பது உங்கள் திட்டத்தின் பங்கேற்பாளர்களுக்கு நடத்தைக்கான எதிர்பார்ப்புகளை நிர்ணயிக்கும் ஆவணம். ஏற்றுக்கொள்வதும், நடைமுறைப்படுத்துவதும், உங்கள் சமூகத்திற்கான ஒரு நேர்மறையான சமூக சூழ்நிலையை உருவாக்க ஒரு நடத்தை விதித் தொகுப்பு உதவும். + +நடத்தை விதித் தொகுப்பு உங்கள் பங்கேற்பாளர்களை மட்டுமல்ல, உங்களையும் பாதுகாக்கும். நீங்கள் ஒரு திட்டத்தை பராமரித்து வந்தால், பிற பங்கேற்பாளர்களிடமிருந்து உற்பத்தியைப் பெறாத மனப்பான்மை, காலப்போக்கில் உங்கள் வேலையைப் பற்றி நீங்கள் வெறுமையாக அல்லது மகிழ்ச்சியற்றதாக உணரலாம். + +நடத்தை விதித் தொகுப்பு ஆரோக்கியமான, ஆக்கபூர்வமான சமூக நடத்தைக்கு உதவுகிறது. உங்கள் செயல்திட்டத்துடன் நீங்கள் அல்லது பிறர் சோர்வடைந்தால், நீங்கள் ஏற்றுக்கொள்ளாத ஒன்றை எவரேனும் செய்தால், நடவடிக்கை எடுக்க உதவுகிறது. + +## நடத்தை விதித் தொகுப்பு உருவாக்குதல் + +ஆரம்பத்தில் ஒரு நடத்தை விதித் தொகுப்பு உருவாக்க முயற்சிக்கவும்: இதனை நீங்கள் முதலில் உங்கள் திட்டத்தை உருவாக்கும் போது சிறந்தது. + +உங்கள் எதிர்பார்ப்புகளைத் தெரிவிப்பதோடு மட்டுமல்லாமல், ஒரு நடத்தை விதித் தொகுப்பு பின்வருமாறு விவரிக்கிறது: + +* நடத்தை விதித் தொகுப்பு நடைமுறைக்கு வந்தால் _(சிக்கல்களிலும் இழு கோரிக்கைகளிலும், அல்லது நிகழ்வுகள் போன்ற சமூக நடவடிக்கைகளிலோ மட்டுமே)_ +* யாரைப் பின்பற்றுகிறீர்கள் _(சமூக உறுப்பினர்கள் மற்றும் பராமரிப்பாளர்கள், ஆனால் ஆதரவாளர்கள்?)_ +* ஒருவர் நடத்தை விதிகளை மீறுவதால் என்ன நிகழும் +* ஒருவர் மீறல்களை எப்படி அறிவிக்க முடியும் + +நீங்கள் எங்கு வேண்டுமானாலும், முந்தைய உபாயத்தை பயன்படுத்தவும். [பங்களிப்பாளரின் உடன்படிக்கை](https://contributor-covenant.org/) என்பது ஒரு நடத்தை விதியாகும், இது குபெர்னீஸ், ரெயில்ஸ் மற்றும் ஸ்விஃப்ட் உள்ளிட்ட 40,000 திறந்த மூல திட்டங்களில் பயன்படுத்தப்படுகிறது. + +[Django நடத்தை விதித் தொகுப்பு](https://www.djangoproject.com/conduct/) மற்றும் [சிட்டிசன் நடத்தை விதித் தொகுப்பு](http://citizencodeofconduct.org/) நடத்தை விதித் தொகுப்புக்கான இரண்டு நல்ல உதாரணங்களாகும். + +உங்கள் திட்டத்தின் மூலம் கோப்பகத்தில் CODE_OF_CONDUCT கோப்பை வைக்கவும், மேலும் உங்கள் CONTRIBUTING அல்லது README கோப்பில் இருந்து அதை இணைப்பதன் மூலம் அதை உங்கள் சமூகத்திற்குத் தெரியப்படுத்தவும். + +## உங்கள் நடத்தை விதித் தொகுப்பு எவ்வாறு செயல்படுவது என்பதை நீங்கள் தீர்மானிப்பீர்கள் + + + +உங்களுடைய நடத்தை எவ்வாறு நடைமுறைப்படுத்தப்படும் என்பதை ஒரு மீறல் ஏற்படும் **_முன்பு_** நீங்கள் விளக்க வேண்டும். அவ்வாறு செய்ய பல காரணங்கள் உள்ளன: + +* தேவைப்படும்போது நீங்கள் நடவடிக்கை எடுப்பது பற்றி தீவிரமாக இருப்பதை இது காட்டுகிறது. + +* புகார்கள் உண்மையில் மறுபரிசீலனை செய்யப்படுமென உங்கள் சமூகம் இன்னும் உறுதி கொள்ளும். + +* ஒரு மீறலுக்காகத் விசாரிக்கப்படும்பொழுது, மீளாய்வு செயல்முறை நியாயமானது மற்றும் வெளிப்படையானதாக இருக்கும் என்று உங்கள் சமூகத்திற்கு உறுதிப்படுத்துங்கள். + +நடத்தை மீறல்களை மக்கள் தனிப்பட்ட முறையில் புகாரளிக்க (மின்னஞ்சல் முகவரியைப் போன்ற) கொடுக்க வேண்டும், மற்றும் அந்த அறிக்கையை யார் பெறுகிறார்கள் என்பதை விளக்கவும். இது ஒரு பராமரிப்பாளர், பராமரிப்பாளர்களின் குழு, அல்லது நடத்தை விதி குழுவாக இருக்கலாம். + +அந்த அறிக்கையைப் பெறும் நபரைப் பற்றி ஒருவர் மீறல் குறித்து புகாரளிக்க விரும்புவதை மறந்துவிடாதீர்கள். இந்த வழக்கில், வேறு யாரிடாமவது மீறல்களைப் புகாரளிக்க அவர்களுக்கு விருப்பத்தெரிவு கொடுங்கள். உதாரணத்திற்கு, @ctb and @mr-c [தங்கள் திட்டத்தை விளக்குகிறார்கள்](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): + +> துஷ்பிரயோகம், தொந்தரவு, அல்லது ஏற்றுக்கொள்ள முடியாத தன்மை ஆகியவற்றின் நிகழ்வுகள் **khmer-project@idyll.org** என்ற மின்னஞ்சல் மூலம் புகாரளிக்கலாம். டைட்டஸ் பிரவுன் மற்றும் மைக்கேல் ஆர். க்ரூஸோ. அவர்களில் ஒருவர் சம்பந்தப்பட்ட ஒரு சிக்கலைப் புகாரளிக்க மின்னஞ்சல் **ஜுடி பிரவுன் கிளார்க், Ph.D.** பரிணாம வளர்ச்சிக்கான ஆய்விற்கான BEACON மையத்தில் பல்வகைமை பணிப்பாளர், அறிவியல் மற்றும் தொழில்நுட்பத்திற்கான NSF மையம்.* + +உத்வேகத்திற்கு, ஜான்கோவின் [அமலாக்க கையேடை](https://www.djangoproject.com/conduct/enforcement-manual/) பார்க்கவும் (உங்கள் திட்டத்தின் அளவைப் பொறுத்து, இவ்வளவு விரிவானது தேவைப்படாமல் இருக்கலாம்). + +## உங்கள் நடத்தை விதித் தொகுப்பை செயல்படுத்ததுதல் + +சில நேரங்களில், உங்கள் சிறந்த முயற்சிகள் இருந்தபோதிலும், யாரோ ஒருவர் இந்த குறியீட்டை மீறுகிறார்கள். இப்படியாகும் பொழுது எதிர்மறையான அல்லது தீங்கு விளைவிக்கும் தன்மையை எதிர்கொள்ள பல வழிகள் உள்ளன. + +### நிலைமையைப் பற்றிய தகவல்களை சேகரிக்கவும் + +ஒவ்வொரு சமூக உறுப்பினரின் குரலையும் உங்கள் சொந்தமாக குரலைப்போல முக்கியமாக கருதுங்கள். யாராவது நடத்தை விதிமுறைகளை மீறுவதாக ஒரு அறிக்கையைப் பெற்றால், அது தீவிரமாக எடுத்து, அந்த நபருடன் உங்கள் சொந்த அனுபவத்திற்கு பொருந்தவில்லை என்றாலும், அதைப் பற்றி விசாரிக்கவும். இப்படி நீங்கள் செய்தால், உங்கள் சமுதாயத்திற்கு அவர்களின் கண்ணோட்டத்தை நீங்கள் மதிக்கிறீர்கள், அவர்களின் தீர்ப்பை நம்புகிறீர்கள் என சமிக்ஞை அனுப்புகிறது. + +கேள்விக்குரிய சமூக உறுப்பினர்கள் மீண்டும் மீண்டும் குற்றவாளியாக இருக்கலாம், மற்றவர்கள் தொடர்ந்து சங்கடப்படுவார்கள், அல்லது அவர்கள் ஒருமுறை சொல்லியோ அல்லது ஏதாவது செய்திருக்கலாம். இரண்டுமே சூழலைப் பொறுத்து, நடவடிக்கை எடுப்பதற்கு அடித்தளமாக இருக்கலாம். + +நீங்கள் பதிலளிக்கும் முன், என்ன நடந்தது என்பதை புரிந்துகொள்ள நேரம் எடுத்துக்கொள்ளுங்கள். நபரின் கடந்தகால கருத்துகள் மற்றும் உரையாடல்களால் அவர்கள் யார் என்பதை நன்கு புரிந்து கொள்ளவும், ஏன் அவர்கள் அப்படி செயல்பட்டிருக்கலாம் என்பதைப் புரிந்து கொள்ளவும். இந்த நபர் மற்றும் அவற்றின் நடத்தை பற்றி உங்களுடைய சொந்தக் காட்சிகளைத் தவிர்ப்பதற்கு முயற்சிக்கவும். + + + +### தகுந்த நடவடிக்கை எடுக்கவும் + +போதுமான தகவலை சேகரித்து செயலாக்குவதன் பிறகு, என்ன செய்ய வேண்டும் என்பதை நீங்கள் தீர்மானிக்க வேண்டும். உங்கள் அடுத்த நடவடிக்கை குறித்து நீங்கள் கருத்தில் கொள்ளும்போது, ஒரு மதிப்பீட்டாளராக உங்கள் குறிக்கோள் பாதுகாப்பான, மரியாதைக்குரிய மற்றும் ஒத்துழைப்புள்ள சூழலை ஊக்குவிப்பதாக நினைவில் கொள்ளுங்கள். சந்தர்ப்ப சூழ்நிலையை எவ்வாறு சமாளிப்பது என்பது மட்டுமல்லாமல், உங்கள் பதிலின் மீதும் உங்கள் சமூகத்தின் நடத்தையையும் எதிர்பார்ப்புகளையும் முன்னெடுத்துச் செல்வதையும் எப்படிப் பாதிக்கும் என்றும் கவனியுங்கள். + +யாராவது நடத்தை மீறல் புகாரளிக்கும் போது, அதை கையாள வேண்டியது உங்கள் வேலை, அவர்களுடையது அல்ல. சில நேரங்களில், தகவல் தருபவர் தங்கள் வாழ்க்கை, புகழ், அல்லது உடல் பாதுகாப்பிற்கு பெரும் ஆபத்தில் தகவல் வெளிப்படுத்துகிறார். அவர்களது துன்புறுத்தலை எதிர்கொள்ள அவர்கள் ஒரு கட்டாய நிலைக்கு தகவல் தருபவரை அனுப்ப முடியும். தகவல் தருபவர் வெளிப்படையாக கோரிக்கை விடுக்காவிட்டால், கேள்விக்குரிய நபருடன் நேரடியாக தொடர்பு கொள்ள வேண்டும். + +நடத்தை மீறலுக்கு நீங்கள் பதிலளிக்கக்கூடிய சில வழிகள் உள்ளன: + +* **கேள்விக்குரிய நபருக்கு ஒரு பகிரங்க எச்சரிக்கையை கொடுங்கள்** மேலும் அவர்களின் நடத்தை மற்றவர்களுக்கு எவ்வாறு தாக்கத்தை ஏற்படுத்துகிறது என்பதை விளக்குங்கள், முன்னர் அது ஏற்பட்ட அலைவரிசையில். சாத்தியமானால், பொதுத்தொடர்பு நீங்கள் நடத்தை நெறியை தீவிரமாக எடுத்துக் கொள்வதை சமூகத்தின் ஏனைய பகுதிகளுக்கு தெரிவிக்கின்றது. பரிவுடன், ஆனால் உங்கள் தொடர்பில் உறுதியாக இருங்கள். + +* கேள்விக்குரிய நபரிடம் அவர்களின் நடத்தை எவ்வாறு மற்றவர்களை பாதிக்கின்றது என்பதை விளக்கும் வகையில் **தனிப்பட்ட முறையில் தொடர்பு கொள்ளுங்கள்**. சூழ்நிலை தனிப்பட்ட தகவலை உள்ளடக்கியிருந்தால், நீங்கள் ஒரு தனிப்பட்ட தொடர்பு அலைவரிசையை பயன்படுத்த விரும்பலாம். நீங்கள் தனிப்பட்ட முறையில் யாரோடேனும் தொடர்பு கொண்டால், முதலில் நிலைமையை அறிக்கை செய்தவர்களை CC(தட்டச்சுப் படி) செய்வது நல்லது, எனவே நீங்கள் நடவடிக்கை எடுத்ததை அவர்கள் அறிவார்கள். புகாரளிக்கும் நபரை CC(தட்டச்சுப் படி) செய்வதற்கு முன் சம்மதம் கேளுங்கள். + +சில நேரங்களில், ஒரு தீர்மானத்தை எட்ட முடியாது. கேள்விக்குரிய நபர் எதிர்படும் பொழுது ஆக்ரோஷமாக அல்லது விரோதமாக மாறலாம் அல்லது மாற்றமடையாமல் போகலாம். இந்த சூழ்நிலையில், நீங்கள் வலுவான நடவடிக்கை எடுக்க வேண்டும். உதாரணத்திற்கு: + +* இந்த திட்டத்தின் எந்தவொரு அம்சத்திலும் பங்கு பெறும் தற்காலிக தடையின் மூலம், **கேள்விக்குரிய நபரை திட்டத்தில் இருந்து தற்காலிகமாக நிறுத்தி வைக்கவும்**. + +* திட்டத்தில் இருந்து **நபரை நிரந்தரமாக தடை செய்யவும்**. + +தடைசெய்யப்பட்ட உறுப்பினர்களை இலகுவாக எடுத்துக் கொள்ளக்கூடாது மற்றும் நிரந்தரமான மற்றும் சமரசமற்ற வேறுபாடுகளின் தோற்றத்தை பிரதிபலிக்க வேண்டும். ஒரு தீர்மானத்தை எட்ட முடியவில்லையே என்று தெளிவாகத் தெரிந்தால் மட்டுமே நீங்கள் இந்த நடவடிக்கைகளை எடுக்க வேண்டும். + +## பராமரிப்பாளராக உங்கள் பொறுப்புகள் + +தன்னிச்சையாக நடைமுறைப்படுத்த, நடத்தை நெறிமுறை ஒரு சட்டம் அல்ல. நடத்தை விதித் தொகுப்பு செயல்படுத்துபவது மற்றும் நடத்தை நெறிமுறை நிறுவும் விதிகளை பின்பற்றவது உங்கள் பொறுப்பு. + +ஒரு பராமரிப்பாளராக உங்கள் சமூகத்தின் வழிகாட்டுதல்களை நீங்கள் நிறுவுவதோடு, உங்கள் வழிகாட்டு நெறிமுறையின் விதிமுறைகளின் படி அந்த வழிமுறைகளை நடைமுறைப்படுத்தவும். அதாவது நடத்தை விதி மீறல் குறித்த எந்தவொரு அறிக்கையையும் தீவிரமாக எடுத்துக்கொள்வதாகும். புகாரளிக்கும் நபர், தங்கள் புகாரை ஒரு முழுமையான மற்றும் நியாயமான மறு ஆய்வு கடன் பட்டிருக்கிறார். அவர்கள் புகார் அளித்த நடத்தை மீறல் அல்ல என்பதை நீங்கள் தீர்மானித்தால், அவர்களுக்குத் தெளிவாகத் தொடர்பு கொண்டு, நீங்கள் ஏன் நடவடிக்கை எடுக்கப் போவதில்லை என்பதை விளக்கவும். அவர்கள் என்ன செய்கிறார்கள் என்பது அவர்களை பொருத்தது: அவர்கள் ஒரு சிக்கல் உள்ள நடத்தை சகித்துக் கொள்ளலாம் அல்லது சமூகத்தில் பங்கு பெறுவதை நிறுத்தலாம். + +நடத்தை முறையை _technically_ மீறாத நடத்தை பற்றிய அறிக்கை உங்கள் சமூகத்தில் ஒரு சிக்கல் இருக்கிறது என்பதைக் குறிக்கலாம், மேலும் இந்த சிக்கலைப் பற்றி விசாரித்து அதன்படி செயல்பட வேண்டும். இது உங்கள் நடத்தையின் விதித் தொகுப்பை மறுசீரமைக்க மற்றும் ஏற்றுக்கொள்ளக்கூடிய நடத்தையை தெளிவுபடுத்தும் மற்றும்/அல்லது கேள்விக்குரிய நபருடன் பேசுவதோடு, அவர்கள் நடத்தை விதிகளை மீறும் போது, அவர்கள் எதிர்பார்ப்பது என்ன என்று விளிம்பில் சாய்வது, பங்கேற்பாளர்கள் சங்கடமாக உணர்கிறார்கள். + +முடிவில், ஒரு பராமரிப்பாளராக, ஏற்றுக்கொள்ளத்தக்க நடத்தைக்கான தரங்களை நீங்கள் அமைத்து நிர்வகிக்கிறீர்கள். உங்களுக்கு திட்டத்தின் சமூக மதிப்புகள் வடிவமைக்கும் திறன் உள்ளது, மற்றும் பங்கேற்பாளர்கள் நீங்கள் ஒரு நியாயமான மற்றும் பாரபட்சமற்ற வழியில் அந்த மதிப்புகளை செயல்படுத்த வேண்டும் என்று எதிர்பார்க்கிறார்கள். + +## நீங்கள் உலகில் பார்க்க விரும்பும் நடத்தை ஊக்குவிக்கவும் 🌎 + +ஒரு திட்டம் விரோதமானதாகவோ அல்லது அசைக்கமுடியாததாகவோ தோன்றினால், மற்றவர்களின் நடத்தை சகித்துக்கொள்ளும் ஒரே ஒரு நபராக இருந்தாலும், நீங்கள் இன்னும் பல பங்களிப்பாளர்களை இழக்க நேரிடும், நீங்கள் சந்திக்காத சிலர் உட்பட. நடத்தை நெறிமுறைகளை பின்பற்றுவது அல்லது நடைமுறைப்படுத்துவது எப்போதும் எளிதல்ல, ஆனால் வரவேற்புமிக்க சூழல் உங்கள் சமூகத்தை வளர்க்க உதவும். diff --git a/_articles/ta/finding-users.md b/_articles/ta/finding-users.md new file mode 100644 index 0000000000000000000000000000000000000000..45fa862ffe9faaa23e3797cd73f55ade391170b5 --- /dev/null +++ b/_articles/ta/finding-users.md @@ -0,0 +1,156 @@ +--- +lang: ta +title: உங்கள் திட்டத்திற்கான பயனர்களைக் கண்டறிதல் +description: மகிழ்ச்சியான பயனர்களின் கைகளில் தருவதன் மூலம் உங்கள் திறந்த மூல திட்டத்தை வளர உதவுங்கள். +class: finding +order: 3 +image: /assets/images/cards/finding.png +related: + - beginners + - building +--- + +## வார்த்தை பரப்புதல் + +நீங்கள் ஒரு திறந்த மூல திட்டத்தை தொடங்கும் பொழுதே ஊக்குவிக்க வேண்டும் என்று எந்த விதியும் இல்லை. திறந்த மூலத்தில் பணியாற்றுவதற்கு பல முழுமையடைக்கூடுய காரணங்கள் உள்ளன, அவை பிரபலத்துவத்திற்காக இல்லை. உங்கள் திறந்த மூல திட்டத்தை கண்டுபிடித்துப் பயன்படுத்துவதற்கு மற்றவர்களை நம்புவதற்குப் பதிலாக, உங்களின் கடின உழைப்பைப் பற்றி வார்த்தைகளைப் பரப்ப வேண்டும்! + +## உங்கள் செய்தியைக் கண்டறியவும் + +உங்கள் திட்டத்தை ஊக்குவிப்பதற்கான உண்மையான பணியைத் தொடங்குவதற்கு முன், நீங்கள் என்ன செய்ய வேண்டும் என்பதை விளக்கவும், ஏன் முக்கியம் என்பதை விளக்கவும் முடியும். + +உங்கள் திட்டம் வித்தியாசமானதா அல்லது சுவாரஸ்யமானதா? நீங்கள் ஏன் அதை உருவாக்கினீர்கள்? இந்த கேள்விகளுக்கு பதில் அளிப்பது, உங்கள் திட்டத்தின் முக்கியத்துவத்தை நீங்கள் பரப்புவதற்கு உதவும். + +பயனர்கள் பயனர்களாக ஈடுபடுவதை நினைவில் கொள்ளுங்கள், இறுதியில் பங்களிப்பாளர்களாகி விடுகிறார்கள், ஏனென்றால் உங்கள் திட்டம் அவர்களுக்கு ஒரு சிக்கலை தீர்க்கிறது. உங்கள் திட்டத்தின் செய்தி மற்றும் மதிப்பைப் பற்றி நீங்கள் சிந்திக்கும்போது, _பயனர்கள் மற்றும் பங்களிப்பாளர்கள்_ விரும்பும் கண்ணாடி வில்லை மூலம் அவற்றைப் பார்க்க முயற்சி செய்யுங்கள். + +எடுத்துக்காட்டாக, @robb [வரைபடவியல்](https://github.com/robb/Cartography), ஏன் பயனுள்ளதாக இருக்கும் என்பதைப் பற்றிய தெளிவான குறியீடுகளைப் பயன்படுத்துகிறார்: + + + +ஒரு ஆழமான செய்திக்கு, மொஸில்லாவின்["ஆளுமை மற்றும் பாதைகள்"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) பயனர் நபர்களை உருவாக்குவதற்கான பயிற்சியைப் பார்க்கவும். + +## மக்கள் உங்கள் திட்டத்தை கண்டுபிடித்து பின்பற்ற உதவுங்கள் + + + +ஒரு பெயரைக் குறிப்பிடுவதன் மூலம் மக்கள் உங்கள் திட்டத்தை கண்டுபிடித்து, நினைவில் வைக்க உதவுங்கள். + +**உங்கள் வேலையை ஊக்குவிக்க ஒரு தெளிவான கைப்பிடி வேண்டும்.** ஒரு கீச்சர் கைப்பிடி, கிட்ஹப் URL, அல்லது IRC சேனல் உங்கள் திட்டத்தை மக்கள் சுட்டிக்காட்ட ஒரு சுலபமான வழி. Tஇந்த நிலையங்கள் உங்கள் திட்டத்தின் வளர்ந்து வரும் சமூகத்தை கூட்டுவதற்கு ஒரு இடத்தையும் கொடுக்கின்றன. + +இன்னும் உங்கள் திட்டத்திற்கான நிலையங்கள் அமைக்க விரும்பவில்லை என்றால், நீங்கள் செய்யும் அனைத்தையும் உங்கள் சொந்த கீச்சர் அல்லது கிட்ஹப் கைப்பிடிகளை விளம்பரப்படுத்தவும். உங்கள் கீச்சர் அல்லது கிட்ஹப் கைப்பிடிகளை மேம்படுத்துவது, உங்களை தொடர்புகொள்வது அல்லது உங்கள் வேலையை எவ்வாறு பின்பற்றுவது என்பதை மக்கள் அறிவர். ஒரு சந்திப்பு அல்லது நிகழ்வில் நீங்கள் பேசினால், உங்கள் தொடர்பு தகவல்கள் உங்கள் ஆளுமைக் குறிப்பு அல்லது விளக்கக்காட்சிகளில் சேர்க்கப்பட்டுள்ளதா என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள். + + + +**உங்கள் திட்டத்திற்கான வலைத்தளத்தை உருவாக்குங்கள்.** தெளிவான ஆவணங்கள் மற்றும் பயிற்சிகளுடன் இணைந்திருக்கும் போது, ஒரு வலைத்தளம் உங்கள் திட்டத்தை நட்பு ரீதியாகவும் எளிதாகவும் செல்லவும் செய்கிறது. ஒரு வலைத்தளம் இருப்பதால், உங்கள் திட்டம் செயலில் இருப்பதைக் குறிக்கிறது, இது உங்கள் பார்வையாளர்களை மிகவும் வசதியாக உணர வைக்கும். உங்கள் திட்டத்தை எவ்வாறு பயன்படுத்துவது என்பது குறித்த யோசனைகளை வழங்குவதற்கு உதாரணங்கள் வழங்கவும். + +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), டிஜாங்கோவின் இணை-படைப்பாளி, ஒரு வலைத்தளம் _"நாங்கள் ஆரம்ப நாட்களில் டிஜாங்கோவில் செய்த சிறந்த விஷயம்"_ என்று கூறினார். + +கிட்ஹப் இல் உங்கள் திட்டம் host செய்யப்பட்டிருந்தால், எளிதாக ஒரு வலைத்தளத்தை உருவாக்க [கிட்ஹப் பக்கங்கள்](https://pages.github.com/) பயன்படுத்தலாம். [யோமன்](http://yeoman.io/), [வேக்ரன்ட்](https://www.vagrantup.com/), மற்றும் [மிடில்மேன்](https://middlemanapp.com/) சிறப்பான, விரிவான வலைத்தளங்களின் [சில உதாரணங்கள்](https://github.com/showcases/github-pages-examples) ஆகும். + + + +இப்போது உங்கள் திட்டத்திற்கான செய்தியைக் கொண்டிருக்கிறோம், உங்கள் திட்டத்தை மக்கள் கண்டுபிடிக்க எளிய வழி, அங்கு சென்று, உங்கள் பார்வையாளர்களுடன் பேசவும்! + +## உங்கள் திட்டத்தின் பார்வையாளர்களிடம் (இயங்கலை) செல்லுங்கள் + +இயங்கலை விஞ்சியிறுப்பு விரைவில் வார்த்தையை பகிர மற்றும் பரவ ஒரு சிறந்த வழி. இயங்கலை தடங்களைப் பயன்படுத்தி, மிக அதிகமான பார்வையாளர்களை அடைய உங்களுக்கு வாய்ப்பு உள்ளது. + +உங்கள் பார்வையாளர்களை அடைய, ஏற்கனவே இருக்கும் இயங்கலை சமூகங்களையும் தளங்களையும் பயன்படுத்தி கொள்ளுங்கள். உங்கள் திறந்த மூல திட்டம் ஒரு மென்பொருள் திட்டமாக இருந்தால், உங்கள் பார்வையாளர்களை ஒருவேளை [ஸ்டாக் ஓவர்ஃப்ளோ](https://stackoverflow.com/), [ரெட்டிட்](https://www.reddit.com), [ஹாக்கர் நியூஸ்](https://news.ycombinator.com/), or [கோரா](https://www.quora.com/) ஆகியவற்றில் நீங்கள் காணலாம். உங்கள் வேலையினால் மக்கள் மிகவும் பயன் அடையும் அல்லது உற்சாகமாக இருக்க வேண்டும் என நினைக்கும் தடங்களை கண்டறியுங்கள். + + + +உங்கள் திட்டத்தை பொருத்தமான வழிகளில் பகிர்ந்து கொள்ள வழிகளைக் காண முடியுமா என்பதைக் காணவும்: + +* **பொருத்தமான திறந்த மூல திட்டங்கள் மற்றும் சமூகங்களை அறிந்து கொள்ளுங்கள்.** சில நேரங்களில், நீங்கள் நேரடியாக உங்கள் திட்டத்தை ஊக்குவிக்க வேண்டியதில்லை. உங்கள் திட்டமானது பைத்தானைப் பயன்படுத்தும் தரவு விஞ்ஞானிகளுக்கு சரியானது என்றால், பைத்தான் தரவு அறிவியலாளரை அறிந்து கொள்ளுங்கள். மக்கள் உங்களுக்குத் தெரிந்தால், உங்கள் வேலையைப் பற்றி பேசுவதற்கும், பகிர்ந்து கொள்வதற்கும் வாய்ப்புகள் இயற்கையாக எழும். +* **உங்கள் திட்டத்தை சரிசெய்யும் சிக்கலை எதிர்கொள்ளும் நபர்களைக் கண்டறியவும்.** உங்கள் திட்டத்தின் இலக்கு பார்வையாளர்களில் விழும் நபர்களை தொடர்புடைய கருத்துக்களம் மூலம் தேடலாம். அவர்களின் கேள்விக்கு பதில் மற்றும் உத்தமமான வழியை கண்டுபிடிக்கவும், தக்க சமயத்தில் ஒரு தீர்வாக உங்கள் திட்டத்தை பரிந்துரைக்கவும். +* **கருத்துக்களைக் கேட்கவும்.** உங்களையும் உங்கள் வேலையும் ஒரு பார்வையாளருக்கு, அதனுடன் தொடர்புடையதாகவும் சுவாரசியமாகவும் இருக்கும்படி அறிமுகப்படுத்தவும். உங்கள் திட்டத்தில் இருந்து யார் பயனடையலாம் என நீங்கள் நினைப்பதைப் பற்றி குறிப்பிடவும். Tவாக்கியத்தை முடிக்க முயற்சிக்கும் போது: _"என் திட்டம் உண்மையில் Y- ஐ செய்ய முயற்சிக்கும் X-க்கு உதவும் என்று நினைக்கிறேன்_". வெறுமனே உங்கள் வேலையை ஊக்குவிப்பதை விட, மற்றவர்களின் கருத்துக்களைக் கேட்டு மறுமொழி கூறுங்கள். + +பொதுவாக, மற்றவர்களிடம் எதிர் உதவி கேட்கும் முன்பு, உதவுவதில் கவனம் செலுத்துங்கள். யாரும் எளிதாக ஒரு திட்டத்தை இயங்கலையில் ஊக்குவிக்க முடியும் என்பதால், கூச்சல் நிறைய இருக்கும். கூட்டத்தில் இருந்து தனித்து நிற்க, மக்களிடம் நீங்கள் எதை விரும்புகிறீர்கள் என்று மட்டுமல்லாமல், நீங்கள் யார் என்பதையும் கூறவும். + +யாரும் கவனத்தை ஈர்க்காவிட்டால் அல்லது உங்கள் ஆரம்ப முயற்சிகளுக்கு பதிலளிக்காவிட்டால், மனந்தளர வேண்டாம்! பெரும்பாலான திட்டங்களை அறிமுகப்படுத்த மாதங்கள் அல்லது ஆண்டுகள் ஆகலாம். நீங்கள் முதல் முறையாக பதிலைப் பெறவில்லையெனில், வேறு தந்திரோபாயத்தை முயற்சிக்கவும் அல்லது மற்றவர்களின் வேலைக்கு மதிப்பு சேர்க்க வழிகளைத் தேடுங்கள். உங்கள் திட்டத்தை மேம்படுத்த மற்றும் துவக்க நேரம் மற்றும் அர்ப்பணிப்பு ஆகியவற்றை எடுக்கும். + +## உங்கள் திட்டத்தின் பார்வையாளர்களிடம் (முடக்கலை) செல்லுங்கள் + + + +முடக்கலை நிகழ்வுகள் பார்வையாளர்களுக்கு புதிய திட்டங்களை மேம்படுத்துவதற்கான ஒரு பிரபலமான வழியாகும். ஈடுபட்டுள்ள பார்வையாளர்களை அடைய மற்றும் ஆழமான மனித இணைப்புகளை உருவாக்க அது ஒரு சிறந்த வழி, குறிப்பாக நீங்கள் நிரலாளர்களை அடைவதில் ஆர்வமாக இருந்தால். + +நீங்கள் [பொது பேச்சிற்கு புதிது](https://speaking.io/) என்றால், உங்கள் திட்டத்தின் மொழி அல்லது சுற்றுச்சூழல் தொடர்பான உள்ளூர் சந்திப்பைக் கண்டுபிடிப்பதன் மூலம் தொடங்கவும். + + + +நீங்கள் முன்பு ஒரு நிகழ்வில் பேசிய அனுபவம் இல்லையென்றால், பதற்ற உணர்வு முற்றிலும் சாதாரணமானது! உங்கள் வேலையைப் பற்றி உண்மையிலேயே கேட்க விரும்புவதால் உங்கள் பார்வையாளர்கள் அங்கு இருப்பதை நினைவில் வையுங்கள். + +உங்கள் பேச்சை எழுதும்போது, உங்கள் பார்வையாளர்களுக்கு சுவாரசியமானவற்றையும், மதிப்பை கொடுப்பதையும் கவனத்தில் கொள்ளவும். உங்கள் மொழி நட்பு மற்றும் அணுகக்கூடியதாக வையுங்கள். புன்னகையுங்கள், சுவாசியுங்கள், கேளிக்கை கொள்ளுங்கள். + + + +நீங்கள் தயாராக இருந்தால், உங்கள் திட்டத்தை மேம்படுத்த மாநாட்டில் பேசுங்கள். மாநாடுகள் பலரைச் சென்றடைய உதவும், சில நேரங்களில் உலகம் முழுவதும். + +உங்கள் மொழி அல்லது சுற்றுச்சூழல் தொடர்பான குறிப்பிட்ட மாநாடுகளைப் பாருங்கள். உங்கள் பேச்சுக்கு முன், மாநாட்டில் கலந்துரையாடலைப் பேசுவதற்கு உங்கள் உரையைச் சுருக்கமாக ஆராயுங்கள், மாநாட்டில் பேசுவதற்கான வாய்ப்புகள் அதிகரிக்கும். மாநாட்டின் பேச்சாளர்களைப் பார்த்து நீங்கள் உங்கள் பார்வையாளர்களை உணர்வீர்கள். + + + +## நற்பெயர் உருவாக்கவும் + +மேலே கோடிட்டுள்ள உத்திகளைத் தவிர்த்து, உங்கள் திட்டத்தில் பங்கெடுக்க மற்றும் பங்களிக்க மக்களை அழைப்பதற்கான சிறந்த வழி அவர்களின் திட்டங்களை பகிர்ந்து மற்றும் பங்களிக்க வேண்டும். + +புதியவர்களுக்கு உதவி, வளங்களை பகிர்தல், மற்றவர்களின் திட்டங்களுக்கு சிந்தனைக்குரிய பங்களிப்புகளை செய்வது ஆகியவை நேர்மறையான நற்பெயரை உருவாக்க உதவும். திறந்த மூல சமுதாயத்தில் செயலில் உள்ள உறுப்பினராக இருப்பதால், உங்கள் வேலைக்கு மக்கள் சூழலைக் கொண்டிருப்பார்கள், மேலும் உங்கள் திட்டத்தை கவனத்தில் எடுத்து, பகிர்ந்து கொள்ளலாம். மற்ற திறந்த மூல திட்டங்களுடனான உறவை வளர்ப்பதன் மூலம் உத்தியோகபூர்வ கூட்டுக்களுக்கு வழிவகுக்கலாம். + + + +உங்கள் நற்பெயரைத் தொடங்குவதற்கு என்றும் முன்னதாகவோ அல்லது மிகவும் தாமதமாக இல்லை. நீங்கள் ஏற்கனவே உங்கள் சொந்த திட்டத்தை ஆரம்பித்திருந்தாலும், மற்றவர்களுக்கு உதவ வழிகளைத் தேடுங்கள். + +பார்வையாளர்களை உருவாக்குவதற்கு ஒரே இரவில் தீர்வு இல்லை. நம்பிக்கையையும் மற்றவர்களுடைய மரியாதையையும் பெற்றுக்கொள்வது நேரம் எடுக்கும், உங்கள் நற்பெயரைக் கட்டி முடிக்காது. + + + +## பொறுமை காக்கவும் + +உங்கள் திறந்த மூல திட்டத்தை மக்கள் கவனிக்க முன் நீண்ட நேரம் எடுக்கலாம். பரவாயில்லை! மிக பிரபலமான சில திட்டங்கள் இன்று அதிக அளவில் நடவடிக்கைகளை எட்டுவதற்கு பல ஆண்டுகள் எடுத்தன. உங்கள் திட்டம் தன்னிச்சையாக புகழ் பெறும் என்று நம்புவதற்குப் பதிலாக உறவுகளை மேம்படுத்தவதில் கவனம் செலுத்துங்கள். பொறுமையாக இருங்கள், உங்கள் வேலையைப் பாராட்டுபவர்களுடன் பகிர்ந்து கொள்ளுங்கள். diff --git a/_articles/ta/getting-paid.md b/_articles/ta/getting-paid.md new file mode 100644 index 0000000000000000000000000000000000000000..3267c7af00befd8a929248d764cde13634c9d88e --- /dev/null +++ b/_articles/ta/getting-paid.md @@ -0,0 +1,181 @@ +--- +lang: ta +title: திறந்த மூல வேலைக்கு பணம் பெறுதல் +description: உங்கள் நேரத்தை அல்லது உங்கள் திட்டத்திற்கான நிதி ஆதாரத்தை பெறுவதன் மூலம் திறந்த மூலத்தில் உங்கள் பணியைத் தொடரவும். +class: getting-paid +order: 7 +image: /assets/images/cards/getting-paid.png +related: + - best-practices + - leadership +--- + +## ஏன் சிலர் நிதி ஆதரவை நாடுகின்றனர் + +பெரும்பான்மையான திறந்த மூல வேலை தன்னார்வலர்களால் செய்யப்படுகிறது. உதாரணமாக, யாரோ ஒருவர் அவர்கள் ஒரு திட்டத்தில் ஒரு பிழையைச் சந்திக்க நேரிடலாம் அல்லது ஒரு விரைவான பிழைத்திருத்தத்தை சமர்ப்பிக்கலாம், அல்லது திறந்த மூல திட்டத்திற்கு தங்களது ஓய்வு நேரத்திலே பழுது நீக்கல் செய்யலாம். + + + +ஒரு திறந்த மூல வேலைக்காக ஒரு நபர் பணம் பெற விரும்பவில்லை என்பதற்கு பல காரணங்கள் உள்ளன. + +* **அவர்கள் ஏற்கனவே விரும்பும் ஒரு முழுநேர வேலையை கொண்டுள்ளார்கள்**, அதனால் அவர்களது ஓய்வு நேரத்தில் திறந்த மூலத்திற்கு பங்களிக்க உதவுகிறது. +* **அவர்கள் பொழுதுபோக்கு அல்லது ஆக்கப்பூர்வமான விலகலுக்காக திறந்த மூலத்தைப்** பற்றி நினைத்து மகிழ்கிறார்கள், தங்கள் திட்டங்களில் பணியாற்றுவதற்காக நிதி ரீதியாக கடமைப்பட்டிருக்க விரும்பவில்லை. +* தங்கள் நற்பெயரை அல்லது இலாக்காகளை உருவாக்கி, ஒரு புதிய திறமையைக் கற்றுக்கொள்வது அல்லது ஒரு சமூகத்திற்கு நெருக்கமாக உணருதல் போன்ற பிற திறன்களை **திறந்த மூலத்திற்கு பங்களிக்கப்பதன் மூலம் ஆதாயங்களாக அவர்கள் பெறுகிறார்கள்**. + + + +மற்றவர்களுக்கு, குறிப்பாக நன்கொடைகள் தொடர்ககின்ற றல்லது குறிப்பிடத்தக்க நேரத்திற்கு தேவைப்படும் போது, திறந்த மூலத்திற்கு பங்களிக்க பணம் செலுத்துவது மட்டுமே அவர்கள் பங்கேற்கக்கூடிய ஒரே வழி, திட்டத்திற்கு தேவை, அல்லது தனிப்பட்ட காரணங்களுக்காக அல்ல. + +பிரபலமான திட்டங்களை பராமரிப்பது குறிப்பிடத்தக்க பொறுப்பாகும், மாதத்திற்கு சில மணிநேரத்திற்கு பதிலாக வாரத்திற்கு 10 அல்லது 20 மணி நேரம் எடுத்துக்கொள்ளலாம். + + + +பணம் செலுத்தும் வேலை, வாழ்க்கையின் பல்வேறு துறைகளிலிருந்தும் அர்த்தமுள்ள பங்களிப்புகளை செய்ய உதவுகிறது. சிலர் திறந்த மூல திட்டங்களில் தங்கள் தற்போதைய நிதி நிலை, கடன், அல்லது குடும்பம் அல்லது பிற கவனிப்பு கடமைகளின் அடிப்படையில் பணம் செலுத்தப்படாத நேரத்தை செலவிட முடியாது. அதாவது, தங்கள் நேரத்தை தன்னார்வத் தொகையை வழங்க முடியாத திறமையான மக்களிடமிருந்து பங்களிப்பை உலகம் காணாது. இதில் நீதிநெறிக்குரிய உட்குறிப்பீடுகள் உள்ளதால், @ashedryden[விவரித்ததுப்போல்](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), வாழ்க்கையில் நன்மைகளை அனுபவிப்பவர்களுக்கே ஆதரவளித்து பணி செய்யப்படுவதால், தன்னார்வ பங்களிப்புகளை அடிப்படையாகக் கொண்டு கூடுதல் நன்மைகள் கிடைக்கும், பின்னர் தன்னார்வத் தொண்டு செய்யாத மற்றவர்கள் பின்னர் வாய்ப்புகளை பெறவில்லை, இது திறந்த மூலத்தின் சமூகத்தின் தற்போதைய பல்வகைமையை வலுப்படுத்தும். + + + +நீங்கள் நிதி ஆதரவு தேடுகிறீர்களானால், இரண்டு பாதைகள் பரிசீலிக்கப்படுகின்றன. உங்கள் சொந்த நேரத்தை ஒரு பங்களிப்பாளராக நீங்கள் ஆதரிக்கலாம் அல்லது திட்டத்திற்கான நிறுவன நிதியுதவியைக் காணலாம். + +## உங்கள் நேரத்திற்கான நிதிநல்கல் + +இன்று, பலர் திறந்த மூலத்தில் பகுதி அல்லது முழுநேர வேலைக்கு பணம் சம்பாதிக்கின்றனர். உங்கள் நேரத்திற்கு பணம் சம்பாதிக்க மிகவும் பொதுவான வழி உங்களை பணி அமர்த்துவரிடம் பேசுவதாகும். + +உங்கள் முதலாளி உண்மையிலேயே திட்டத்தை பயன்படுத்துகிறார்களானால், திறந்த மூல வேலைக்கு ஒரு விஷயத்தை எளிதாக்கலாம், ஆனால் உங்கள் சுருதிடன் ஆக்கப்பூர்வமாகப் பெறலாம். ஒருவேளை உங்கள் முதலாளி இந்த திட்டத்தை பயன்படுத்தவில்லை, ஆனால் பைதான் பயன்படுத்தப்படுகிறது, மேலும் பிரபலமான பைத்தான் திட்டத்தை பராமரிக்க புதிய பைத்தான் நிரல் உருவாக்குபவர்களை ஈர்க்கிறது. ஒருவேளை அது உங்கள் முதலாளி பொதுவாக நிரலர் நட்புக்கு மிகவும் பொருத்தமானதாக இருக்கும். + + + +நீங்கள் வேலை செய்ய உங்களிடம் திறந்த மூல திட்டப்பணி இல்லை என்றால், தற்போதைய பணி வெளியீடு திறந்த மூலமாக்க, உங்கள் சொந்த மென்பொருளில் சிலவற்றை திறக்க உங்கள் முதலாளிக்கு ஒரு வழக்கு உருவாக்கவும். + +பல நிறுவனங்கள் திறந்த மூல திட்டங்களை தங்கள் வியாபாரக் குறி உருவாக்க மற்றும் செயல் திறனை மிக்கவர்களை பணியமர்த்துவதற்கு உருவாக்குகின்றன. + +@hueniverse, உதாரணமாக, [வால்மார்ட்டின் திறந்த மூலதன முதலீட்டை](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html) நியாயப்படுத்த நிதி காரணங்களைக் கண்டறிந்துள்ளனர். மற்றும் ஃபேஸ்புக்கின் திறந்த மூல நிரல் ஆட்சேர்ப்பில் [வேறுபாட்டை உருவாக்கியதை](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) @jamesgpearce கண்டறிந்தார்: + +> இது எங்கள் கொந்தர் கலாச்சாரத்துடன் நெருக்கமாக உள்ளது, எங்கள் அமைப்பு எவ்வாறு உணரப்பட்டது. நாங்கள் எங்கள் ஊழியர்களிடம் கேட்டோம், "முகநூலில் திறந்த மூல மென்பொருள் திட்டம் பற்றி நீங்கள் அறிந்திருக்கிறீர்களா?". மூன்றில் இரண்டு பங்கு "ஆம்" என்றார். ஒரு பாதிபேர் அந்த செயல்முறைத் திட்டம் எங்களுக்கு வேலை செய்யத் தீர்மானித்தது. இவை குறுகலான எண்களாக இல்லை, மேலும் தொடர்கின்ற ஒரு போக்கு. + +உங்கள் நிறுவனம் இந்த வழியில் செல்லும்பொழுது, சமூகம் மற்றும் பெருநிறுவன செயல்பாடுகளுக்கு இடையில் எல்லைகளை வைத்திருக்க வேண்டியது அவசியம்.இறுதியாக, திறந்த மூலமானது உலகெங்கிலும் உள்ள மக்களிடமிருந்து நன்கொடைகள் மூலம் தன்னைத் தக்கவைத்துக்கொள்வதோடு, எந்த ஒரு நிறுவனத்தையும் அல்லது இடத்தையும் விட இது பெரியதாகும். + + + +திறந்த மூல வேலைக்கு முன்னுரிமை கொடுக்க உங்கள் தற்போதைய பணியாளரை நீங்கள் சமாதானப்படுத்த முடியாவிட்டால், ஒரு புதிய முதலாளி கண்டுபிடிப்பதை கருத்தில் கொள்க. திறந்த மூல வேலை வெளிப்படையான அர்ப்பணிப்பு செய்யும் நிறுவனங்களைக் கவனியுங்கள். உதாரணத்திற்கு: + +* சில நிறுவனங்கள், [நெட்ஃபிக்ஸ்](https://netflix.github.io/) or [பேபால்](https://paypal.github.io/), திறந்த மூலத்தில் தங்கள் ஈடுபாட்டை வலைத்தளங்கள்ல் உயர்த்தி உரைக்கின்றன +* [Zalando](https://opensource.zalando.com) ஊழியர்களுக்கான [திறந்த மூல பங்களிப்பு கொள்கையை](https://opensource.zalando.com/docs/using/contributing/) வெளியிட்டது + +[Go](https://github.com/golang) அல்லது [React](https://github.com/facebook/react) போன்ற ஒரு பெரிய நிறுவனத்தில் தோன்றிய திட்டங்கள், திறந்த மூலத்தில் மேலும் வேலை செய்ய மக்களைப் பயன்படுத்தக்கூடும். + +இறுதியாக, உங்களுடைய தனிப்பட்ட சூழ்நிலைகளை பொறுத்து, நீங்கள் உங்கள் திறந்த மூல வேலைக்கு நிதி திரட்ட முயற்சி செய்யலாம். உதாரணத்திற்கு: + +* @gaearon தனது [Redux](https://github.com/reactjs/redux) திட்டத்திற்கான நிதியை [பேட்ரியன் கூட்டல் நிதி பிரச்சாரத்தின்](https://redux.js.org/) மூலம் திரட்டினார். +* @andrewgodwin டிஜாங்க் திட்ட அமைப்புமுறைகளை [kickstarter பிரச்சாரத்தின்](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) மூலம் திரட்டினார். + +## உங்கள் திட்டத்திற்கான நிதிகளைக் கண்டறிதல் + +தனிப்பட்ட பங்களிப்பாளர்களுக்கான ஏற்பாடுகளுக்கு அப்பால், சில நேரங்களில் திட்டங்கள் நிறுவனங்கள், தனிநபர்கள் அல்லது மற்றவர்களிடம் இருந்து பணத்தை திரட்டுகின்றன. + +நிறுவன நிதியளிப்பு நடப்பு பங்களிப்பாளர்களுக்கு செலுத்துவதை நோக்கி செல்லலாம், திட்டத்தை இயங்கும் செலவுகள் (ஹோஸ்டிங் கட்டணங்கள் போன்றவை) அல்லது புதிய அம்சங்கள் அல்லது யோசனைகளை முதலீடு செய்தல் ஆகியவற்றை உள்ளடக்கும். + +திறந்த மூலத்தின் புகழ் அதிகரிக்கும்போது, திட்டங்களுக்கான நிதிகளைக் கண்டறிவது இன்னும் பரிசோதனையாகும், ஆனால் சில பொதுவான விருப்பத்தெரிவுகள் உள்ளன. + +### பிரச்சாரங்களை அல்லது விளம்பரதாரர்கள் மூலம் உங்கள் பணிக்கான பணம் திரட்டவும் + +உங்களிடம் வலுவான பார்வையாளர்களோ அல்லது நற்பெயரைப் பெற்றிருந்தால், உங்கள் திட்டம் மிகவும் பிரபலமாக இருந்தால், நிதியுதவிகளை கண்டறிவது நல்லது. +நிதியளிக்கும் திட்டங்களின் சில உதாரணங்கள் பின்வருமாறு: + +* **[வெப்பேக்](https://github.com/webpack)** நிறுவனங்கள் மற்றும் தனிநபர்களிடமிருந்து [OpenCollective மூலம்](https://opencollective.com/webpack) நிதி திரட்டுகிறது +* **[Vue](https://github.com/vuejs/vue)** [பேட்ரன் மூலம் நிதியளிக்கப்பட்டது](https://github.com/open-source/stories/yyx990803) +* **[ரூபி டுகேதர்](https://rubytogether.org/),** [பண்ட்லர்](https://github.com/bundler/bundler), [ரூபிஜெம்ஸ்](https://github.com/rubygems/rubygems), மற்றும் பிற ரூபி உள்கட்டமைப்பு திட்டங்களுக்கு பணிக்கு பணம் செலுத்துகின்ற ஒரு இலாப நோக்கமற்ற அமைப்பு + +### வருவாய் நீரோடை உருவாக்கவும் + +உங்கள் திட்டத்தை பொறுத்து, நீங்கள் வணிக ஆதரவு, ஹோஸ்ட் செய்யப்பட்ட விருப்பங்கள், அல்லது கூடுதல் அம்சங்களுக்கு கட்டணம் வசூலிக்கலாம். ஒரு சில உதாரணங்கள் பின்வருமாறு: + +* **[சைட்கிக்](https://github.com/mperham/sidekiq)** கூடுதல் ஆதரவுக்கான கட்டண பதிப்புகள் வழங்குகிறது +* **[டிராவிஸ் சிஐ](https://github.com/travis-ci)** அதன் தயாரிப்பின் கட்டண பதிப்புகள் வழங்குகிறது +* **[கோஸ்ட்](https://github.com/TryGhost/Ghost)** ஒரு இலாப நோக்கமற்றத பணம் செலுத்திய நிர்வகிக்கப்பட்ட சேவை + +[என்பிஎம்](https://github.com/npm/npm) and [டாக்கர்](https://github.com/docker/docker), போன்ற சில பிரபலமான திட்டங்கள், தங்கள் வணிக வளர்ச்சியை ஆதரிப்பதற்காக துணிகர மூலதனத்தை அதிகரிக்கின்றன. + +### மானிய நிதிக்கு விண்ணப்பிக்கவும் + +சில மென்பொருள் அடித்தளங்கள் மற்றும் நிறுவனங்கள் திறந்த மூல வேலைகளுக்கு மானியங்களை வழங்குகின்றன. சில நேரங்களில், திட்டத்திற்கான ஒரு சட்ட நிறுவனம் ஒன்றை அமைக்காமல் தனிநபர்களுக்கு மானியங்கள் வழங்கப்படலாம். + +* **[ரீட் த டாக்ஸ்](https://github.com/rtfd/readthedocs.org)** [மோசில்லா திறந்த மூல ஆதரவு](https://www.mozilla.org/en-US/grants/) மூலம் கொடை பெற்றது +* **[ஓபன்எம்ஆர்எஸ்](https://github.com/openmrs)** பணி [Stripe's திறந்த மூல ரிட்ரேட்](https://stripe.com/blog/open-source-retreat-2016-grantees) மூலம் நிதி பெற்றது +* **[லைப்பிரரி.ஐஓ](https://github.com/librariesio)** [ஸ்லோன் அறக்கட்டளை](https://sloan.org/programs/digital-technology) மூலம் கொடை பெற்றது +* **[பைத்தான் மென்பொருள் அறக்கட்டளை](https://www.python.org/psf/grants/)** பைத்தான் தொடர்பான பணிக்கு மானியங்களை வழங்குகிறது + +மேலும் விரிவான விருப்ப தெரிவுகள் மற்றும் வழக்கு ஆய்வுகளுக்கு, திறந்த மூல வேலைக்கு பணம் சம்பாதிக்க @nayafia [ஒரு வழிகாட்டி எழுதினார்](https://github.com/nayafia/lemonade-stand). வெவ்வேறு விதமான நிதியுதவி பல்வேறு திறமைகளுக்குத் தேவைப்படுகிறது, எனவே உங்கள் விருப்பங்களை நீங்கள் சிறப்பாகச் செயல்படுத்துவதை கண்டுபிடிக்க உங்கள் பலத்தை கருத்தில் கொள்ளுங்கள். + +## நிதியுதவிக்கு ஒரு வகை செய்தல் + +உங்கள் திட்டம் ஒரு புதிய யோசனையாக இருந்தாலும் அல்லது பல ஆண்டுகளாக இருந்தாலும் சரி, உங்கள் இலக்கு அனுபவத்தை அடையாளம் காண்பதில் குறிப்பிடத்தக்க சிந்தனை வைக்க வேண்டும் மற்றும் ஒரு கட்டாய வழக்கு ஒன்றை உருவாக்கும். + +நீங்கள் உங்கள் சொந்த நேரத்திற்காக அல்லது ஒரு திட்டத்திற்கான நிதி திரட்ட, நீங்கள் பின்வரும் கேள்விகளுக்கு பதிலளிக்க வேண்டும். + +### தாக்கம் + +ஏன் இந்த திட்டம் பயனுள்ளதாக இருக்கும்? ஏன் உங்கள் பயனர்கள், அல்லது சாத்தியமான பயனர்கள் அதை விரும்புகிறார்கள்? இது ஐந்து ஆண்டுகளில் எங்கு இருக்கும்? + +### இழுவை + +உங்கள் திட்டம் முக்கியம் என்பதற்கான அளவீடுகள், நிகழ்வுகள், அல்லது சான்றுகள் ஆதாரங்களாக சேகரிக்க முயற்சிக்கவும். இப்போது உங்கள் திட்டத்தை பயன்படுத்தி வரும் நிறுவனங்கள் அல்லது குறிப்பிடத்தக்க மக்கள் இருக்கிறீர்களா? இல்லையென்றால், ஒரு முக்கிய நபர் அதை ஆதரித்தாரா? + +### முதலீட்டாளர்களுக்கு மதிப்பு + +முதலீட்டாளர்கள், உங்களுடைய முதலாளிகளோ அல்லது மானிய நிதியளிப்பு நிறுவனமோ அடிக்கடி வாய்ப்புகளை சந்திக்கிறார்கள். வேறு எந்த சந்தர்ப்பத்திலும் உங்கள் திட்டத்தை ஏன் அவர்கள் ஆதரிக்க வேண்டும்? அவர்கள் எப்படி தனிப்பட்ட முறையில் பயனடைகிறார்கள்? + +### நிதிகளைப் பயன்படுத்துதல் + +முன்மொழியப்பட்ட நிதிக்கு என்ன, சரியாக, நீங்கள் சாதிக்க வேண்டும்? ஊதியத்தை செலுத்துவதற்கு பதிலாக திட்ட மைல்கற்கள் அல்லது விளைவுகளை கவனம் செலுத்துங்கள். + +### எவ்வாறு நீங்கள் நிதிகளைப் பெறுவீர்கள் + +முதலீட்டாளர்களுக்கு பிரித்துவழங்குதல் குறித்து ஏதேனும் தேவைகள் உள்ளனவா? எடுத்துக்காட்டாக, நீங்கள் ஒரு இலாப நோக்கமற்றவராக அல்லது லாபமற்ற நிதிய நிதியளிப்பாளராக இருக்க வேண்டும். Oஅல்லது ஒருவேளை நிதி ஒரு நிறுவனத்திற்கு பதிலாக தனிப்பட்ட ஒப்பந்தக்காரருக்கு கொடுக்கப்பட வேண்டும். இந்த தேவைகள் நிதிதாரர்களிடையே வேறுபடுகின்றன, எனவே உங்கள் ஆராய்ச்சி முன்னதாகவே செய்ய வேண்டும். + + + +## பரிசோதனை செய்யுங்கள் மற்றும் தளர்ந்துவிடாதீர்கள் + +பணத்தை உயர்த்துவது எளிதானது அல்ல, நீங்கள் ஒரு திறந்த மூல திட்டம், ஒரு இலாப நோக்கமற்ற அல்லது ஒரு மென்பொருள் துளிர் நிறுவனம், மற்றும் பெரும்பாலான சந்தர்ப்பங்களில் நீங்கள் படைப்பாற்றல் பெற்றிருக்க வேண்டும். நீங்கள் எப்படி பணம் சம்பாதிக்க வேண்டும், ஆராய்ச்சி செய்து, உங்கள் முதலீட்டாளர்களுடைய காலணிகளில் உங்களை வைத்துக் கொள்ளுதல், நிதிக்கு உறுதியான ஒரு சூழ்நிலையை உருவாக்கும். diff --git a/_articles/ta/how-to-contribute.md b/_articles/ta/how-to-contribute.md new file mode 100644 index 0000000000000000000000000000000000000000..c27a34f70708fd7928da495a0ae3252a079c5bb0 --- /dev/null +++ b/_articles/ta/how-to-contribute.md @@ -0,0 +1,522 @@ +--- +lang: ta +title: திறந்த மூலத்திற்கு எவ்வாறு பங்களிப்பது +description: திறந்த மூலத்திற்கு பங்களிக்க விரும்புகிறீர்களா? புதியவர்கள் மற்றும் துறைத்தேர்ந்தோர்க்கான, திறந்த மூல பங்களிப்புகளை உருவாக்கும் ஒரு வழிகாட்டி. +class: contribute +order: 1 +image: /assets/images/cards/contribute.png +related: + - beginners + - building +--- + +## ஏன் திறந்த மூலத்திற்கு பங்களிக்க வேண்டும்? + + + +திறந்த மூலத்திற்கான பங்களிப்பு, நீங்கள் கற்பனை செய்யக்கூடிய எந்தவொரு திறனுடனும் கற்றல், கற்பித்தல் மற்றும் அனுபவத்தை உருவாக்க ஒரு பயனளிக்கும் வழியாகும். + +ஏன் மக்கள் திறந்த மூலத்திற்கு பங்களிக்க வேண்டும்? நிறைய காரணங்கள்! + +### இருக்கும் திறன்களை மேம்படுத்தவும் + +நீங்கள் பயிற்சிக்காக குறியீட்டு, பயனர் இடைமுக வடிவமைப்பு, வரைகலை திட்டம், எழுதுதல் அல்லது ஒழுங்குபடுத்துதல் போன்றவற்றை தேடுகிறீர்கள் என்றால், திறந்த மூல திட்டத்தில் உங்களுக்கு ஒரு பணி உள்ளது. + +### ஒப்பான விஷயங்களில் ஆர்வமாக உள்ளவர்களை சந்திக்க + +நல்ல, வரவேற்பு சமூகங்களைக் கொண்ட திறந்த மூல திட்டங்கள், மக்களை பல ஆண்டுகளுக்கு பங்களிப்பை பெறுகின்றன. பல மக்கள் திறந்த மூலத்தில் பங்கேற்பதன் மூலம் வாழ்நாள் முழுவதும் நட்பை உருவாக்குகிறார்கள், இது மாநாட்டில் ஒருவருக்கொருவர் சந்திக்கவோ அல்லது பொரிட்டோஸைப் பற்றிய தாமதமான இரவு அரட்டைகளில் பேசும் வரை கொண்டு செல்லும். + +### வழிகாட்டிகளை கண்டறிதல் மற்றும் பிறருக்கு கற்பித்தல் + +ஒரு பகிர்வு திட்டத்தில் மற்றவர்களுடன் வேலை செய்வது என்றால் நீங்கள் விஷயங்களை எவ்வாறு செய்வது என்பதை விளக்க வேண்டும், மேலும் உதவிக்காக பிறரிடம் கேட்கவும். கற்றல் மற்றும் கற்பித்தல் செயல்கள் சம்பந்தப்பட்ட அனைவருக்கும் ஒரு பூரணமான செயலாகும். + +### பொது கலைப்பொருட்களை உருவாக்குவதன் மூலம் உங்கள் நற்பெயர் (மற்றும் ஒரு தொழில்) வளர உதவும் + +அடிப்படையில், உங்கள் திறந்த மூல வேலை அனைத்தையும் பொதுமக்கட்குரியது, அதாவது நீங்கள் அவற்றை இலவச செயல் விளக்கமாக எங்கு வேண்டுமானாலும் எடுத்துக்கொள்ளலாம். + +### மக்கள் திறன்களை அறிக + +திறந்த மூல தலைமை மற்றும் முகாமைத்துவ திறன்களை நடைமுறைப்படுத்துவதற்கான வாய்ப்பை வழங்குகிறது, முரண்களை தீர்ப்பது, மக்களை அணிகள் ஒழுங்குபடுத்துதல், வேலைகளை முக்கிய வரிசைப்படுத்துதல். + +### மாற்றங்கள் செய்ய அதிகாரம் அளிக்கவல்லது, சிறிய மாற்றங்களாயினும் + +திறந்த மூலத்தில் பங்கேற்க நீங்கள் வாழ்நாள் முழுவதும் பங்களிப்பு செய்ய வேண்டியதில்லை. நீங்கள் எப்போதாவது ஒரு வலைத்தளத்தில் ஒரு தட்டச்சுப் பிழையை பார்த்திருக்கிறீர்களா, யாரேனும் அதை சரிசெய்வார்கள் என கருதியிரிக்கிறீர்களா? திறந்த மூல திட்டத்தில், நீங்கள் அதை செய்ய முடியும். திறந்த மூல மக்கள் தங்கள் வாழ்வில் செயலாண்மையை உணர உதவுகிறது மற்றும் அவர்கள் உலக அனுபவத்தை பெறுவது, அதுவே மன நிறைவு தருகிறன்தாகும். + +## பங்களிப்பதின் அர்த்தம் என்ன + +நீங்கள் ஒரு புதிய திறந்த மூல பங்களிப்பாளராக இருந்தால், செயல்முறை அச்சுறுத்தும். சரியான திட்டத்தை எப்படி கண்டுபிடிப்பது? உங்களுக்கு குறியீடு தெரியாது என்றால் என்ன செய்வது? ஏதாவது தவறு நடந்தால் என்ன செய்வது? + +வருத்தப்பட வேண்டாம்! திறந்த மூல திட்டத்தில் ஈடுபடுவதற்கான எல்லாவித வழிகளும் உள்ளன, மேலும் சில உதவிக்குறிப்புகள் உங்கள் அனுபவத்தை பெருக்க மிகவும் உதவியாக இருக்கும். + +### நீங்கள் குறியீடு பங்களிக்க வேண்டியதில்லை + +திறந்த மூலத்திற்கு பங்களிப்பதைப் பற்றி பொதுவான தவறான கருத்து நீங்கள் குறியீட்டை பங்களிக்க வேண்டும். உண்மையில், இது பெரும்பாலும் ஒரு திட்டத்தின் [மிகவும் புறக்கணிக்கப்பட்ட அல்லது கண்காணிக்கவில்லை](https://github.com/blog/2195-the-shape-of-open-source) பிற பகுதிகளாகும். இந்த வகையான பங்களிப்புகளை வழங்குவதன் மூலம் நீங்கள் திட்டத்திற்கு _மிகப்பெரிய_ நன்மை செய்வீர்கள். + + + +நீங்கள் குறியீட்டை எழுத விரும்பினால் கூட, பிற வகையான பங்களிப்புகள் ஒரு திட்டத்துடன் தொடர்பு கொள்ளவும் மற்ற சமூக உறுப்பினர்களை சந்திக்கவும் சிறந்த வழியாகும். அந்த உறவுகளை கட்டியெழுப்புதல் திட்டத்தின் மற்ற பகுதிகளிலும் வேலை செய்ய உங்களுக்கு வாய்ப்பளிக்கும். + + + +### நிகழ்வு திட்டமிடல்களை விரும்புகிறீர்களா? + +* திட்டம் பற்றி பட்டறைகள் அல்லது சந்திப்புகளை ஏற்பாடு செய்யுங்கள், [@fzamperin NodeSchoolக்கு செய்ததை போல](https://github.com/nodeschool/organizers/issues/406) +* திட்டத்தின் கலந்தாய்வு ஒழுங்குபடுத்துதல் (அப்படி ஒன்று இருந்தால்) +* உதவி சமூக உறுப்பினர்கள் சரியான கலந்தாய்வுகளை கண்டுபிடித்து பேசுவதற்கான திட்டங்களை சமர்ப்பிக்கவும் + +### நீங்கள் வடிவமைக்க விரும்புகிறீர்களா? + +* திட்டத்தின் பயன்பாட்டினை மேம்படுத்துவதற்கு மறுகட்டமைப்பு வடிவமைப்புகளை அமைத்தல் +* திட்டத்தின் வழிசெலுத்தல் அல்லது பட்டியல்களை மறுசீரமைக்கவும் புதுப்பிக்கவும் பயனர் ஆராய்ச்சி நடத்திடுங்கள், [Drupal கூறுவதைப்போல்](https://www.drupal.org/community-initiatives/drupal-core/usability) +* திட்டத்தின் ஒரு நிலையான காட்சி வடிவமைப்புக்கு உதவும் ஒரு பாணி வழிகாட்டி உருவாக்கவும் +* டி-சர்ட்டுகளுக்கு ஓவியம் அல்லது புதிய சின்னம் உருவாக்கவும், [hapi.js's பங்களிப்பாளர்கள் செய்ததைப்போல](https://github.com/hapijs/contrib/issues/68) + +### நீங்கள் எழுத விரும்புகிறீர்களா? + +* திட்டத்தின் ஆவணங்களை எழுதுவது மற்றும் மேம்படுத்துவது +* திட்டம் எவ்வாறு பயன்படுத்தப்படுகிறது என்பதை காட்டும் உதாரணங்கள் ஒரு கோப்புறையை தொகுத்தல் +* திட்டத்திற்கான ஒரு செய்திமடலைத் தொடங்கவும் அல்லது அஞ்சல் பட்டியலிலிருந்த சிறப்பம்சங்களைக் தொகுக்கவும் +* திட்டத்திற்கான பயிற்சியை எழுதுங்கள், [PyPA's பங்களிப்பாளர்கள் செய்ததைப்போல](https://github.com/pypa/python-packaging-user-guide/issues/194) +* திட்டத்தின் ஆவணங்களுக்கான ஒரு மொழிபெயர்ப்பை எழுதுங்கள் + + + +### உங்களுக்கு ஒழுங்குபடுத்துவதில் விருப்பமுண்டா? + +* விஷயங்களை ஒழுங்காக வைக்க, நகல் சிக்கல்களை இணைக்கவும், புதிய சிக்கல் அடையாளச் சிட்டை பரிந்துரைக்கவும் +* திறந்த சிக்கல்களில் பழையவற்றை மூடுமாறு பரிந்துரைக்கவும், [@nzakas ESLint-ல் செய்ததைப்போல](https://github.com/eslint/eslint/issues/6765) +* விவாதத்தை முன்னோக்கி நகர்த்துவதற்காக சமீபத்தில் திறக்கப்பட்ட சிக்கல்கள் குறித்து கேள்விகளைக் கேளுங்கள் + +### நீங்கள் குறிமுறையாக்கத்தை விரும்புகிறீர்களா? + +* ஒரு திறந்த சிக்கலைக் கண்டறிந்து கையாளுதல், [@dianjin Leaflet-ல் செய்ததைப்போல](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) +* புதிய அம்சத்தை எழுதுவதற்கு நீங்கள் உதவ முடியுமா எனக் கேளுங்கள் +* தானியங்கு திட்டம் அமைப்பு +* கருவியாக்கல் மற்றும் சோதனைகளை மேம்படுத்தவும் + +### நீங்கள் மக்களுக்கு உதவ விரும்புகிறீர்களா? + +* திட்டத்தின் பற்றிய கேள்விகளுக்கு பதிலளிக்கவும் எ.கா., Stack Overflow ([இந்த Postgres உதாரணம் போல](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) அல்லது Reddit +* திறந்த சிக்கல்கள் உள்ளவர்களின் கேள்விகளுக்கு விடையளிக்கவும் +* கலந்துரையாடல் பலகைகள் அல்லது உரையாடல் தடங்களை மிதமாக்க உதவுங்கள் + +### நீங்கள் மற்றவர்களுக்கான குறியீடுக்கு உதவ விரும்புவரா? + +* மற்றவர்களின் குறியீடு சமர்ப்பிப்புகளை மதிப்பாய்வு செய்தல் +* ஒரு திட்டம் எவ்வாறு பயன்படுத்தப்படலாம் என்ற பயிற்சியை எழுதுங்கள் +* மற்றொரு பங்களிப்பாளருக்கு வழிகாட்டியாக இருத்ததலதல்,[@ereichert @bronzdocக்கு Rustல் இருந்ததைப்போல](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) + +### நீங்கள் மென்பொருள் திட்டங்களில் மட்டுமே வேலை செய்ய வேண்டியதில்லை! + +"திறந்த மூலம்" பெரும்பாலும் மென்பொருளைக் குறிக்கும் போது, நீங்கள் எதைப் பற்றியும் கூடி வேலைச்செய்யயலாம். திறந்த மூல திட்டங்களாக உருவாக்கப்பட்ட புத்தகங்கள், சமையல் குறிப்புகள், பட்டியல்கள் மற்றும் வகுப்புகள் உள்ளன. + +உதாரணத்திற்கு: + +* @sindresorhus ["அற்புதமான" பட்டியல்களின் பட்டியல்](https://github.com/sindresorhus/awesome) தொகுத்தார் +* @h5bp முன்-முனை மேம்பாட்டர் தேர்வர்களுக்கான [சாத்தியமான நேர்காணல் கேள்விகளை](https://github.com/h5bp/Front-end-Developer-Interview-Questions) பராமரிக்கிறார் +* @stuartlynn மற்றும் @nicole-a-tesla [puffins-பெரிய அலகுடைய கடற்பறவைகள் பற்றி வேடிக்கை உண்மைகள் சேகரிப்பு](https://github.com/stuartlynn/puffin_facts) செய்தனர் + +நீங்கள் ஒரு மென்பொருள் உருவாக்குநராக இருந்தாலும்கூட, ஆவணங்கள் திட்டத்தில் பணிபுரியும் திறந்த மூலத்தில் நீங்கள் தொடங்குவதற்கு உதவலாம். இது குறியீட்டை உள்ளடக்கிய திட்டங்களில் பணிபுரியும் அளவுக்கு குறைவான அச்சுறுத்தலாகும், மற்றும் ஒத்துழைப்பு செயல்முறை உங்களுக்கு நம்பிக்கையும் அனுபவத்தையும் உருவாக்கும். + +## ஒரு புதிய திட்டத்திற்காக உங்களை நெறிப்படுத்துதல் + + + +ஒரு தட்டச்சுப் பிழையை சரி செய்வதை விட அதிகம், ஓப்பன் சோர்ஸ் பங்களிப்பு என்பது அந்நியர்களின் கொண்டாட்டத்தில் ஒரு குழுவினருடன் நடப்பது போலாகும். அவர்கள் தங்கமீன் பற்றி ஒரு விவாதத்தில் ஆழமாக இருந்தபோது, நீங்கள் இலாமா (கம்பள ஒட்டக இனம்) பற்றி பேச ஆரம்பித்தால், அவர்கள் ஒருவேளை உங்களை ஒரு வித்தியாசமான முறையில் பார்ப்பார்கள். + +உங்கள் சொந்த ஆலோசனையுடன் கண்மூடித்தனமாக குதிக்கும்முன், அறையை படிக்க எப்படி கற்பது என்பதிலிருந்து தொடங்கவும். அவ்வாறு செய்யும்போது, உங்கள் கருத்துக்கள் கவனிக்கப்பட்டு, கேட்கப்படும் வாய்ப்புகளை அதிகரிக்கிறது. + +### திறந்த மூல திட்டத்தின் உடற்கூறியல் + +ஒவ்வொரு திறந்த மூல சமூகமும் மாறுபட்டவை. + +ஒரு திறந்த மூல திட்டத்தில் ஆண்டுகள் செலவழித்து நீங்கள் ஒரு திறந்த மூல திட்டத்தை அறிந்து கொள்ள முடிந்தது. வேறொரு திட்டத்திற்கு செல்லும் பொழுது, சொல்லகராதி, நெறிமுறைகள் மற்றும் தகவல்தொடர்பு பாணிகள் முற்றிலும் வேறுபட்டதாக காணலாம். + +பல திறந்த மூல திட்டங்கள் இதே அமைப்பு முறையை பின்பற்றின. வெவ்வேறு சமூகப் பணிகளைப் புரிந்துகொள்வது மற்றும் மொத்த செயல்முறை ஆகியவை எந்தவொரு புதிய திட்டத்திற்கும் விரைவாகப் பெற உதவும். + +ஒரு பொதுவான திறந்த மூல திட்டம் பின்வரும் வகையான மக்களைக் கொண்டுள்ளது: + +* **படைப்பாளர்:** திட்டத்தை உருவாக்கிய நபர்/கள் அல்லது அமைப்பு +* **உரிமையாளர்:** அமைப்பு அல்லது களஞ்சியத்தில் நிர்வாக உரிமையுள்ள நபர்/கள்(எப்போதும் அசல் படைப்பாளர் அல்ல) +* **பராமரிப்பாளர்கள்:** திட்டத்தின் நோக்கம் மற்றும் நிறுவன அம்சங்களை நிர்வகிப்பதற்கும் பொறுப்புள்ள பங்களிப்பாளர்கள். (அவர்கள் திட்டத்தின் படைப்பாளர்கள் அல்லது உரிமையாளர்களாக இருக்கலாம்.) +* **பங்களிப்பாளர்கள்:** திட்டத்திற்கு ஏதேனும் பங்களித்த அனைவருக்கும். +* **சமூக உறுப்பினர்கள்:** திட்டத்தை பயன்படுத்தும் மக்கள். அவர்கள் உரையாடலில், செயலில் அல்லது திட்டத்தின் திசையைப் பற்றி தங்கள் கருத்தை தெரிவிக்கலாம். + +பெரிய திட்டங்கள், உபகாரம், சமுதாயம் மிதமிடுதல் மற்றும் நிகழ்வு ஏற்பாடு போன்ற பல்வேறு பணிகளைக் கருத்தில் கொண்ட உப குழு அல்லது பணிக்குழுக்கள் இருக்கலாம். இந்தத் தகவலைக் கண்டறிய, ஒரு "குழு" பக்கத்திற்கான ஒரு திட்டத்தின் வலைத்தளத்தைப் பார்க்கவும், அல்லது ஆட்சி ஆவணத்திற்கான களஞ்சியத்தில் பாருங்கள். + +ஒரு திட்டத்தில் ஆவணங்களும் உள்ளன. இந்த கோப்புகள் வழக்கமாக ஒரு களஞ்சியத்தின் மேல் மட்டத்தில் பட்டியலிடப்பட்டுள்ளன. + +* **உரிமம்(LICENSE):** வரையறையின்படி, ஒவ்வொரு திறந்த மூல திட்டமும் [திறந்த மூல உரிமத்தை](https://choosealicense.com) கொண்டிருக்க வேண்டும். திட்டத்திற்கு ஒரு உரிமம் இல்லை என்றால், அது திறந்த மூலம் அல்ல. +* **என்னைவாசி(README):** README என்பது புதிய சமூக உறுப்பினர்களை திட்டத்திற்கு வரவேற்கும் வழிமுறை கையேடு ஆகும். ஏன் திட்டம் பயனுள்ளதாக இருக்கும் மற்றும் எப்படி தொடங்குவது என இது விளக்குகிறது. +* **பங்களிப்பு(CONTRIBUTING):** READMEs மக்கள் உதவுகிறது திட்டத்தை _பயன்படுத்த_ உதவுகிறது, CONTRIBUTING ஆவணங்கள் திட்டத்திற்கு மக்கள் _பங்களிக்க_ உதவுகிறது. இது எவ்விதமான பங்களிப்புகள் தேவைப்படுகின்றன மற்றும் செயல்முறை எவ்வாறு செயல்படுகிறது என்பதையும் இது விளக்குகிறது. ஒவ்வொரு திட்டமும் ஒரு பங்களிப்புக் கோப்பில் இல்லை என்றாலும், அதன் இருப்பு சமிக்ஞைகள் இது பங்களிக்க ஒரு வரவேற்புத் திட்டம் ஆகும். +* **நடத்தை_குறியீடு(CODE_OF_CONDUCT):** நடத்தை குறியீடு தொடர்புடைய பங்கேற்பாளர்கள் நடத்தை தர விதிகள் அமைக்கிறது மற்றும் ஒரு நட்பு, வரவேற்பு சூழலை எளிதாக்கும் உதவுகிறது. ஒவ்வொரு திட்டமும் CODE_OF_CONDUCT கோப்பைக் கொண்டிருக்கவில்லை என்றாலும், இது பங்களிப்பு செய்வதற்கான வரவேற்புத் திட்டம் என்று அதன் இருப்பு சமிக்ஞைகள் உள்ளன. +* **பிற ஆவணங்கள்:** பயிற்சிகள், மேலோட்டப்பார்வைகள் அல்லது ஆளுமைக் கொள்கை போன்ற கூடுதல் ஆவணங்கள் இருக்கலாம், குறிப்பாக பெரிய திட்டங்களில். + +இறுதியாக, திறந்த மூல திட்டங்கள் விவாதத்தை ஒழுங்கமைக்க பின்வரும் கருவிகளைப் பயன்படுத்துகின்றன. ஆவணக்கிடங்குகளை படித்தல் மூலம் சமூகம் எப்படி சிந்திக்கிறது மற்றும் வேலை செய்கிறது என அறிய முடியும். + +* **சிக்கல் தடமி(Issue tracker):** திட்டப்பணியுடன் தொடர்புடைய பிரச்சினைகளை மக்கள் விவாதிக்கும் இடம். +* **இழு கோரிக்கைகள்(Pull requests):** முன்னேற்றத்தில் இருக்கும் மாற்றங்களை விவாதிக்கும் மற்றும் மதிப்பாய்வு செய்யுமிடம். +* **கலந்துரையாடல் மன்றங்கள் அல்லது அஞ்சல் பட்டியல்கள்:** சில திட்டங்கள் இந்த உரையாடல்களை உரையாடல் தலைப்புகளில் பயன்படுத்தலாம் (எடுத்துக்காட்டாக, _"நான் எப்படி ..."_ அல்லது _"என்ன நினைக்கிறீர்கள் ..."_ பிழை அறிக்கைகள் அல்லது அம்ச கோரிக்கைகளுக்கு பதிலாக). மற்றவர்கள் எல்லா உரையாடல்களுக்கும் சிக்கல் தடமியை பயன்படுத்துகின்றனர். +* **ஒத்திசைவு அரட்டை அலைத்தடம்:** சில திட்டங்கள் சாதாரண உரையாடல், ஒத்துழைப்பு, மற்றும் விரைவான பரிமாற்றங்களுக்கான அரட்டைத் தடங்களை (Slack அல்லது IRC போன்றவற்றை) பயன்படுத்துகின்றன. + +## பங்களிக்க ஒரு திட்டத்தை கண்டறிதல் + +இப்பொழுது திறந்த மூல திட்டங்கள் எப்படி இயங்குகின்றன என்பதை நீங்கள் அறிந்தீர்கள், இது பங்களிக்க ஒரு திட்டத்தை கண்டறியும் நேரம்! + +நீங்கள் இதற்கு முன்னர் திறந்த மூலத்திற்கு பங்களித்திருக்கவில்லை எனில், அமெரிக்க ஜனாதிபதி ஜான் எஃப். கென்னடி சில ஆலோசனையை எடுத்துக் கொண்டால், "நாடு உங்களுக்கு என்ன செய்தது என்று கேட்காதீர்கள் - நீங்கள் நாட்டிற்கு என்ன செய்ய முடியும் என்று கேளுங்கள்." + +திறந்த மூலத்திற்கான பங்களிப்பு, அனைத்து மட்டங்களிலும் திட்டங்கள்தோறும் நடக்கிறது. உங்களுடைய முதல் பங்களிப்பு என்னவாக இருக்கும், அல்லது அது எப்படி இருக்கும் என்பதை நீங்கள் அதிகம் ஆலோசனை செய்ய வேண்டியதில்லை. + +அதற்கு பதிலாக, நீங்கள் ஏற்கனவே பயன்படுத்திய, அல்லது பயன்படுத்த விரும்பும் திட்டங்களை பற்றி யோசித்து தொடங்கவும். நீங்கள் தீவிரமாக பங்களித்த திட்டங்களை நீங்கள் திரும்பி வருகிறீர்கள். + +அந்த திட்டங்களுள், எப்போதாவது நீங்கள் ஏதாவது ஒன்றை சிறப்பாக அல்லது வித்தியாசமாக இருந்திருக்கலாம் என கருதுவீர்கள், உங்கள் உள்ளுணர்வு சொல்வதைக் கேட்டு செயல்படுங்கள். + +திறந்த மூலமானது ஒரு பிரத்யேக சங்கம் அல்ல; இது உங்களைப் போன்ற மக்கள் உருவாக்கியது. உலகின் பிரச்சினைகளை சரிசெய்யக்கூடிய வகையில் "திறந்த மூல" என்பது ஒரு கற்பனையான சொல். + +நீங்கள் ஒரு README ஐ ஸ்கேன் செய்து உடைந்த இணைப்பு அல்லது ஒரு தட்டச்சுப் பிழையை காணலாம். அல்லது நீங்கள் புதிய பயனராக இருக்கின்றீர்கள், நீங்கள் ஏதாவது உடைந்துவிட்டதா என்று கவனித்தீர்களா அல்லது ஒரு சிக்கல் ஆவணத்தில் இருக்க வேண்டும் என்று நீங்கள் நினைக்கிறீர்களா . அதை புறக்கணித்துவிட்டு, நகர்த்துவதற்கு அல்லது வேறு யாராவது அதை சரிசெய்வதற்குப் பதிலாக, நீங்கள் உந்துதல் மூலம் உதவ முடியுமா என்பதைப் பார்க்கவும். + +> திறந்த மூலத்திற்கான [28% தற்காலிக பங்களிப்புகள்](https://www.igor.pro.br/publica/papers/saner2016.pdf) ஒரு தட்டச்சுப் பிழை சரி செய்வது, மறுசீரமைப்பு அல்லது மொழிபெயர்ப்பு எழுதுதல் போன்ற ஆவணங்கள் ஆகும். + +நீங்கள் புதிய திட்டங்களை கண்டறிய மற்றும் பங்களிக்க உதவுவதற்கு பின்வரும் வளங்களில் ஒன்றைப் பயன்படுத்தலாம்: + +* [கிட்ஹப் ஆராய்தல்](https://github.com/explore/) +* [திறந்த மூல வெள்ளிக்கிழமை](https://opensourcefriday.com) +* [முதல் முறையாளர்கள் மட்டுமே](https://www.firsttimersonly.com/) +* [CodeTriage](https://www.codetriage.com/) +* [24 இழு கோரிக்கைகள்](https://24pullrequests.com/) +* [Up For Grabs](https://up-for-grabs.net/) +* [பங்களிப்பாளர்-நிஞ்ஜா](https://contributor.ninja) +* [முதல் பங்களிப்புகள்](https://firstcontributions.github.io) +* [SourceSort](https://www.sourcesort.com/) + +### பங்களிக்கும் முன் ஒரு சரிபார்ப்புப் பட்டியல் + +நீங்கள் பங்களிக்க விரும்பும் ஒரு திட்டத்தை நீங்கள் கண்டறிந்தால், பங்களிப்புகளை ஏற்றுக்கொள்வதற்கு திட்டம் பொருத்தமானதா என்பதை உறுதிப்படுத்த விரைவான ஆய்வு செய்யுங்கள். இல்லையெனில், உங்களுடைய கடின உழைப்பு ஒரு மறு மொழியை பெறாது. + +ஒரு திட்டம் புதிய பங்களிப்பாளர்களுக்கு பொருத்தமானதா என்பதை மதிப்பீடு செய்வதற்கான ஒரு கையேடு பட்டியல். + +**திறந்த மூலத்தின் வரையறைகளை சந்திக்கிறது** + +-— @kfogel, [_打造开源软件_](http://producingoss.com/en/producingoss.html#common-pitfalls) +— @kfogel, [_打造开源软件_](https://producingoss.com/en/producingoss.html#common-pitfalls)
@@ -281,6 +278,6 @@ Atom Issues不存在投票系统的部分原因是因为Atom团队在所有情 使用决策者应该是你们最后才能采取的手段。分离issues是一个你们社区成长和学习的机会。利用这些机会并精诚合作，尽量找出问题的解决方案。 -## Community is the ❤️ of open source +## 社区是开源的❤️ 健康，蓬勃的社区每周都会为开源付出大量辛勤的劳动。许多贡献者指出其他人在开源工作或不在开源工作的原因。通过学习如何建设性地利用这股力量，你们会帮助他人有一个难忘的开源体验。 diff --git a/_articles/zh-cn/code-of-conduct.md b/_articles/zh-hans/code-of-conduct.md similarity index 91% rename from _articles/zh-cn/code-of-conduct.md rename to _articles/zh-hans/code-of-conduct.md index dc76262339cac3c574f11bf26e0c39a5d378b081..5b88b4f89ed1c7d7ee3e955004ff0f880678d963 100644 --- a/_articles/zh-cn/code-of-conduct.md +++ b/_articles/zh-hans/code-of-conduct.md @@ -1,21 +1,17 @@ --- -lang: zh-cn +lang: zh-hans title: 行为准则 description: 社区的长远发展和健康成长，离不开一些行为准则，需要遵守并执行。 class: coc -toc: - why-do-i-need-a-code-of-conduct: "我为什么需要行为守则?" - establishing-a-code-of-conduct: "建立行为守则" - deciding-how-youll-enforce-your-code-of-conduct: "决定你们如何执行行为守则" - enforcing-your-code-of-conduct: "执行你们的行为守则" order: 8 image: /assets/images/cards/coc.png related: - building - leadership +redirect_from: /zh-cn/code-of-conduct/ --- -## Why do I need a code of conduct? +## 为什么我们需要行为守则？ 行为守则是一份确立项目参与者行为规范的文件。采用和执行行为守则可以帮助你们的社区营造积极的氛围。 @@ -23,7 +19,7 @@ related: 一份行为守则可以帮助你们促进健康，有建设性的社区行为。积极主动减少你们或其他人在你们的项目中变得疲劳的可能性，并帮助你们在有人做出你们不同意的事情时采取行动。 -## Establishing a code of conduct +## 建立一个行为守则 尽可能早地建立行为守则，当你们第一次创建项目的时候。 @@ -34,13 +30,13 @@ related: * 如果有人违反了行为守则会怎样？ * 大家如何举报违规 -无论你们在哪里，请使用已有的行为守则。[贡献者盟约](http://contributor-covenant.org/)是一个被超过40，000个开源项目（包括Kubernetes, Rails和Swift）所使用的行为守则。 +无论你们在哪里，请使用已有的行为守则。[贡献者盟约](https://www.contributor-covenant.org/)是一个被超过40,000个开源项目（包括Kubernetes, Rails和Swift）所使用的行为守则。 [Django行为守则](https://www.djangoproject.com/conduct/)和[Citizen行为守则](http://citizencodeofconduct.org/)都是非常好的行为守则。 请将CODE_OF_CONDUCT文件放在你们项目的根目录，并在README中附上其链接，这样对你们的社区是可见的。 -## Deciding how you'll enforce your code of conduct +## 决定你们如何执行行为守则