From a8e3a2d1b646608b9bd8e451decdd302572639af Mon Sep 17 00:00:00 2001 From: minwook Date: Tue, 10 Oct 2017 16:42:09 +0900 Subject: [PATCH 01/87] starting korean translation --- _config.yml | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/_config.yml b/_config.yml index f84f154536c..5a258cf71b0 100644 --- a/_config.yml +++ b/_config.yml @@ -1,12 +1,12 @@ -title: "Open Source Guides" -description: "Learn how to launch and grow your project." +title: "오픈소스 가이드" +description: "프로젝트를 시작하고 성장시키는 방법에 대해 알아보십시오." # See: docs/translations.md -locale: en-US +locale: ko-KR translations: - en-US: - name: English (US) - url: https://opensource.guide + ko-KR: + name: Korean + url: https://minwook-shin.github.io/open-source-guide/ exclude: - bin From 20b659b2790fb0a4a78f0ca865954d3e82578964 Mon Sep 17 00:00:00 2001 From: minwook Date: Tue, 10 Oct 2017 16:54:42 +0900 Subject: [PATCH 02/87] chagne eng to kor --- _data/locale/ko-KR.yml | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 _data/locale/ko-KR.yml diff --git a/_data/locale/ko-KR.yml b/_data/locale/ko-KR.yml new file mode 100644 index 00000000000..100104da17f --- /dev/null +++ b/_data/locale/ko-KR.yml @@ -0,0 +1,29 @@ +nav: + about: 이것에 관하여 + contribute: 기여 + +index: + lead: 오픈 소스 소프트웨어는 당신과 비슷한 사람들이 만듭니다. 프로젝트를 시작하고 성장시키는 방법에 대해 배워보십시오. + +article: + table_of_contents: 목차 + +footer: + contribute: + heading: 기여 + description: 제안 하기 원하시나요? 이 내용은 오픈 소스입니다.개선 할 수 있도록 도와주세요. + button: 기여하기 + subscribe: + heading: 계속 소식 받기 + description: GitHub의 최신 오픈 소스 팁과 리소스에 대해 먼저 들어보십시오. + label: 이메일 주소 + button: 구독하기 + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] with [love] by [github] and [friends]" + # Label for code octicon + code_label: 코드 + # Label for love octicon + love_label: 사랑 + # Label for the contributors link + friends_label: 친구 From 1cdd37de2c903677ff7625d42e251260997dda6f Mon Sep 17 00:00:00 2001 From: minwook Date: Tue, 10 Oct 2017 16:57:01 +0900 Subject: [PATCH 03/87] starting article korean translation --- _articles/ko-KR/best-practices.md | 279 ++++++++++ _articles/ko-KR/building-community.md | 279 ++++++++++ _articles/ko-KR/code-of-conduct.md | 119 +++++ _articles/ko-KR/finding-users.md | 165 ++++++ _articles/ko-KR/getting-paid.md | 188 +++++++ _articles/ko-KR/how-to-contribute.md | 528 +++++++++++++++++++ _articles/ko-KR/leadership-and-governance.md | 164 ++++++ _articles/ko-KR/legal.md | 165 ++++++ _articles/ko-KR/metrics.md | 132 +++++ _articles/ko-KR/starting-a-project.md | 369 +++++++++++++ 10 files changed, 2388 insertions(+) create mode 100644 _articles/ko-KR/best-practices.md create mode 100644 _articles/ko-KR/building-community.md create mode 100644 _articles/ko-KR/code-of-conduct.md create mode 100644 _articles/ko-KR/finding-users.md create mode 100644 _articles/ko-KR/getting-paid.md create mode 100644 _articles/ko-KR/how-to-contribute.md create mode 100644 _articles/ko-KR/leadership-and-governance.md create mode 100644 _articles/ko-KR/legal.md create mode 100644 _articles/ko-KR/metrics.md create mode 100644 _articles/ko-KR/starting-a-project.md diff --git a/_articles/ko-KR/best-practices.md b/_articles/ko-KR/best-practices.md new file mode 100644 index 00000000000..55571ce0607 --- /dev/null +++ b/_articles/ko-KR/best-practices.md @@ -0,0 +1,279 @@ +--- +locale: en-US +title: Best Practices for Maintainers +description: Making your life easier as an open source maintainer, from documenting processes to leveraging your community. +class: best-practices +toc: + what-does-it-mean-to-be-a-maintainer: "What does it mean to be a maintainer?" + documenting-your-processes: "Documenting your processes" + learning-to-say-no: "Learning to say no" + leverage-your-community: "Leverage your community" + bring-in-the-robots: "Bring in the robots" + its-okay-to-hit-pause: "It’s okay to hit pause" +order: 5 +image: /assets/images/cards/best-practices.png +related: + - metrics + - leadership +--- + +## What does it mean to be a maintainer? + +If you maintain an open source project that a lot of people use, you may have noticed you're coding less and responding to issues more. + +In the early stages of a project, you're experimenting with new ideas and making decisions based on what you want. As your project increases in popularity, you'll find yourself working with your users and contributors more. + +Maintaining a project requires more than code. These tasks are often unexpected, but they're just as important to a growing project. We've gathered a few ways to make your life easier, from documenting processes to leveraging your community. + +## Documenting your processes + +Writing things down is one of the most important things you can do as a maintainer. + +Documentation not only clarifies your own thinking, but it helps other people understand what you need or expect, before they even ask. + +Writing things down makes it easier to say no when something doesn't fit into your scope. It also makes it easier for people to pitch in and help. You never know who might be reading or using your project. + +Even if you don't use full paragraphs, jotting down bullet points is better than not writing at all. + +### Write down your project's vision + +Start by writing down the goals of your project. Add them to your README, or create a separate file called VISION. If there are other artifacts that could help, like a project roadmap, make those public as well. + +Having a clear, documented vision keeps you focused and helps you avoid "scope creep" from others' contributions. + +For example, @lord discovered that having a project vision helped him figure out which requests to spend time on. As a new maintainer, he regretted not sticking to his project's scope when he got his first feature request for [Slate](https://github.com/lord/slate). + + + +### Communicate your expectations + +Rules can be nerve-wracking to write down. Sometimes you might feel like you're policing other people's behavior or killing all the fun. + +Written and enforced fairly, however, good rules empower maintainers. They prevent you from getting dragged into doing things you don't want to do. + +Most people who come across your project don't know anything about you or your circumstances. They may assume you get paid to work on it, especially if it's something they regularly use and depend on. Maybe at one point you put a lot of time into your project, but now you're busy with a new job or family member. + +All of this is perfectly okay! Just make sure other people know about it. + +If maintaining your project is part-time or purely volunteered, be honest about how much time you have. This is not the same as how much time you think the project requires, or how much time others want you to spend. + +Here are a few rules that are worth writing down: + +* How a contribution is reviewed and accepted (_Do they need tests? An issue template?_) +* The types of contributions you'll accept (_Do you only want help with a certain part of your code?_) +* When it's appropriate to follow up (_ex. "You can expect a response from a maintainer within 7 days. If you haven't heard anything by then, feel free to ping the thread."_) +* How much time you spend on the project (_ex. "We only spend about 5 hours per week on this project"_) + +[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) are several examples of projects with ground rules for maintainers and contributors. + +### Keep communication public + +Don't forget to document your interactions, too. Wherever you can, keep communication about your project public. If somebody tries to contact you privately to discuss a feature request or support need, politely direct them to a public communication channel, such as a mailing list or issue tracker. + +If you meet with other maintainers, or make a major decision in private, document these conversations in public, even if it's just posting your notes. + +That way, anybody who joins your community will have access to the same information as someone who's been there for years. + +## Learning to say no + +You've written things down. Ideally, everybody would read your documentation, but in reality, you'll have to remind others that this knowledge exists. + +Having everything written down, however, helps depersonalize situations when you do need to enforce your rules. + +Saying no isn't fun, but _"Your contribution doesn't match this project's criteria"_ feels less personal than _"I don't like your contribution"_. + +Saying no applies to many situations you'll come across as a maintainer: feature requests that don't fit the scope, someone derailing a discussion, doing unnecessary work for others. + +### Keep the conversation friendly + +One of the most important places you'll practice saying no is on your issue and pull request queue. As a project maintainer, you'll inevitably receive suggestions that you don't want to accept. + +Maybe the contribution changes your project's scope or doesn't match your vision. Maybe the idea is good, but the implementation is poor. + +Regardless of the reason, it is possible to tactfully handle contributions that don't meet your project's standards. + +If you receive a contribution you don't want to accept, your first reaction might be to ignore it or pretend you didn't see it. Doing so could hurt the other person's feelings and even demotivate other potential contributors in your community. + + + +Don't leave an unwanted contribution open because you feel guilty or want to be nice. Over time, your unanswered issues and PRs will make working on your project feel that much more stressful and intimidating. + +It's better to immediately close the contributions you know you don't want to accept. If your project already suffers from a large backlog, @steveklabnik has suggestions for [how to triage issues efficiently](http://words.steveklabnik.com/how-to-be-an-open-source-gardener). + +Secondly, ignoring contributions sends a negative signal to your community. Contributing to a project can be intimidating, especially if it's someone's first time. Even if you don't accept their contribution, acknowledge the person behind it and thank them for their interest. It's a big compliment! + +If you don't want to accept a contribution: + +* **Thank them** for their contribution +* **Explain why it doesn't fit** into the scope of the project, and offer clear suggestions for improvement, if you're able. Be kind, but firm. +* **Link to relevant documentation**, if you have it. If you notice repeated requests for things you don't want to accept, add them into your documentation to avoid repeating yourself. +* **Close the request** + +You shouldn't need more than 1-2 sentences to respond. For example, when a user of [celery](https://github.com/celery/celery/) reported a Windows-related error, @berkerpeksag [responded with](https://github.com/celery/celery/issues/3383): + +![Celery screenshot](/assets/images/best-practices/celery.png) + +If the thought of saying no terrifies you, you're not alone. As @jessfraz [put it](https://blog.jessfraz.com/post/the-art-of-closing/): + +> 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. + +Don't feel guilty about not wanting to accept someone's contribution. The first rule of open source, [according to](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"No is temporary, yes is forever."_ While empathizing with another person's enthusiasm is a good thing, rejecting a contribution is not the same as rejecting the person behind it. + +Ultimately, if a contribution isn't good enough, you're under no obligation to accept it. Be kind and responsive when people contribute to your project, but only accept changes that you truly believe will make your project better. The more often you practice saying no, the easier it becomes. Promise. + +### Be proactive + +To reduce the volume of unwanted contributions in the first place, explain your project's process for submitting and accepting contributions in your contributing guide. + +If you're receiving too many low-quality contributions, require that contributors do a bit of work beforehand, for example: + +* Fill out a issue or PR template/checklist +* Open an issue before submitting a PR + +If they don't follow your rules, close the issue immediately and point to your documentation. + +While this approach may feel unkind at first, being proactive is actually good for both parties. It reduces the chance that someone will put in many wasted hours of work into a pull request that you aren't going to accept. And it makes your workload easier to manage. + + + +Sometimes, when you say no, your potential contributor may get upset or criticize your decision. If their behavior becomes hostile, [take steps to defuse the situation](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) or even remove them from your community, if they're not willing to collaborate constructively. + +### Embrace mentorship + +Maybe someone in your community regularly submits contributions that don't meet your project's standards. It can be frustrating for both parties to repeatedly go through rejections. + +If you see that someone is enthusiastic about your project, but needs a bit of polish, be patient. Explain clearly in each situation why their contributions don't meet the expectations of the project. Try pointing them to an easier or less ambiguous task, like an issue marked _"good first bug,"_ to get their feet wet. If you have time, consider mentoring them through their first contribution, or find someone else in your community who might be willing to mentor them. + +## Leverage your community + +You don't have to do everything yourself. Your project's community exists for a reason! Even if you don't yet have an active contributor community, if you have a lot of users, put them to work. + +### Share the workload + +If you're looking for others to pitch in, start by asking around. + +When you see new contributors making repeated contributions, recognize their work by offering more responsibility. Document how others can grow into leadership roles if they wish. + +Encouraging others to [share ownership of the project](../building-community/#share-ownership-of-your-project) can greatly reduce your own workload, as @lmccart discovered on her project, [p5.js](https://github.com/processing/p5.js?files=1). + + + +If you need to step away from your project, either on hiatus or permanently, there's no shame in asking someone else to take over for you. + +If other people are enthusiastic about its direction, give them commit access or formally hand over control to someone else. If someone forked your project and is actively maintaining it elsewhere, consider linking to the fork from your original project. It's great that so many people want your project to live on! + +@progrium [found that](http://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) documenting the vision for his project, [Dokku](https://github.com/dokku/dokku), helped those goals live on even after he stepped away from the project: + +> 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. + +### Let others build the solutions they need + +If a potential contributor has a different opinion on what your project should do, you may want to gently encourage them to work on their own fork. + +Forking a project doesn't have to be a bad thing. Being able to copy and modify projects is one of the best things about open source. Encouraging your community members to work on their own fork can provide the creative outlet they need, without conflicting with your project's vision. + + + +The same applies to a user who really wants a solution that you simply don't have the bandwidth to build. Offering APIs and customization hooks can help others meet their own needs, without having to modify the source directly. @orta [found that](http://artsy.github.io/blog/2016/07/03/handling-big-projects/) encouraging plugins for CocoaPods led to "some of the most interesting ideas": + +> 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. + +## Bring in the robots + +Just as there are tasks that other people can help you with, there are also tasks that no human should ever have to do. Robots are your friend. Use them to make your life as a maintainer easier. + +### Require tests and other checks to improve the quality of your code + +One of the most important ways you can automate your project is by adding tests. + +Tests help contributors feel confident that they won't break anything. They also make it easier for you to review and accept contributions quickly. The more responsive you are, the more engaged your community can be. + +Set up automatic tests that will run on all incoming contributions, and ensure that your tests can easily be run locally by contributors. Require that all code contributions pass your tests before they can be submitted. You'll help set a minimum standard of quality for all submissions. [Required status checks](https://help.github.com/articles/about-required-status-checks/) on GitHub can help ensure no change gets merged without your tests passing. + +If you add tests, make sure to explain how they work in your CONTRIBUTING file. + + + +### Use tools to automate basic maintenance tasks + +The good news about maintaining a popular project is that other maintainers have probably faced similar issues and built a solution for it. + +There are a [variety of tools available](https://github.com/showcases/tools-for-open-source) to help automate some aspects of maintenance work. A few examples: + +* [semantic-release](https://github.com/semantic-release/semantic-release) automates your releases +* [mention-bot](https://github.com/facebook/mention-bot) mentions potential reviewers for pull requests +* [Danger](https://github.com/danger/danger) helps automate code review + +For bug reports and other common contributions, GitHub has [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates), which you can create to streamline the communication you receive. You can also set up [email filters](https://github.com/blog/2203-email-updates-about-your-own-activity) to manage your email notifications. + +If you want to get a little more advanced, style guides and linters can standardize project contributions and make them easier to review and accept. + +However, if your standards are too complicated, they can increase the barriers to contribution. Make sure you're only adding enough rules to make everyone's lives easier. + +If you're not sure which tools to use, look at what other popular projects do, especially those in your ecosystem. For example, what does the contribution process look like for other Node modules? Using similar tools and approaches will also make your process more familiar to your target contributors. + +## It's okay to hit pause + +Open source work once brought you joy. Maybe now it's starting to make you feel avoidant or guilty. + +Perhaps you're feeling overwhelmed or a growing sense of dread when you think about your projects. And meanwhile, the issues and pull requests pile up. + +Burnout is a real and pervasive issue in open source work, especially among maintainers. As a maintainer, your happiness is a non-negotiable requirement for the survival of any open source project. + +Although it should go without saying, take a break! You shouldn't have to wait until you feel burned out to take a vacation. @brettcannon, a Python core developer, decided to take [a month-long vacation](http://www.snarky.ca/why-i-took-october-off-from-oss-volunteering) after 14 years of volunteer OSS work. + +Just like any other type of work, taking regular breaks will keep you refreshed, happy, and excited about your work. + + + +Sometimes, it can be hard to take a break from open source work when it feels like everybody needs you. People may even try to make you feel guilty for stepping away. + +Do your best to find support for your users and community while you're away from a project. If you can't find the support you need, take a break anyway. Be sure to communicate when you're not available, so people aren't confused by your lack of responsiveness. + +Taking breaks applies to more than just vacations, too. If you don't want to do open source work on weekends, or during work hours, communicate those expectations to others, so they know not to bother you. + +## Take care of yourself first! + +Maintaining a popular project requires different skills than the earlier stages of growth, but it's no less rewarding. As a maintainer, you'll practice leadership and personal skills on a level that few people get to experience. While it's not always easy to manage, setting clear boundaries and only taking on what you're comfortable with will help you stay happy, refreshed, and productive. diff --git a/_articles/ko-KR/building-community.md b/_articles/ko-KR/building-community.md new file mode 100644 index 00000000000..fb3cc512335 --- /dev/null +++ b/_articles/ko-KR/building-community.md @@ -0,0 +1,279 @@ +--- +locale: en-US +title: Building Welcoming Communities +description: Building a community that encourages people to use, contribute to, and evangelize your project. +class: building +toc: + setting-your-project-up-for-success: "Setting your project up for success" + growing-your-community: "Growing your community" + resolving-conflicts: "Resolving conflicts" +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +--- + +## Setting your project up for success + +You've launched your project, you're spreading the word, and people are checking it out. Awesome! Now, how do you get them to stick around? + +A welcoming community is an investment into your project's future and reputation. If your project is just starting to see its first contributions, start by giving early contributors a positive experience, and make it easy for them to keep coming back. + +### Make people feel welcome + +One way to think about your project's community is through what @MikeMcQuaid calls the [contributor funnel](https://speakerdeck.com/mikemcquaid/the-open-source-contributor-funnel): + +![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png) + +As you build your community, consider how someone at the top of the funnel (a potential user) might theoretically make their way to the bottom (an active maintainer). Your goal is to reduce friction at each stage of the contributor experience. When people have easy wins, they will feel incentivized to do more. + +Start with your documentation: + +* **Make it easy for someone to use your project.** [A friendly README](../starting-a-project/#writing-a-readme) and clear code examples will make it easier for anyone who lands on your project to get started. +* **Clearly explain how to contribute**, using [your CONTRIBUTING file](../starting-a-project/#writing-your-contributing-guidelines) and keeping your issues up-to-date. + +[GitHub's 2017 Open Source Survey](http://opensourcesurvey.org/2017/) showed incomplete or confusing documentation is the biggest problem for open source users. Good documentation invites people to interact with your project. Eventually, someone will open an issue or pull request. Use these interactions as opportunities to move them down the funnel. + +* **When someone new lands on your project, thank them for their interest!** It only takes one negative experience to make someone not want to come back. +* **Be responsive.** If you don't respond to their issue for a month, chances are, they've already forgotten about your project. +* **Be open-minded about the types of contributions you'll accept.** Many contributors start with a bug report or small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help. +* **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#learning-to-say-no) it doesn't fit into the scope of the project, linking to relevant documentation if you have it. + + + +The majority of open source contributors are "casual contributors": people who contribute to a project only occasionally. A casual contributor may not have time to get fully up to speed with your project, so your job is to make it easy for them to contribute. + +Encouraging other contributors is an investment in yourself, too. When you empower your biggest fans to run with the work they're excited about, there's less pressure to do everything yourself. + +### Document everything + + + +When you start a new project, it may feel natural to keep your work private. But open source projects thrive when you document your process in public. + +When you write things down, more people can participate at every step of the way. You might get help on something you didn't even know you needed. + +Writing things down means more than just technical documentation. Any time you feel the urge to write something down or privately discuss your project, ask yourself whether you can make it public. + +Be transparent about your project's roadmap, the types of contributions you're looking for, how contributions are reviewed, or why you made certain decisions. + +If you notice multiple users running into the same problem, document the answers in the README. + +For meetings, consider publishing your notes or takeaways in a relevant issue. The feedback you'll get from this level of transparency may surprise you. + +Documenting everything applies to the work you do, too. If you're working on a substantial update to your project, put it into a pull request and mark it as a work in progress (WIP). That way, other people can feel involved in the process early on. + +### Be responsive + +As you [promote your project](../finding-users), people will have feedback for you. They may have questions about how things work, or need help getting started. + +Try to be responsive when someone files an issue, submits a pull request, or asks a question about your project. When you respond quickly, people will feel they are part of a dialogue, and they'll be more enthusiastic about participating. + +Even if you can't review the request immediately, acknowledging it early helps increase engagement. Here's how @tdreyno responded to a pull request on [Middleman](https://github.com/middleman/middleman/pull/1466): + +![Middleman pull request](/assets/images/building-community/middleman_pr.png) + +[A Mozilla study found that](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) contributors who received code reviews within 48 hours had a much higher rate of return and repeat contribution. + +Conversations about your project could also be happening in other places around the internet, such as Stack Overflow, Twitter, or Reddit. You can set up notifications in some of these places so you are alerted when someone mentions your project. + +### Give your community a place to congregate + +There are two reasons to give your community a place to congregate. + +The first reason is for them. Help people get to know each other. People with common interests will inevitably want a place to talk about it. And when communication is public and accessible, anybody can read past archives to get up to speed and participate. + +The second reason is for you. If you don't give people a public place to talk about your project, they will likely contact you directly. In the beginning, it may seem easy enough to respond to private messages "just this once". But over time, especially if your project becomes popular, you will feel exhausted. Resist the temptation to communicate with people about your project in private. Instead, direct them to a designated public channel. + +Public communication can be as simple as directing people to open an issue instead of emailing you directly or commenting on your blog. You could also set up a mailing list, or create a Twitter account, Slack, or IRC channel for people to talk about your project. Or try all of the above! + +[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) sets aside office hours every other week to help community members: + +> 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. + +Notable exceptions to public communication are: 1) security issues and 2) sensitive code of conduct violations. You should always have a way for people to report these issues privately. If you don't want to use your personal email, set up a dedicated email address. + +## Growing your community + +Communities are extremely powerful. That power can be a blessing or a curse, depending on how you wield it. As your project's community grows, there are ways to help it become a force of construction, not destruction. + +### Don't tolerate bad actors + +Any popular project will inevitably attract people who harm, rather than help, your community. They may start unnecessary debates, quibble over trivial features, or bully others. + +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. + + + +Regular debates over trivial aspects of your project distracts others, including you, from focusing on important tasks. New people who arrive to your project may see these conversations and not want to participate. + +When you see negative behavior happening on your project, call it out publicly. Explain, in a kind but firm tone, why their behavior is not acceptable. If the problem persists, you may need to [ask them to leave](../code-of-conduct/#enforcing-your-code-of-conduct). Your [code of conduct](../code-of-conduct/) can be a constructive guide for these conversations. + +### Meet contributors where they're at + +Good documentation only becomes more important as your community grows. Casual contributors, who may not otherwise be familiar with your project, read your documentation to quickly get the context they need. + +In your CONTRIBUTING file, explicitly tell new contributors how to get started. You may even want to make a dedicated section for this purpose. [Django](https://github.com/django/django), for example, has a special landing page to welcome new contributors. + +![Django new contributors page](/assets/images/building-community/django_new_contributors.png) + +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 bug"_, 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): + +> 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 + + + +People are excited to contribute to projects when they feel a sense of ownership. That doesn't mean you need to turn over your project's vision or accept contributions you don't want. But the more you give credit to others, the more they'll stick around. + +See if you can find ways to share ownership with your community as much as possible. Here are some ideas: + +* **Resist fixing easy (non-critical) bugs.** Instead, use them as opportunities to recruit new contributors, or mentor someone who'd like to contribute. It may seem unnatural at first, but your investment will pay off over time. For example, @michaeljoseph asked a contributor to submit a pull request on a [Cookiecutter](https://github.com/audreyr/cookiecutter) issue below, rather than fix it himself. + +![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png) + +* **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. + +* 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. + +* **Give every contributor commit access.** @felixge found that this made people [more excited to polish their patches](http://felixge.de/2013/03/11/the-pull-request-hack.html), and he even found new maintainers for projects that he hadn't worked on in awhile. + +* If your project is on GitHub, **move your project from your personal account to an [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** and add at least one backup admin. Organizations make it easier to work on projects with external collaborators. + +The reality is that [most projects only have](https://peerj.com/preprints/1233.pdf) one or two maintainers who do most of the work. The bigger your project, and the bigger your community, the easier it is to find help. + +While you may not always find someone to answer the call, putting a signal out there increases the chances that other people will pitch in. And the earlier you start, the sooner people can help. + + + +## Resolving conflicts + +In the early stages of your project, making major decisions is easy. When you want to do something, you just do it. + +As your project becomes more popular, more people will take interest in the decisions you make. Even if you don't have a big community of contributors, if your project has a lot of users, you'll find people weighing in on decisions or raising issues of their own. + +For the most part, if you've cultivated a friendly, respectful community and documented your processes openly, your community should be able to find resolution. But sometimes you run into an issue that's a bit harder to address. + +### Set the bar for kindness + +When your community is grappling with a difficult issue, tempers may rise. People may become angry or frustrated and take it out on one another, or on you. + +Your job as a maintainer is to keep these situations from escalating. Even if you have a strong opinion on the topic, try to take the position of a moderator or facilitator, rather than jumping into the fight and pushing your views. If someone is being unkind or monopolizing the conversation, [act immediately](../building-community/#dont-tolerate-bad-actors) to keep discussions civil and productive. + + + +Other people are looking to you for guidance. Set a good example. You can still express disappointment, unhappiness, or concern, but do so calmly. + +Keeping your cool isn't easy, but demonstrating leadership improves the health of your community. The internet thanks you. + +### Treat your README as a constitution + +Your README is [more than just a set of instructions](../starting-a-project/#writing-a-readme). It's also a place to talk about your goals, product vision, and roadmap. If people are overly focused on debating the merit of a particular feature, it may help to revisit your README and talk about the higher vision of your project. Focusing on your README also depersonalizes the conversation, so you can have a constructive discussion. + +### Focus on the journey, not the destination + +Some projects use a voting process to make major decisions. While sensible at first glance, voting emphasizes getting to an "answer," rather than listening to and addressing each other's concerns. + +Voting can become political, where community members feel pressured to do each other favors or vote a certain way. Not everybody votes, either, whether it's the [silent majority](http://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) in your community, or current users who didn't know a vote was taking place. + +Sometimes, voting is a necessary tiebreaker. As much as you are able, however, emphasize ["consensus seeking"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) rather than consensus. + +Under a consensus seeking process, community members discuss major concerns until they feel they have been adequately heard. When only minor concerns remain, the community moves forward. "Consensus seeking" acknowledges that a community may not be able to reach a perfect answer. Instead, it prioritizes listening and discussion. + + + +Even if you don't actually adopt a consensus seeking process, as a project maintainer, it's important that people know you are listening. Making other people feel heard, and committing to resolving their concerns, goes a long way to diffuse sensitive situations. Then, follow up on your words with actions. + +Don't rush into a decision for the sake of having a resolution. Make sure that everybody feels heard and that all information has been made public before moving toward a resolution. + +### Keep the conversation focused on action + +Discussion is important, but there is a difference between productive and unproductive conversations. + +Encourage discussion so long as it is actively moving towards resolution. If it's clear that conversation is languishing or going off-topic, jabs are getting personal, or people are quibbling about minor details, it's time to shut it down. + +Allowing these conversations to continue is not only bad for the issue at hand, but bad for the health of your community. It sends a message that these types of conversations are permitted or even encouraged, and it can discourage people from raising or resolving future issues. + +With every point made by you or by others, ask yourself, _"How does this bring us closer to a resolution?"_ + +If the conversation is starting to unravel, ask the group, _"Which steps should we take next?"_ to refocus the conversation. + +If a conversation clearly isn't going anywhere, there are no clear actions to be taken, or the appropriate action has already been taken, close the issue and explain why you closed it. + + + +### Pick your battles wisely + +Context is important. Consider who is involved in the discussion and how they represent the rest of the community. + +Is everybody in the community upset about, or even engaged with, this issue? Or is a lone troublemaker? Don't forget to consider your silent community members, not just the active voices. + +If the issue does not represent the broader needs of your community, you may just need to acknowledge the concerns of a few people. If this is a recurring issue without a clear resolution, point them to previous discussions on the topic and close the thread. + +### Identify a community tiebreaker + +With a good attitude and clear communication, most difficult situations are resolvable. However, even in a productive conversation, there can simply be a difference in opinion on how to proceed. In these cases, identify an individual or group of people that can serve as a tiebreaker. + +A tiebreaker could be the primary maintainer of the project, or it could be a small group of people who make a decision based on voting. Ideally, you've identified a tiebreaker and the associated process in a GOVERNANCE file before you ever have to use it. + +Your tiebreaker should be a last resort. Divisive issues are an opportunity for your community to grow and learn. Embrace these opportunities and use a collaborative process to move to a resolution wherever possible. + +## Community is the ❤️ of open source + +Healthy, thriving communities fuel the thousands of hours poured into open source every week. Many contributors point to other people as the reason for working - or not working - on open source. By learning how to tap into that power constructively, you'll help someone out there have an unforgettable open source experience. diff --git a/_articles/ko-KR/code-of-conduct.md b/_articles/ko-KR/code-of-conduct.md new file mode 100644 index 00000000000..ea884dc3bd7 --- /dev/null +++ b/_articles/ko-KR/code-of-conduct.md @@ -0,0 +1,119 @@ +--- +locale: en-US +title: Your Code of Conduct +description: Facilitate healthy and constructive community behavior by adopting and enforcing a code of conduct. +class: coc +toc: + why-do-i-need-a-code-of-conduct: "Why do I need a code of conduct?" + 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" +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## Why do I need a code of conduct? + +A code of conduct is a document that establishes expectations for behavior for your project's participants. Adopting, and enforcing, a code of conduct can help create a positive social atmosphere for your community. + +Codes of conduct help protect not just your participants, but yourself. If you maintain a project, you may find that unproductive attitudes from other participants can make you feel drained or unhappy about your work over time. + +A code of conduct empowers you to facilitate healthy, constructive community behavior. Being proactive reduces the likelihood that you, or others, will become fatigued with your project, and helps you take action when someone does something you don't agree with. + +## Establishing a code of conduct + +Try to establish a code of conduct as early as possible: ideally, when you first create your project. + +In addition to communicating your expectations, a code of conduct describes the following: + +* Where the code of conduct takes effect _(only on issues and pull requests, or community activities like events?)_ +* Whom the code of conduct applies to _(community members and maintainers, but what about sponsors?)_ +* What happens if someone violates the code of conduct +* How someone can report violations + +Wherever you can, use prior art. The [Contributor Covenant](http://contributor-covenant.org/) is a drop-in code of conduct that is used by over 40,000 open source projects, including Kubernetes, Rails, and Swift. + +The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](http://citizencodeofconduct.org/) are also two good code of conduct examples. + +Place a CODE_OF_CONDUCT file in your project's root directory, and make it visible to your community by linking it from your CONTRIBUTING or README file. + +## Deciding how you'll enforce your code of conduct + + + +You should explain how your code of conduct will be enforced **_before_** a violation occurs. There are several reasons to do so: + +* It demonstrates that you are serious about taking action when it's needed. + +* Your community will feel more reassured that complaints actually get reviewed. + +* You'll reassure your community that the review process is fair and transparent, should they ever find themselves investigated for a violation. + +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): + +> 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.* + +For inspiration, check out Django's [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (though you may not need something this comprehensive, depending on the size of your project). + +## Enforcing your code of conduct + +Sometimes, despite your best efforts, somebody will do something that violates this code. There are several ways to address negative or harmful behavior when it comes up. + +### Gather information about the situation + +Treat each community member's voice as important as your own. If you receive a report that someone violated the code of conduct, take it seriously and investigate the matter, even if it does not match your own experience with that person. Doing so signals to your community that you value their perspective and trust their judgment. + +The community member in question may be a repeat offender who consistently makes others feel uncomfortable, or they may have only said or done something once. Both can be grounds for taking action, depending on context. + +Before you respond, give yourself time to understand what happened. Read through the person's past comments and conversations to better understand who they are and why they might have acted in such a way. Try to gather perspectives other than your own about this person and their behavior. + + + +### Take appropriate action + +After gathering and processing sufficient information, you'll need to decide what to do. As you consider your next steps, remember that your goal as a moderator is to foster a safe, respectful, and collaborative environment. Consider not only how to deal with the situation in question, but how your response will affect the rest of your community's behavior and expectations moving forward. + +When somebody reports a code of conduct violation, it is your, not their, job to handle it. Sometimes, the reporter is disclosing information at great risk to their career, reputation, or physical safety. Forcing them to confront their harasser could put the reporter in a compromising position. You should handle direct communication with the person in question, unless the reporter explicitly requests otherwise. + +There are a few ways you might respond to a code of conduct violation: + +* **Give the person in question a public warning** and explain how their behavior negatively impacted others, preferably in the channel where it occurred. Where possible, public communication conveys to the rest of the community that you take the code of conduct seriously. Be kind, but firm in your communication. + +* **Privately reach out to the person** in question to explain how their behavior negatively impacted others. You may want to use a private communication channel if the situation involves sensitive personal information. If you communicate with someone privately, it's a good idea to CC those who first reported the situation, so they know you took action. Ask the reporting person for consent before CCing them. + +Sometimes, a resolution cannot be reached. The person in question may become aggressive or hostile when confronted or does not change their behavior. In this situation, you may want to consider taking stronger action. For example: + +* **Suspend the person** in question from the project, enforced through a temporary ban on participating in any aspect of the project + +* **Permanently ban** the person from the project + +Banning members should not be taken lightly and represents a permanent and irreconcilable difference of perspectives. You should only take these measures when it is clear that a resolution cannot be reached. + +## Your responsibilities as a maintainer + +A code of conduct is not a law that is enforced arbitrarily. You are the enforcer of the code of conduct and it's your responsibility to follow the rules that the code of conduct establishes. + +As a maintainer you establish the guidelines for your community and enforce those guidelines according to the rules set forth in your code of conduct. This means taking any report of a code of conduct violation seriously. The reporter is owed a thorough and fair review of their complaint. If you determine that the behavior that they reported is not a violation, communicate that clearly to them and explain why you're not going to take action on it. What they do with that is up to them: tolerate the behavior that they had an issue with, or stop participating in the community. + +A report of behavior that doesn't _technically_ violate the code of conduct may still indicate that there is a problem in your community, and you should investigate this potential problem and act accordingly. This may include revising your code of conduct to clarify acceptable behavior and/or talking to the person whose behavior was reported and telling them that while they did not violate the code of conduct, they are skirting the edge of what is expected and are making certain participants feel uncomfortable. + +In the end, as a maintainer, you set and enforce the standards for acceptable behavior. You have the ability to shape the community values of the project, and participants expect you to enforce those values in a fair and even-handed way. + +## Encourage the behavior you want to see in the world 🌎 + +When a project seems hostile or unwelcoming, even if it's just one person whose behavior is tolerated by others, you risk losing many more contributors, some of whom you may never even meet. It's not always easy to adopt or enforce a code of conduct, but fostering a welcoming environment will help your community grow. diff --git a/_articles/ko-KR/finding-users.md b/_articles/ko-KR/finding-users.md new file mode 100644 index 00000000000..0e2c45eb802 --- /dev/null +++ b/_articles/ko-KR/finding-users.md @@ -0,0 +1,165 @@ +--- +locale: en-US +title: Finding Users for Your Project +description: Help your open source project grow by getting it in the hands of happy users. +class: finding +toc: + spreading-the-word: "Spreading the word" + figure-out-your-message: "Figure out your message" + help-people-find-and-follow-your-project: "Help people find and follow your project" + go-where-your-projects-audience-is-online: "Go where your project’s audience is (online)" + go-where-your-projects-audience-is-offline: "Go where your project’s audience is (offline)" + build-a-reputation: "Build a reputation" +order: 3 +image: /assets/images/cards/finding.png +related: + - beginners + - building +--- + +## Spreading the word + +There's no rule that says you have to promote an open source project when you launch. There are many fulfilling reasons to work in open source that have nothing to do with popularity. If you are hoping others will find and use your open source project, however, it's time to tell everybody about your hard work! + +## Figure out your message + +Before you start the actual work of promoting your project, you should be able to explain what it does, and why it matters. + +What makes your project different or interesting? Why did you create it? Answering these questions for yourself will make it easier to convince others. + +Remember that people get involved as users, and eventually contributors, because it solves a problem for them. As you think about your project's message and value, try to view it through the lens of what _they_ might want. + +For example, @robb uses code examples to clearly communicate why his project, [Cartography](https://github.com/robb/Cartography), is useful: + +![Cartography README](/assets/images/finding-users/cartography.jpg) + +For a deeper dive into messaging, check out Mozilla's ["Personas and Pathways"](http://mozillascience.github.io/working-open-workshop/personas_pathways/) exercise for developing user personas. + +## Help people find and follow your project + + + +Help people find and remember your project by pointing them to a single namespace. + +**Have a clear handle to promote your work.** A Twitter handle, GitHub URL, or IRC channel is an easy way to point people to your project. They also give your project's growing community a place to convene. + +If you don't wish to set up these channels for your project yet, promote your own Twitter or GitHub handle in everything you do. For example, make sure it is included in your bio or slides if you speak at a meetup or event. That way, people know how to reach you or follow your work. + + + +**Consider creating a website for your project.** A website makes your project friendlier and easier to navigate, especially paired with clear documentation and tutorials. It also suggests that your project is active, which will make your audience feel more comfortable using it. Use examples to give people ideas for how to use your project. + +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-creator of Django, said that a website was _"by far the best thing we did with Django in the early days"_. + +If your project is hosted on GitHub, you can use [GitHub Pages](https://pages.github.com/) to easily make a website. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) are [a few examples](https://github.com/showcases/github-pages-examples) of excellent, comprehensive websites. + +![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png) + +Now that you have a message for your project, and an easy way for people to find your project, let's get out there and talk to your audience! + +## Go where your project's audience is (online) + +Online outreach is a great way to share and spread the word quickly. Using online channels, you have the potential to reach a very wide audience. + +Take advantage of existing online communities and platforms to reach your audience. If your open source project is a software project, you can probably find your audience on [Stack Overflow](http://stackoverflow.com/), [Reddit](http://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/). Find the channels where you think people will most benefit from or be excited about your work. + + + +See if you can find ways to share your project in relevant ways: + +* **Get to know relevant open source projects and communities.** Sometimes, you don't have to directly promote your project. If your project is perfect for data scientists who use Python, get to know the Python data science community. As people get to know you, natural opportunities will arise to talk about and share your work. +* **Find people experiencing the problem that your project solves.** Search through related forums for people who fall into your project's target audience. Answer their question and find a tactful way, when appropriate, to suggest your project as a solution. +* **Ask for feedback.** Introduce yourself and your work to an audience that would find it relevant and interesting. Be specific about who you think would benefit from your project. Try to finish the sentence: _"I think my project would really help X, who are trying to do Y_". Listen and respond to others' feedback, rather than simply promoting your work. + +Generally speaking, focus on helping others before asking for things in return. Because it is easy for anybody to promote a project online, there will be a lot of noise. Give people context for who you are, not just what you want, to stand out from the crowd. + +If nobody pays attention or responds to your initial outreach, don't get discouraged! Most project launches are an iterative process that can take months or years. If you don't get a response the first time, try a different tactic, or look for ways to add value to others' work first. These things take time and dedication. + +## Go where your project's audience is (offline) + +![Public speaking](/assets/images/finding-users/public_speaking.jpg) + +Offline events are a popular way to promote new projects. It's 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've never spoken at an event before, it's perfectly normal to feel nervous! Remember that your audience is there because they genuinely want to hear about your work. + +As you write your talk, focus on what your audience will find interesting and get value out of. Keep your language friendly and approachable. Smile, breathe, and have fun. + + + +When you feel ready, consider speaking at a conference to promote your project. Conferences can help you reach more people, sometimes from all over the world. + +Look for conferences that are specific to your language or ecosystem. Before you submit your talk, research the conference beforehand to tailor your talk to its attendees and increase your chances of getting accepted. You can often get a sense of a conference's audience by looking at its speakers. + + + +## Build a reputation + +In addition to the strategies outlined above, the best way to invite people to share and contribute to your project is to share and contribute to their projects. + +Helping newcomers, sharing resources, and making thoughtful contributions to others' work will help you build a positive reputation. Then, people will have context for your work and be more likely to pay attention and share what you're doing. + +Sometimes, these relationships can even lead to official partnerships with the wider ecosystem. + + + +It's never too early, or too late, to start building your reputation. Even if you've launched your own project already, continue looking for ways to help others. + +There is no overnight solution to building an audience. Gaining the trust and respect of others takes time, and reputation building work never ends. + + + +## Keep at it! + +Sometimes, it takes a long time before people notice your open source project. That's okay! Some of the most popular projects today took years to reach high levels of activity. Focus on building relationships instead of a magic bullet. Be patient, and keep sharing your work with those who appreciate it. diff --git a/_articles/ko-KR/getting-paid.md b/_articles/ko-KR/getting-paid.md new file mode 100644 index 00000000000..97585eb29bf --- /dev/null +++ b/_articles/ko-KR/getting-paid.md @@ -0,0 +1,188 @@ +--- +locale: en-US +title: Getting Paid for Open Source Work +description: Sustain your work in open source by getting financial support for your time or your project. +class: getting-paid +toc: + why-some-people-seek-financial-support: "Why some people seek financial support" + funding-your-own-time: "Funding your own time" + finding-funding-for-your-project: "Finding funding for your project" + building-a-case-for-financial-support: "Building a case for financial support" +order: 7 +image: /assets/images/cards/getting-paid.png +related: + - best-practices + - leadership +--- + +## Why some people seek financial support + +Much of open source work is volunteered. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time. + + + +There are many reasons why a person would not want to be paid for their open source work. + +* **They may already have a full-time job that they love,** which enables them to contribute to open source in their spare time. +* **They enjoy thinking of open source as a hobby** or creative escape and don't want to feel financially obligated to work on their projects. +* **They get other benefits from contributing to open source,** such as building their reputation or portfolio, learning a new skill, or feeling closer to a community. + + + +For others, especially when contributions are ongoing or require significant time, getting paid to contribute to open source is the only way they can participate, either because the project requires it, or for personal reasons. + +Maintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month. + + + +Paid work also enables people from different walks of life to make meaningful contributions. Some people cannot afford to spend unpaid time on open source projects, based on their current financial position, debt, or family or other caretaking obligations. That means the world never sees contributions from talented people who can't afford to volunteer their time. This has ethical implications, as @ashedryden [has described](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), since work that is done is biased in favor of those who already have advantages in life, who then gain additional advantages based on their volunteer contributions, while others who are not able to volunteer then don't get later opportunities, which reinforces the current lack of diversity in the open source community. + + + +If you're looking for financial support, there are two paths to consider. You can fund your own time as a contributor, or you can find organizational funding for the project. + +## Funding your own time + +Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer. + +It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general. + + + +If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software. + +Many companies are developing open source programs to build their brand and recruit quality talent. + +@hueniverse, for example, found that there were financial reasons to justify [Walmart's investment in open source](http://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). And @jamesgpearce found that Facebook's open source program [made a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) in recruiting: + +> 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. + +If your company goes down this route, it's important to keep the boundaries between community and corporate activity clear. Ultimately, open source sustains itself through contributions from people all over the world, and that's bigger than any one company or location. + + + +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](http://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 + +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: + +* @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](http://redux.js.org/) +* @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) + +## Finding funding for your project + +Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work. + +Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing into new features or ideas. + +As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available. + +### Raise money for your work through crowdfunding campaigns or sponsorships + +Finding sponsorships works well if you have a strong audience or reputation already, or your project is very popular. +A few examples of sponsored projects include: + +* **[webpack](https://github.com/webpack)** raises money from companies and individuals [through OpenCollective](https://opencollective.com/webpack) +* **[Vue](https://github.com/vuejs/vue)** is [funded through Patreon](https://github.com/open-source/stories/yyx990803) +* **[Ruby Together](https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects + +### Create a revenue stream + +Depending on your project, you may be able to charge for commercial support, hosted options, or additional features. A few examples include: + +* **[Sidekiq](https://github.com/mperham/sidekiq)** offers paid versions for additional support +* **[Travis CI](https://github.com/travis-ci)** offers paid versions of its product +* **[Ghost](https://github.com/TryGhost/Ghost)** is a nonprofit with a paid managed service + +Some popular projects, like [npm](https://github.com/npm/npm) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth. + +### Apply for grant funding + +Some software foundations and companies offer grants for open source work. Sometimes, grants can be paid out to individuals without setting up a legal entity for the project. + +* **[Read the Docs](https://github.com/rtfd/readthedocs.org)** received a grant from [Mozilla Open Source Support](https://www.mozilla.org/en-US/grants/) +* **[OpenMRS](https://github.com/openmrs)** work was funded by [Stripe's Open-Source Retreat](https://stripe.com/blog/open-source-retreat-2016-grantees) +* **[Libraries.io](https://github.com/librariesio)** received a grant from the [Sloan Foundation](https://sloan.org/programs/digital-technology) +* The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work + +For more detailed options and case studies, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) to getting paid for open source work. Different types of funding require different skills, so consider your strengths to figure out which option works best for you. + +## Building a case for financial support + +Whether your project is a new idea, or has been around for years, you should expect to put significant thought into identifying your target funder and making a compelling case. + +Whether you're looking to pay for your own time, or fundraise for a project, you should be able to answer the following questions. + +### Impact + +Why is this project useful? Why do your users, or potential users, like it so much? Where will it be in five years? + +### Traction + +Try to collect evidence that your project matters, whether it's metrics, anecdotes, or testimonials. Are there any companies or noteworthy people using your project right now? If not, has a prominent person endorsed it? + +### Value to funder + +Funders, whether your employer or a grantmaking foundation, are frequently approached with opportunities. Why should they support your project over any other opportunity? How do they personally benefit? + +### Use of funds + +What, exactly, will you accomplish with the proposed funding? Focus on project milestones or outcomes rather than paying a salary. + +### How you'll receive the funds + +Does the funder have any requirements around disbursal? For example, you may need to be a nonprofit or have a nonprofit fiscal sponsor. Or perhaps the funds must be given to an individual contractor rather than an organization. These requirements vary between funders, so be sure to do your research beforehand. + + + +## 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/ko-KR/how-to-contribute.md b/_articles/ko-KR/how-to-contribute.md new file mode 100644 index 00000000000..e1588e10bdd --- /dev/null +++ b/_articles/ko-KR/how-to-contribute.md @@ -0,0 +1,528 @@ +--- +locale: en-US +title: How to Contribute to Open Source +description: Want to contribute to open source? A guide to making open source contributions, for first-timers and for veterans. +class: contribute +toc: + why-contribute-to-open-source: "Why contribute to open source?" + what-it-means-to-contribute: "What it means to contribute" + orienting-yourself-to-a-new-project: "Orienting yourself to a new project" + finding-a-project-to-contribute-to: "Finding a project to contribute to" + how-to-submit-a-contribution: "How to submit a contribution" + what-happens-after-you-submit-a-contribution: "What happens after you submit a contribution" +order: 1 +image: /assets/images/cards/contribute.png +related: + - beginners + - building +--- + +## Why contribute to open source? + + + +Contributing to open source can be a rewarding way to learn, teach, and build experience in just about any skill you can imagine. + +Why do people contribute to open source? Plenty of reasons! + +### 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. + +### Meet people who are interested in similar things + +Open source projects with warm, welcoming communities keep people coming back for years. Many people form lifelong friendships through their participation in open source, whether it's running into each other at conferences or late night online chats about burritos. + +### Find mentors and teach others + +Working with others on a shared project means you'll have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved. + +### Build public artifacts that help you grow a reputation (and a career) + +By definition, all of your open source work is public, which means you get free examples to take anywhere as a demonstration of what you can do. + +### Learn people skills + +Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organizing teams of people, and prioritizing work. + +### It's empowering to be able to make changes, even small ones + +You don't have to become a lifelong contributor to enjoy participating in open source. Have you ever seen a typo on a website, and wished someone would fix it? On an open source project, you can do just that. Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying. + +## What it means to contribute + +If you're a new open source contributor, the process can be intimidating. How do you find the right project? What if you don't know how to code? What if something goes wrong? + +Not to worry! There are all sorts of ways to get involved with an open source project, and a few tips will help you get the most out of your experience. + +### You don't have to contribute code + +A common misconception about contributing to open source is that you need to contribute code. In fact, it's often the other parts of a project that are [most neglected or overlooked](https://github.com/blog/2195-the-shape-of-open-source). You'll do the project a _huge_ favor by offering to pitch in with these types of contributions! + + + +Even if you like to write code, other types of contributions are a great way to get involved with a project and meet other community members. Building those relationships will give you opportunities to work on other parts of the project. + + + +### Do you like planning events? + +* Organize workshops or meetups about the project, [like @fzamperin did for NodeSchool](https://github.com/nodeschool/organizers/issues/406) +* Organize the project's conference (if they have one) +* Help community members find the right conferences and submit proposals for speaking + +### Do you like to design? + +* Restructure layouts to improve the project's usability +* Conduct user research to reorganize and refine the project's navigation or menus, [like Drupal suggests](https://www.drupal.org/community-initiatives/drupal-core/usability) +* Put together a style guide to help the project have a consistent visual design +* Create art for t-shirts or a new logo, [like hapi.js's contributors did](https://github.com/hapijs/contrib/issues/68) + +### Do you like to write? + +* Write and improve the project's documentation +* Curate a folder of examples showing how the project is used +* Start a newsletter for the project, or curate highlights from the mailing list +* Write tutorials for the project, [like PyPA's contributors did](https://github.com/pypa/python-packaging-user-guide/issues/194) +* Write a translation for the project's documentation + + + +### Do you like organizing? + +* Link to duplicate issues, and suggest new issue labels, to keep things organized +* Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765) +* Ask clarifying questions on recently opened issues to move the discussion forward + +### Do you like to code? + +* Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) +* Ask if you can help write a new feature +* Automate project setup +* Improve tooling and testing + +### Do you like helping people? + +* Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](http://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit +* Answer questions for people on open issues +* Help moderate the discussion boards or conversation channels + +### Do you like helping others code? + +* Review code on other people's submissions +* Write tutorials for how a project can be used +* Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) + +### You don't just have to work on software projects! + +While "open source" often refers to software, you can collaborate on just about anything. There are books, recipes, lists, and classes that get developed as open source projects. + +For example: + +* @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome) +* @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates +* @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts) + +Even if you're a software developer, working on a documentation project can help you get started in open source. It's often less intimidating to work on projects that don't involve code, and the process of collaboration will build your confidence and experience. + +## Orienting yourself to a new project + + + +For anything more than a typo fix, contributing to open source is like walking up to a group of strangers at a party. If you start talking about llamas, while they were deep in a discussion about goldfish, they'll probably look at you a little strangely. + +Before jumping in blindly with your own suggestions, start by learning how to read the room. Doing so increases the chances that your ideas will be noticed and heard. + +### Anatomy of an open source project + +Every open source community is different. + +Spending years on one open source project means you've gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different. + +That said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project. + +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. + +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. + +A project also has documentation. These files are usually listed in the top level of a repository. + +* **LICENSE:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source. +* **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started. +* **CONTRIBUTING:** Whereas READMEs help people _use_ the project, contributing docs help people _contribute_ to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to. +* **CODE_OF_CONDUCT:** The code of conduct sets ground rules for participants' behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to. +* **Other documentation:** There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects. + +Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works. + +* **Issue tracker:** Where people discuss issues related to the project. +* **Pull requests:** Where people discuss and review changes that are in progress. +* **Discussion forums or mailing lists:** Some projects may use these channels for conversational topics (ex. _"How do I..."_ or _"What do you think about..."_ instead of bug reports or feature requests). Others use the issue tracker for all conversations. +* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges. + +## Finding a project to contribute to + +Now that you've figured out how open source projects work, it's time to find a project to contribute to! + +If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said, _"Ask not what your country can do for you - ask what you can do for your country."_ + +Contributing to open source happens at all levels, across projects. You don't need to overthink what exactly your first contribution will be, or how it will look. + +Instead, start by thinking about the projects you already use, or want to use. The projects you'll actively contribute to are the ones you find yourself coming back to. + +Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct. + +Open source isn't an exclusive club; it's made by people just like you. "Open source" is just a fancy term for treating the world's problems as fixable. + +You might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about! + +> [28% of casual contributions](http://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as a typo fix, reformatting, or writing a translation. + +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/) +* [CodeTriage](https://www.codetriage.com/) +* [24 Pull Requests](https://24pullrequests.com/) +* [Up For Grabs](http://up-for-grabs.net/) +* [Contributor-ninja](https://contributor.ninja) + +### A checklist before you contribute + +When you've found a project you'd like to contribute to, do a quick scan to make sure that the project is suitable for accepting contributions. Otherwise, your hard work may never get a response. + +Here's a handy checklist to evaluate whether a project is good for new contributors. + +**Meets the definition of open source** + +
+ + +
+ +**Project actively accepts contributions** + +Look at the commit activity on the master branch. On GitHub, you can see this information on a repository's homepage. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +Next, look at the project's issues. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +Now do the same for the project's pull requests. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Project is welcoming** + +A project that is friendly and welcoming signals that they will be receptive to new contributors. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ + + +## How to submit a contribution + +You've found a project you like, and you're ready to make a contribution. Finally! Here's how to get your contribution in the right way. + +### Communicating effectively + +Whether you're a one-time contributor or trying to join a community, working with others is one of the most important skills you'll develop in open source. + + + +Before you open an issue or pull request, or ask a question in chat, keep these points in mind to help your ideas come across effectively. + +**Give context.** Help others get quickly up to speed. If you're running into an error, explain what you're trying to do and how to reproduce it. If you're suggesting a new idea, explain why you think it'd be useful to the project (not just to you!). + +> 😇 _"X doesn't happen when I do Y"_ +> +> 😢 _"X is broken! Please fix it."_ + +**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate when you demonstrate that you're trying to learn. + +> 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_ +> +> 😢 _"How do I X?"_ + +**Keep requests short and direct.** Much like sending an email, every contribution, no matter how simple or helpful, requires someone else's review. Many projects have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you. + +> 😇 _"I'd like to write an API tutorial."_ +> +> 😢 _"I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you..."_ + +**Keep all communication public.** Although it's tempting, don't reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation). When you keep the conversation public, more people can learn and benefit from your exchange. Discussions can be, in themselves, contributions. + +> 😇 _(as a comment) "@-maintainer Hi there! How should we proceed on this PR?"_ +> +> 😢 _(as an email) "Hey there, sorry to bother you over email, but I was wondering if you've had a chance to review my PR"_ + +**It's okay to ask questions (but be patient!).** Everybody was new to the project at some point, and even experienced contributors need to get up to speed when they look at a new project. By the same token, even longtime maintainers are not always familiar with every part of the project. Show them the same patience that you'd want them to show to you. + +> 😇 _"Thanks for looking into this error. I followed your suggestions. Here's the output."_ +> +> 😢 _"Why can't you fix my problem? Isn't this your project?"_ + +**Respect community decisions.** Your ideas may differ from the community's priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project. + +> 😇 _"I'm disappointed you can't support my use case, but as you've explained it only affects a minor portion of users, I understand why. Thanks for listening."_ +> +> 😢 _"Why won't you support my use case? This is unacceptable!"_ + +**Above all, keep it classy.** Open source is made up of collaborators from all over the world. Context gets lost across languages, cultures, geographies, and time zones. In addition, written communication makes it harder to convey a tone or mood. Assume good intentions in these conversations. It's fine to politely push back on an idea, ask for more context, or further clarify your position. Just try to leave the internet a better place than when you found it. + +### Gathering context + +Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way. + +If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by opening an issue or pull request: + +* **Issues** are like starting a conversation or discussion +* **Pull requests** are for starting work on a solution +* **For lightweight communication,** such as a clarifying or how-to question, try asking on Stack Overflow, IRC, Slack, or other chat channels, if the project has one + +Before you open an issue or pull request, check the project's contributing docs (usually a file called CONTRIBUTING, or in the README), to see whether you need to include anything specific. For example, they may ask that you follow a template, or require that you use tests. + +If you want to make a substantial contribution, open an issue to ask before working on it. It's helpful to watch the project for a while (on GitHub, [you can click "Watch"](https://help.github.com/articles/watching-repositories/) to be notified of all conversations), and get to know community members, before doing work that might not get accepted. + + + +### Opening an issue + +You should usually open an issue in the following situations: + +* Report an error you can't solve yourself +* Discuss a high-level topic or idea (ex. community, vision, policies) +* Propose a new feature or other project idea + +Tips for communicating on issues: + +* **If you see an open issue that you want to tackle,** comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work. +* **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work. +* **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project. + +### Opening a pull request + +You should usually open a pull request in the following situations: + +* Submit trivial fixes (ex. a typo, broken link, or obvious error) +* Start work on a contribution that was already asked for, or that you've already discussed, in an issue + +A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just mark it as a "WIP" (Work in Progress) in the subject line. You can always add more commits later. + +If the project is on GitHub, here's how to submit a pull request: + +* **[Fork the repository](https://guides.github.com/activities/forking/)** and clone it locally. Connect your local to the original "upstream" repository by adding it as a remote. Pull in changes from "upstream" often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely. (See more detailed instructions [here](https://help.github.com/articles/syncing-a-fork/).) +* **[Create a branch](https://guides.github.com/introduction/flow/)** for your edits. +* **Reference any relevant issues** or supporting documentation in your PR (ex. "Closes #37.") +* **Include screenshots of the before and after** if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request. +* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don't break the existing project. +* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future. + +If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a free walkthrough resource. + +## What happens after you submit a contribution + +You did it! Congratulations on becoming an open source contributor. We hope it's the first of many. + +After you submit a contribution, one of the following will happen: + +### 😭 You don't get a response. + +Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response. + +If you haven't gotten a response in over a week, it's fair to politely respond in that same thread, asking someone for a review. If you know the name of the right person to review your contribution, you can @-mention them in that thread. + +**Don't** reach out to that person privately; remember that public communication is vital to open source projects. + +If you make a polite bump and still nobody responds, it's possible that nobody will respond, ever. It's not a great feeling, but don't let that discourage you. It's happened to everyone! There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive. + +### 🚧 Someone requests changes to your contribution. + +It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code. + +When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it. + +If you don't have time to work on the issue anymore (for example, if the conversation has been going on for months, and your circumstances have changed), let the maintainer know so they're not expecting a response. Someone else may be happy to take over. + +### 👎 Your contribution doesn't get accepted. + +Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree! + +### 🎉 Your contribution gets accepted. + +Hooray! You've successfully made an open source contribution! + +## You did it! + +Whether you just made your first open source contribution, or you're looking for new ways to contribute, we hope you're inspired to take action. Even if your contribution wasn't accepted, don't forget to say thanks when a maintainer put effort into helping you. Open source is made by people like you: one issue, pull request, comment, or high-five at a time. diff --git a/_articles/ko-KR/leadership-and-governance.md b/_articles/ko-KR/leadership-and-governance.md new file mode 100644 index 00000000000..fbab0d61ba8 --- /dev/null +++ b/_articles/ko-KR/leadership-and-governance.md @@ -0,0 +1,164 @@ +--- +locale: en-US +title: Leadership and Governance +description: Growing open source projects can benefit from formal rules for making decisions. +class: leadership +toc: + what-are-examples-of-formal-roles-used-in-open-source-projects: "What are examples of formal roles used in open source projects?" + how-do-i-formalize-these-leadership-roles: "How do I formalize these leadership roles?" + when-should-i-give-someone-commit-access: "When should I give someone commit access?" + what-are-some-of-the-common-governance-structures-for-open-source-projects: "What are some of the common governance structures for open source projects?" + do-i-need-governance-docs-when-i-launch-my-project: "Do I need governance docs when I launch my project?" + what-happens-if-corporate-employees-start-submitting-contributions: "What happens if corporate employees start submitting contributions?" + do-i-need-a-legal-entity-to-support-my-project: "Do I need a legal entity to support my project?" +order: 6 +image: /assets/images/cards/leadership.png +related: + - best-practices + - metrics +--- + +## Understanding governance for your growing project + +Your project is growing, people are engaged, and you're committed to keeping this thing going. At this stage, you may be wondering how to incorporate regular project contributors into your workflow, whether it's giving someone commit access or resolving community debates. If you have questions, we've got answers. + +## What are examples of formal roles used in open source projects? + +Many projects follow a similar structure for contributor roles and recognition. + +What these roles actually mean, though, is entirely up to you. Here are a few types of roles you may recognize: + +* **Maintainer** +* **Contributor** +* **Committer** + +**For some projects, "maintainers"** are the only people in a project with commit access. In other projects, they're simply the people who are listed in the README as maintainers. + +A maintainer doesn't necessarily have to be someone who writes code for your project. It could be someone who's done a lot of work evangelizing your project, or written documentation that made the project more accessible to others. Regardless of what they do day-to-day, a maintainer is probably someone who feels responsibility over the direction of the project and is committed to improving it. + +**A "contributor" could be anyone** who comments on an issue or pull request, people who add value to the project (whether it's triaging issues, writing code, or organizing events), or anybody with a merged pull request (perhaps the narrowest definition of a contributor). + + + +**The term "committer"** might be used to distinguish commit access, which is a specific type of responsibility, from other forms of contribution. + +While you can define your project roles any way you'd like, [consider using broader definitions](../how-to-contribute/#what-it-means-to-contribute) to encourage more forms of contribution. You can use leadership roles to formally recognize people who have made outstanding contributions to your project, regardless of their technical skill. + + + +## How do I formalize these leadership roles? + +Formalizing your leadership roles helps people feel ownership and tells other community members who to look to for help. + +For a smaller project, designating leaders can be as simple as adding their names to your README or a CONTRIBUTORS text file. + +For a bigger project, if you have a website, create a team page or list your project leaders there. For example, [Postgres](https://github.com/postgres/postgres/) has a [comprehensive team page](https://www.postgresql.org/community/contributors/) with short profiles for each contributor. + +If your project has a very active contributor community, you might form a "core team" of maintainers, or even subcommittees of people who take ownership of different issue areas (ex. security, issue triaging, or community conduct). Let people self-organize and volunteer for the roles they're most excited about, rather than assigning them. + + + +Leadership teams may want to create a designated channel (like on IRC) or meet regularly to discuss the project (like on Gitter or Google Hangout). You can even make those meetings public so other people can listen. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), for example, [hosts office hours every week](https://github.com/cucumber/cucumber-ruby/blob/master/CONTRIBUTING.md#talking-with-other-devs). + +Once you've established leadership roles, don't forget to document how people can attain them! Establish a clear process for how someone can become a maintainer or join a subcommittee in your project, and write it into your GOVERNANCE.md. + +Tools like [Vossibility](https://github.com/icecrime/vossibility-stack) can help you publicly track who is (or isn't) making contributions to the project. Documenting this information avoids the community perception that maintainers are a clique that makes its decisions privately. + +Finally, if your project is on GitHub, consider moving your project from your personal account to an Organization and adding at least one backup admin. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/) make it easier to manage permissions and multiple repositories and protect your project's legacy through [shared ownership](../building-community/#share-ownership-of-your-project). + +## When should I give someone commit access? + +Some people think you should give commit access to everybody who makes a contribution. Doing so could encourage more people to feel ownership of your project. + +On the other hand, especially for bigger, more complex projects, you may want to only give commit access to people who have demonstrated their commitment. There's no one right way of doing it - do what makes you most comfortable! + +If your project is on GitHub, you can use [protected branches](https://help.github.com/articles/about-protected-branches/) to manage who can push to a particular branch, and under which circumstances. + + + +## What are some of the common governance structures for open source projects? + +There are three common governance structures associated with open source projects. + +* **BDFL:** BDFL stands for "Benevolent Dictator for Life". Under this structure, one person (usually the initial author of the project) has final say on all major project decisions. [Python](https://github.com/python) is a classic example. Smaller projects are probably BDFL by default, because there are only one or two maintainers. A project that originated at a company might also fall into the BDFL category. + +* **Meritocracy:** **(Note: the term "meritocracy" carries negative connotations for some communities and has a [complex social and political history](http://geekfeminism.wikia.com/wiki/Meritocracy).)** Under a meritocracy, active project contributors (those who demonstrate "merit") are given a formal decision making role. Decisions are usually made based on pure voting consensus. The meritocracy concept was pioneered by the [Apache Foundation](http://www.apache.org/); [all Apache projects](http://www.apache.org/index.html#projects-list) are meritocracies. Contributions can only be made by individuals representing themselves, not by a company. + +* **Liberal contribution:** Under a liberal contribution model, the people who do the most work are recognized as most influential, but this is based on current work and not historic contributions. Major project decisions are made based on a consensus seeking process (discuss major grievances) rather than pure vote, and strive to include as many community perspectives as possible. Popular examples of projects that use a liberal contribution model include [Node.js](https://nodejs.org/en/foundation/) and [Rust](https://www.rust-lang.org/en-US/). + +Which one should you use? It's up to you! Every model has advantages and trade-offs. And although they may seem quite different at first, all three models have more in common than they seem. If you're interested in adopting one of these models, check out these templates: + +* [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) + +## Do I need governance docs when I launch my project? + +There is no right time to write down your project's governance, but it's much easier to define once you've seen your community dynamics play out. The best (and hardest) part about open source governance is that it is shaped by the community! + +Some early documentation will inevitably contribute to your project's governance, however, so start writing down what you can. For example, you can define clear expectations for behavior, or how your contributor process works, even at your project's launch. + +If you're part of a company launching an open source project, it's worth having an internal discussion before launch about how your company expects to maintain and make decisions about the project moving forward. You may also want to publicly explain anything particular to how your company will (or won't!) be involved with the project. + + + +## What happens if corporate employees start submitting contributions? + +Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project's code as one component in a commercial service offering. + +As the project gets more widely used, people who have expertise in it become more in-demand - you may be one of them! - and will sometimes get paid for work they do in the project. + +It's important to treat commercial activity as normal and as just another source of development energy. Paid developers shouldn't get special treatment over unpaid ones, of course; each contribution must be evaluated on its technical merits. However, people should feel comfortable engaging in commercial activity, and feel comfortable stating their use cases when arguing in favor of a particular enhancement or feature. + +"Commercial" is completely compatible with "open source". "Commercial" just means there is money involved somewhere - that the software is used in commerce, which is increasingly likely as a project gains adoption. (When open source software is used as part of a non-open-source product, the overall product is still "proprietary" software, though, like open source, it might be used for commercial or non-commercial purposes.) + +Like anyone else, commercially-motivated developers gain influence in the project through the quality and quantity of their contributions. Obviously, a developer who is paid for her time may be able to do more than someone who is not paid, but that's okay: payment is just one of many possible factors that could affect how much someone does. Keep your project discussions focused on the contributions, not on the external factors that enable people to make those contributions. + +## Do I need a legal entity to support my project? + +You don't need a legal entity to support your open source project unless you're handling money. + +For example, if you want to create a commercial business, you'll want to set up a C Corp or LLC (if you're based in the US). If you're just doing contract work related to your open source project, you can accept money as a sole proprietor, or set up an LLC (if you're based in the US). + +If you want to accept donations for your open source project, you can set up a donation button (using PayPal or Stripe, for example), but the money won't be tax-deductible unless you are a qualifying nonprofit (a 501c3, if you're in the US). + +Many projects don't wish to go through the trouble of setting up a nonprofit, so they find a nonprofit fiscal sponsor instead. A fiscal sponsor accepts donations on your behalf, usually in exchange for a percentage of the donation. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](http://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) and [Open Collective](https://opencollective.com/opensource) are examples of organizations that serve as fiscal sponsors for open source projects. + + + +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](http://expressjs.com/), a Node-based framework. diff --git a/_articles/ko-KR/legal.md b/_articles/ko-KR/legal.md new file mode 100644 index 00000000000..0039292a9d3 --- /dev/null +++ b/_articles/ko-KR/legal.md @@ -0,0 +1,165 @@ +--- +locale: en-US +title: The Legal Side of Open Source +description: Everything you've ever wondered about the legal side of open source, and a few things you didn't. +class: legal +toc: + why-do-people-care-so-much-about-the-legal-side-of-open-source: "Why do people care so much about the legal side of open source?" + are-public-github-projects-open-source: "Are public GitHub projects open source?" + just-give-me-the-tldr-on-what-i-need-to-protect-my-project: "Just give me the TL;DR on what I need to protect my project" + which-open-source-license-is-appropriate-for-my-project: "Which open source license is appropriate for my project?" + what-if-i-want-to-change-the-license-of-my-project: "What if I want to change the license of my project?" + does-my-project-need-an-additional-contributor-agreement: "Does my project need an additional contributor agreement?" + what-does-my-companys-legal-team-need-to-know: "What does my company’s legal team need to know?" +order: 10 +image: /assets/images/cards/legal.png +related: + - contribute + - leadership +--- + +## Understanding the legal implications of open source + +Sharing your creative work with the world can be an exciting and rewarding experience. It can also mean a bunch of legal things you didn't know you had to worry about. Thankfully, you don't have to start from scratch. We've got your legal needs covered. (Before you dig in, be sure to read our [disclaimer](../notices/).) + +## Why do people care so much about the legal side of open source? + +Glad you asked! When you make a creative work (such as writing, graphics, or code), that work is under exclusive copyright by default. That is, the law assumes that as the author of your work, you have a say in what others can do with it. + +In general, that means nobody else can use, copy, distribute, or modify your work without being at risk of take-downs, shake-downs, or litigation. + +Open source is an unusual circumstance, however, because the author expects that others will use, modify, and share the work. But because the legal default is still exclusive copyright, you need a license that explicitly states these permissions. + +If you don't apply an open source license, everybody who contributes to your project also becomes an exclusive copyright holder of their work. That means nobody can use, copy, distribute, or modify their contributions -- and that "nobody" includes you. + +Finally, your project may have dependencies with license requirements that you weren't aware of. Your project's community, or your employer's policies, may also require your project to use specific open source licenses. We'll cover these situations below. + +## Are public GitHub projects open source? + +When you [create a new project](https://help.github.com/articles/creating-a-new-repository/) on GitHub, you have the option to make the repository **private** or **public**. + +![Create repository](/assets/images/legal/repo-create-name.png) + +**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. + +If you want others to use, copy, 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. + +## Just give me the TL;DR on what I need to protect my project. + +You're in luck, because today, open source licenses are standardized and easy to use. You can copy-paste an existing license directly into your project. + +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are the most popular open source licenses, but there are other options to choose from. You can find the full text of these licenses, and instructions on how to use them, on [choosealicense.com](https://choosealicense.com/). + +When you create a new project on GitHub, you'll be [asked to add a license](https://help.github.com/articles/open-source-licensing/). + + + +## Which open source license is appropriate for my project? + +If you're starting from a blank slate, it's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/). It's short, very easy to understand, and allows anyone to do anything so long as they keep a copy of the license, including your copyright notice. You'll be able to release the project under a different license if you ever need to. + +Otherwise, picking the right open source license for your project depends on your objectives. + +Your project very likely has (or will have) **dependencies**. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). Each of those libraries you depend on will have its own open source license. If each of their licenses is "permissive" (gives the public permission to use, modify, and share, without any condition for downstream licensing), you can use any license you want. Common permissive licenses include MIT, Apache 2.0, ISC, and BSD. + +On the other hand, if any of your dependencies' licenses are "strong copyleft" (also gives public same permissions, subject to condition of using the same license downstream), then your project will have to use the same license. Common strong copyleft licenses include GPLv2, GPLv3, and AGPLv3. + +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 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. + +Your **company** may have specific licensing requirements for its open source projects. For example, it may require a permissive license so that the company can use your project in the company's closed source product. Or your company may require a strong copyleft license and an additional contributor agreement (see below) so that only your company, and nobody else, can use your project in closed source software. Or your company may have certain needs related to standards, social responsibility, or transparency, any of which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know). + +When you create a new project on GitHub, you are given the option to select a license. Including one of the licenses mentioned above will make your GitHub project open source. If you'd like to see other options, check out [choosealicense.com](https://choosealicense.com) to find the right license for your project, even if it [isn't software](https://choosealicense.com/non-software/). + +## What if I want to change the license of my project? + +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: + +**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! + +**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. + +**Your project's existing copyright holders.** If you're the sole contributor to your project then either you or your company is the project's sole copyright holder. You can add or change to whatever license you or your company wants to. Otherwise there may be other copyright holders that you need agreement from in order to change licenses. Who are they? People who have commits in your project is a good place to start. But in some cases copyright will be held by those people's employers. In some cases people will have only made minimal contributions, but there's no hard and fast rule that contributions under some number of lines of code are not subject to copyright. What to do? It depends. For a relatively small and young project, it may be feasible to get all existing contributors to agree to a license change in an issue or pull request. For large and long-lived projects, you may have to seek out many contributors and even their heirs. Mozilla took years (2001-2006) to relicense Firefox, Thunderbird, and related software. + +Alternatively, you can have contributors agree in advance (via an additional contributor agreement -- see below) to certain license changes under certain conditions, beyond those allowed by your existing open source license. This shifts the complexity of changing licenses a bit. You'll need more help from your lawyers up front, and you'll still want to clearly communicate with your project's stakeholders when executing a license change. + +## 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). + +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. + +Also, by adding "paperwork" that some believe is unnecessary, hard to understand, or unfair (when the agreement recipient gets more rights than contributors or the public do via the project's open source license), an additional contributor agreement may be perceived as unfriendly to the project's community. + + + +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 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. + +If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction. + +## What does my company's legal team need to know? + +If you're releasing an open source project as a company employee, first, your legal team should know that you're open sourcing a project. + +For better or worse, consider letting them know even if it's a personal project. You probably have an "employee IP agreement" with your company that gives them some control of your projects, especially if they are at all related to the company's business or you use any company resources to develop the project. Your company _should_ easily give you permission, and maybe already has through an employee-friendly IP agreement or a company policy. If not, you can negotiate (for example, explain that your project serves the company's professional learning and development objectives for you), or avoid working on your project until you find a better company. + +**If you're open sourcing a project for your company,** then definitely let them know. Your legal team probably already has policies for what open source license (and maybe additional contributor agreement) to use based on the company's business requirements and expertise around ensuring your project complies with the licenses of its dependencies. If not, you and they are in luck! Your legal team should be eager to work with you to figure this stuff out. Some things to think about: + +* **Third party material:** Does your project have dependencies created by others or otherwise include or use others' code? If these are open source, you'll need to comply with the materials' open source licenses. That starts with choosing a license that works with the third party open source licenses (see above). If your project modifies or distributes third party open source material, then your legal team will also want to know that you're meeting other conditions of the third party open source licenses such as retaining copyright notices. If your project uses others' code that doesn't have an open source license, you'll probably have to ask the third party maintainers to [add an open source license](https://choosealicense.com/no-license/#for-users), and if you can't get one, stop using their code in your project. + +* **Trade secrets:** Consider whether there is anything in the project that the company does not want to make available to the general public. If so, you could open source the rest of your project, after extracting the material you want to keep private. + +* **Patents:** Is your company applying for a patent of which open sourcing your project would constitute [public disclosure](https://en.wikipedia.org/wiki/Public_disclosure)? Sadly, you might be asked to wait (or maybe the company will reconsider the wisdom of the application). If you're expecting contributions to your project from employees of companies with large patent portfolios, your legal team may want you to use a license with an express patent grant from contributors (such as Apache 2.0 or GPLv3), or an additional contributor agreement (see above). + +* **Trademarks:** Double check that your project's name [does not conflict with any existing trademarks](../starting-a-project/#avoiding-name-conflicts). If you use your own company trademarks in the project, check that it does not cause any conflicts. [FOSSmarks](http://fossmarks.org/) is a practical guide to understanding trademarks in the context of free and open source projects. + +* **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations. + +If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns). + +Longer term, your legal team can do more to help the company get more from its involvement in open source, and stay safe: + +* **Employee contribution policies:** Consider developing a corporate policy that specifies how your employees contribute to open source projects. A clear policy will reduce confusion among your employees and help them contribute to open source projects in the company's best interest, whether as part of their jobs or in their free time. A good example is Rackspace's [Model IP and Open Source Contribution Policy](https://processmechanics.com/2015/07/22/a-model-ip-and-open-source-contribution-policy/). + + + +* **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. + + + +* **Patents:** Your company may wish to join the [Open Invention Network](http://www.openinventionnetwork.com/), a shared defensive patent pool to protect members' use of major open source projects, or explore other [alternative patent licensing](https://www.eff.org/document/hacking-patent-system-2016). +* **Governance:** Especially if and when it makes sense to move a project to a [legal entity outside of the company](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project). diff --git a/_articles/ko-KR/metrics.md b/_articles/ko-KR/metrics.md new file mode 100644 index 00000000000..597594dff2b --- /dev/null +++ b/_articles/ko-KR/metrics.md @@ -0,0 +1,132 @@ +--- +locale: en-US +title: Open Source Metrics +description: Make informed decisions to help your open source project thrive by measuring and tracking its success. +class: metrics +toc: + why-measure-anything: "Why measure anything?" + discovery: "Discovery" + usage: "Usage" + retention: "Retention" + maintainer-activity: "Maintainer activity" +order: 9 +image: /assets/images/cards/metrics.png +related: + - finding + - best-practices +--- + +## Why measure anything? + +Data, when used wisely, can help you make better decisions as an open source maintainer. + +With more information, you can: + +* Understand how users respond to a new feature +* Figure out where new users come from +* Identify, and decide whether to support, an outlier use case or functionality +* Quantify your project's popularity +* Understand how your project is used +* Raise money through sponsorships and grants + +For example, [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) finds that Google Analytics helps them prioritize work: + +> Homebrew is provided free of charge and run entirely by volunteers in their spare time. As a result, we do not have the resources to do detailed user studies of Homebrew users to decide on how best to design future features and prioritise current work. Anonymous aggregate user analytics allow us to prioritise fixes and features based on how, where and when people use Homebrew. + +Popularity isn't everything. Everybody gets into open source for different reasons. If your goal as an open source maintainer is to show off your work, be transparent about your code, or just have fun, metrics may not be important to you. + +If you _are_ interested in understanding your project on a deeper level, read on for ways to analyze your project's activity. + +## Discovery + +Before anybody can use or contribute back to your project, they need to know it exists. Ask yourself: _are people finding this project?_ + +![Traffic graph](/assets/images/metrics/repo_traffic_graphs_tooltip.png) + +If your project is hosted on GitHub, [you can view](https://help.github.com/articles/about-repository-graphs/#traffic) how many people land on your project and where they come from. From your project's page, click "Graphs", then "Traffic". On this page, you can see: + +* **Total page views:** Tells you how many times your project was viewed + +* **Total unique visitors:** Tells you how many people viewed your project + +* **Referring sites:** Tells you where visitors came from. This metric can help you figure out where to reach your audience and whether your promotion efforts are working. + +* **Popular content:** Tells you where visitors go on your project, broken down by page views and unique visitors. + +[GitHub stars](https://help.github.com/articles/about-stars/) can also help provide a baseline measure of popularity. While GitHub stars don't necessarily correlate to downloads and usage, they can tell you how many people are taking notice of your work. + +You may also want to [track discoverability in specific places](https://opensource.com/business/16/6/pirate-metrics): for example, Google PageRank, referral traffic from your project's website, or referrals from other open source projects or websites. + +## Usage + +People are finding your project on this wild and crazy thing we call the internet. Ideally, when they see your project, they'll feel compelled to do something. The second question you'll want to ask is: _are people using this project?_ + +If you use a package manager, such as npm or RubyGems.org, to distribute your project, you may be able to track your project's downloads. + +Each package manager may use a slightly different definition of "download", and downloads do not necessarily correlate to installs or use, but it provides some baseline for comparison. Try using [Libraries.io](https://libraries.io/) to track usage statistics across many popular package managers. + +If your project is on GitHub, navigate again to the "Traffic" page. You can use the [clone graph](https://github.com/blog/1873-clone-graphs) to see how many times your project has been cloned on a given day, broken down by total clones and unique cloners. + +![Clone graph](/assets/images/metrics/clone_graph.png) + +If usage is low compared to the number of people discovering your project, there are two issues to consider. Either: + +* Your project isn't successfully converting your audience, or +* You're attracting the wrong audience + +For example, if your project lands on the front page of Hacker News, you'll probably see a spike in discovery (traffic), but a lower conversion rate, because you're reaching everyone on Hacker News. If your Ruby project is featured at a Ruby conference, however, you're more likely to see a high conversion rate from a targeted audience. + +Try to figure out where your audience is coming from and ask others for feedback on your project page to figure out which of these two issues you're facing. + +Once you know that people are using your project, you might want to try to figure out what they are doing with it. Are they building on it by forking your code and adding features? Are they using it for science or business? + +## Retention + +People are finding your project and they're using it. The next question you'll want to ask yourself is: _are people contributing back to this project?_ + +It's never too early to start thinking about contributors. Without other people pitching in, you risk putting yourself into an unhealthy situation where your project is _popular_ (many people use it) but not _supported_ (not enough maintainer time to meet demand). + +Retention also requires an [inflow of new contributors](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), as previously active contributors will eventually move on to other things. + +Examples of community metrics that you may want to regularly track include: + +* **Total contributor count and number of commits per contributor:** Tells you how many contributors you have, and who's more or less active. On GitHub, you can view this under "Graphs" -> "Contributors." Right now, this graph only counts contributors who have committed to the default branch of the repository. + +![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png) + +* **First time, casual, and repeat contributors:** Helps you track whether you're getting new contributors, and whether they come back. (Casual contributors are contributors with a low number of commits. Whether that's one commit, less than five commits, or something else is up to you.) Without new contributors, your project's community can become stagnant. + +* **Number of open issues and open pull requests:** If these numbers get too high, you might need help with issue triaging and code reviews. + +* **Number of _opened_ issues and _opened_ pull requests:** Opened issues means somebody cares enough about your project to open an issue. If that number increases over time, it suggests people are interested in your project. + +* **Types of contributions:** For example, commits, fixing typos or bugs, or commenting on an issue. + + + +## Maintainer activity + +Finally, you'll want to close the loop by making sure your project's maintainers are able to handle the volume of contributions received. The last question you'll want to ask yourself is: _am I (or are we) responding to our community?_ + +Unresponsive maintainers become a bottleneck for open source projects. If someone submits a contribution but never hears back from a maintainer, they may feel discouraged and leave. + +[Research from Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) suggests that maintainer responsiveness is a critical factor in encouraging repeat contributions. + +Consider tracking how long it takes for you (or another maintainer) to respond to contributions, whether an issue or a pull request. Responding doesn't require taking action. It can be as simple as saying: _"Thanks for your submission! I'll review this within the next week."_ + +You could also measure the time it takes to move between stages in the contribution process, such as: + +* Average time an issue remains open +* Whether issues get closed by PRs +* Whether stale issues get closed +* Average time to merge a pull request + +## Use 📊 to learn about people + +Understanding metrics will help you build an active, growing open source project. Even if you don't track every metric on a dashboard, use the framework above to focus your attention on the type of behavior that will help your project thrive. diff --git a/_articles/ko-KR/starting-a-project.md b/_articles/ko-KR/starting-a-project.md new file mode 100644 index 00000000000..d7b87773431 --- /dev/null +++ b/_articles/ko-KR/starting-a-project.md @@ -0,0 +1,369 @@ +--- +locale: en-US +title: Starting an Open Source Project +description: Learn more about the world of open source and get ready to launch your own project. +class: beginners +toc: + the-what-and-why-of-open-source: "The what and why of open source" + should-i-launch-my-own-open-source-project: "Should I launch my own open source project?" + launching-your-own-open-source-project: "Launching your own open source project" + naming-and-branding-your-project: "Naming and branding your project" + your-pre-launch-checklist: "Your pre-launch checklist" +order: 2 +image: /assets/images/cards/beginner.png +related: + - finding + - building +--- + +## The "what" and "why" of open source + +So you're thinking about getting started with open source? Congratulations! The world appreciates your contribution. Let's talk about what open source is and why people do it. + +### What does "open source" mean? + +When a project is open source, that means **anybody can view, use, modify, and distribute your project for any purpose.** These permissions are enforced through [an open source license](https://opensource.org/licenses). + +Open source is powerful because it lowers the barriers to adoption, allowing ideas to spread quickly. + +To understand how it works, imagine your friend is having a potluck, and you bring a cherry pie. + +* Everybody tries the pie (_use_) +* The pie is a hit! They ask you for the recipe, which you provide (_view_) +* One friend, Alex, who's a pastry chef, suggests reducing the sugar (_modify_) +* Another friend, Lisa, asks to use it for a dinner next week (_distribute_) + +By comparison, a closed source process would be going to a restaurant and ordering a slice of cherry pie. You must pay a fee to eat the pie, and the restaurant probably won't give you their recipe. If you copied their pie exactly and sold it under your own name, the restaurant could take action against you. + +### Why do people open source their work? + + + +[There are many reasons](http://ben.balter.com/2015/11/23/why-open-source/) why a person or organization would want to open source a project. Some examples include: + +* **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). + +* **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). + +Open source isn't just for software, either. You can open source everything from data sets to books. Check out [GitHub Explore](https://github.com/explore) for ideas on what else you can open source. + +### Does open source mean "free of charge"? + +One of open source's biggest draws is that it does not cost money. "Free of charge", however, is a byproduct of open source's overall value. + +Because [an open source license requires](https://opensource.org/osd-annotated) that anyone can use, modify, and share your project for nearly any purpose, projects themselves tend to be free of charge. If the project cost money to use, anyone could legally make a copy and use the free version instead. + +As a result, most open source projects are free, but "free of charge" is not part of the open source definition. There are ways to charge for open source projects indirectly through dual licensing or limited features, while still complying with the official definition of open source. + +## Should I launch my own open source project? + +The short answer is yes, because no matter the outcome, launching your own project is a great way to learn how open source works. + +If you've never open sourced a project before, you might be nervous about what people will say, or whether anyone will notice at all. If this sounds like you, you're not alone! + +Open source work is like any other creative activity, whether it's writing or painting. It can feel scary to share your work with the world, but the only way to get better is to practice - even if you don't have an audience. + +If you're not yet convinced, take a moment to think about what your goals might be. + +### Setting your goals + +Goals can help you figure out what to work on, what to say no to, and where you need help from others. Start by asking yourself, _why am I open sourcing this project?_ + +There is no one right answer to this question. You may have multiple goals for a single project, or different projects with different goals. + +If your only goal is to show off your work, you may not even want contributions, and even say so in your README. On the other hand, if you do want contributors, you'll invest time into clear documentation and making newcomers feel welcome. + + + +As your project grows, your community may need more than just code from you. Responding to issues, reviewing code, and evangelizing your project are all important tasks in an open source project. + +While the amount of time you spend on non-coding tasks will depend on the size and scope of your project, you should be prepared as a maintainer to address them yourself or find someone to help you. + +**If you're part of a company open sourcing a project,** make sure your project has the internal resources it needs to thrive. You'll want to identify who's responsible for maintaining the project after launch, and how you'll share those tasks with your community. + +If you need a dedicated budget or staffing for promotion, operations and maintaining the project, start those conversations early. + + + +### Contributing to other projects + +If your goal is to learn how to collaborate with others or understand how open source works, consider contributing to an existing project. Start with a project that you already use and love. Contributing to a project can be as simple as fixing typos or updating documentation. + +If you're not sure how to get started as a contributor, check out our [How to Contribute to Open Source guide](../how-to-contribute/). + +## Launching your own open source project + +There is no perfect time to open source your work. You can open source an idea, a work in progress, or after years of being closed source. + +Generally speaking, you should open source your project when you feel comfortable having others view, and give feedback on, your work. + +No matter which stage you decide to open source your project, every project should include the following documentation: + +* [Open source license](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) +* [Contributing guidelines](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +* [Code of conduct](../code-of-conduct/) + +As a maintainer, these components will help you communicate expectations, manage contributions, and protect everyone's legal rights (including your own). They significantly increase your chances of having a positive experience. + +If your project is on GitHub, putting these files in your root directory with the recommended filenames will help GitHub recognize and automatically surface them to your readers. + +### Choosing a license + +An open source license guarantees that others can use, copy, modify, and contribute back to your project without repercussions. It also protects you from sticky legal situations. **You must include a license when you launch an open source project.** + +Legal work is no fun. The good news is that you can copy and paste an existing license into your repository. It will only take a minute to protect your hard work. + +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), and [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) are the most popular open source licenses, but [there are other options](https://choosealicense.com) to choose from. + +When you create a new project on GitHub, you are given the option to select a license. Including an open source license will make your GitHub project open source. + +![Pick a license](/assets/images/starting-a-project/repository-license-picker.png) + +If you have other questions or concerns around the legal aspects of managing an open source project, [we've got you covered](../legal/). + +### Writing a README + +READMEs do more than explain how to use your project. They also explain why your project matters, and what your users can do with it. + +In your README, try to answer the following questions: + +* What does this project do? +* Why is this project useful? +* How do I get started? +* Where can I get more help, if I need it? + +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. + +When you include a README file in the root directory, GitHub will automatically display it on the repository homepage. + +### Writing your contributing guidelines + +A CONTRIBUTING file tells your audience how to participate in your project. For example, you might include information on: + +* How to file a bug report (try using [issue and pull request templates](https://github.com/blog/2111-issue-and-pull-request-templates)) +* How to suggest a new feature +* How to set up your environment and run tests + +In addition to technical details, a CONTRIBUTING file is an opportunity to communicate your expectations for contributions, such as: + +* The types of contributions you're looking for +* Your roadmap or vision for the project +* How contributors should (or should not) get in touch with you + +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: + +> First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool. + +In the earliest stages of your project, your CONTRIBUTING file can be simple. You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution. + +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"](http://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. + +![Contributing guidelines](/assets/images/starting-a-project/Contributing-guidelines.jpg) + +### Establishing a code of conduct + + + +Finally, a code of conduct helps set ground rules for behavior for your project's participants. This is especially valuable if you're launching an open source project for a community or company. A code of conduct empowers you to facilitate healthy, constructive community behavior, which will reduce your stress as a maintainer. + +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](http://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. + +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. + +## Naming and branding your project + +Branding is more than a flashy logo or catchy project name. It's about how you talk about your project, and who you reach with your message. + +### Choosing the right name + +Pick a name that is easy to remember and, ideally, gives some idea of what the project does. For example: + +* [Sentry](https://github.com/getsentry/sentry) monitors apps for crash reporting +* [Thin](https://github.com/macournoyer/thin) is a fast and simple Ruby web server + +If you're building upon an existing project, using their name as a prefix can help clarify what your project does (ex. [node-fetch](https://github.com/bitinn/node-fetch) brings `window.fetch` to Node.js). + +Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. Some of your potential users might be company employees: you don't want to make them uncomfortable when they have to explain your project at work! + +### Avoiding name conflicts + +[Check for open source projects with a similar name](http://ivantomic.com/projects/ospnc/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience. + +If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet. + +Make sure that your project's name doesn't infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It's just not worth the risk. + +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/). + +Finally, do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn't want them to see? + +### How you write (and code) affects your brand, too! + +Throughout the life of your project, you'll do a lot of writing: READMEs, tutorials, community documents, responding to issues, maybe even newsletters and mailing lists. + +Whether it's official documentation or a casual email, your writing style is part of your project's brand. Consider how you might come across to your audience and whether that is the tone you wish to convey. + + + +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](http://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. + +## Your pre-launch checklist + +Ready to open source your project? Here's a checklist to help. Check all the boxes? You're ready to go! [Click "publish"](https://help.github.com/articles/making-a-private-repository-public/) and pat yourself on the back. + +**Documentation** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Code** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +**People** + +If you're an individual: + +
+ + +
+ +If you're a company or organization: + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +## You did it! + +Congratulations on open sourcing your first project. No matter the outcome, working in public is a gift to the community. With every commit, comment, and pull request, you're creating opportunities for yourself and for others to learn and grow. From f5a8fb1c6193e3154b636ecb8c666c8925691df1 Mon Sep 17 00:00:00 2001 From: minwook Date: Tue, 10 Oct 2017 16:57:18 +0900 Subject: [PATCH 04/87] change cname --- CNAME | 2 +- _config.yml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/CNAME b/CNAME index 94d502ed2e0..cec092fcb40 100644 --- a/CNAME +++ b/CNAME @@ -1 +1 @@ -opensource.guide +kr.opensource.guide \ No newline at end of file diff --git a/_config.yml b/_config.yml index 5a258cf71b0..1f0b81e4161 100644 --- a/_config.yml +++ b/_config.yml @@ -6,7 +6,7 @@ locale: ko-KR translations: ko-KR: name: Korean - url: https://minwook-shin.github.io/open-source-guide/ + url: https://kr.opensource.guide exclude: - bin From 545f167a258937eecc01dadf0cf71b00680dabe9 Mon Sep 17 00:00:00 2001 From: minwook Date: Tue, 10 Oct 2017 17:47:27 +0900 Subject: [PATCH 05/87] starting part of best-practices translation --- _articles/ko-KR/best-practices.md | 52 +++++++++++++++---------------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/_articles/ko-KR/best-practices.md b/_articles/ko-KR/best-practices.md index 55571ce0607..56e94cd36e4 100644 --- a/_articles/ko-KR/best-practices.md +++ b/_articles/ko-KR/best-practices.md @@ -1,15 +1,15 @@ --- -locale: en-US -title: Best Practices for Maintainers -description: Making your life easier as an open source maintainer, from documenting processes to leveraging your community. -class: best-practices +locale: ko-KR +title: 메인테이너를 위한 모범 사례 +description: 문서화 과정에서 커뮤니티 활용에 이르기까지 오픈 소스 메인테이너로서 여러분의 삶을 편하게 만들어줍니다. +class: 모범-사례 toc: - what-does-it-mean-to-be-a-maintainer: "What does it mean to be a maintainer?" - documenting-your-processes: "Documenting your processes" - learning-to-say-no: "Learning to say no" - leverage-your-community: "Leverage your community" - bring-in-the-robots: "Bring in the robots" - its-okay-to-hit-pause: "It’s okay to hit pause" + what-does-it-mean-to-be-a-maintainer: "메인테이너가 된다는 것은 무엇을 의미하나요?" + documenting-your-processes: "진행과정을 문서화하기" + learning-to-say-no: "아니오라고 말하는 것을 배우기" + leverage-your-community: "커뮤니티 활용하기" + bring-in-the-robots: "로봇 가져오기" + its-okay-to-hit-pause: "정지를 눌러도 좋습니다" order: 5 image: /assets/images/cards/best-practices.png related: @@ -17,7 +17,7 @@ related: - leadership --- -## What does it mean to be a maintainer? +## 메인테이너가 된다는 것은 무엇을 의미하나요? If you maintain an open source project that a lot of people use, you may have noticed you're coding less and responding to issues more. @@ -25,7 +25,7 @@ In the early stages of a project, you're experimenting with new ideas and making Maintaining a project requires more than code. These tasks are often unexpected, but they're just as important to a growing project. We've gathered a few ways to make your life easier, from documenting processes to leveraging your community. -## Documenting your processes +## 진행과정을 문서화하기 Writing things down is one of the most important things you can do as a maintainer. @@ -35,7 +35,7 @@ Writing things down makes it easier to say no when something doesn't fit into yo Even if you don't use full paragraphs, jotting down bullet points is better than not writing at all. -### Write down your project's vision +### 프로젝트의 비전을 써내려가기 Start by writing down the goals of your project. Add them to your README, or create a separate file called VISION. If there are other artifacts that could help, like a project roadmap, make those public as well. @@ -51,7 +51,7 @@ For example, @lord discovered that having a project vision helped him figure out

-### Communicate your expectations +### 생각을 소통하기 Rules can be nerve-wracking to write down. Sometimes you might feel like you're policing other people's behavior or killing all the fun. @@ -72,7 +72,7 @@ Here are a few rules that are worth writing down: [Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) are several examples of projects with ground rules for maintainers and contributors. -### Keep communication public +### 열린 소통을 유지하기 Don't forget to document your interactions, too. Wherever you can, keep communication about your project public. If somebody tries to contact you privately to discuss a feature request or support need, politely direct them to a public communication channel, such as a mailing list or issue tracker. @@ -80,7 +80,7 @@ If you meet with other maintainers, or make a major decision in private, documen That way, anybody who joins your community will have access to the same information as someone who's been there for years. -## Learning to say no +## 아니오라고 말하는 것을 배우기 You've written things down. Ideally, everybody would read your documentation, but in reality, you'll have to remind others that this knowledge exists. @@ -90,7 +90,7 @@ Saying no isn't fun, but _"Your contribution doesn't match this project's crite Saying no applies to many situations you'll come across as a maintainer: feature requests that don't fit the scope, someone derailing a discussion, doing unnecessary work for others. -### Keep the conversation friendly +### 친근한 대화를 유지하기 One of the most important places you'll practice saying no is on your issue and pull request queue. As a project maintainer, you'll inevitably receive suggestions that you don't want to accept. @@ -133,7 +133,7 @@ Don't feel guilty about not wanting to accept someone's contribution. The first Ultimately, if a contribution isn't good enough, you're under no obligation to accept it. Be kind and responsive when people contribute to your project, but only accept changes that you truly believe will make your project better. The more often you practice saying no, the easier it becomes. Promise. -### Be proactive +### 대책 세우기 To reduce the volume of unwanted contributions in the first place, explain your project's process for submitting and accepting contributions in your contributing guide. @@ -156,17 +156,17 @@ While this approach may feel unkind at first, being proactive is actually good f Sometimes, when you say no, your potential contributor may get upset or criticize your decision. If their behavior becomes hostile, [take steps to defuse the situation](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) or even remove them from your community, if they're not willing to collaborate constructively. -### Embrace mentorship +### 멘토십을 포옹하기 Maybe someone in your community regularly submits contributions that don't meet your project's standards. It can be frustrating for both parties to repeatedly go through rejections. If you see that someone is enthusiastic about your project, but needs a bit of polish, be patient. Explain clearly in each situation why their contributions don't meet the expectations of the project. Try pointing them to an easier or less ambiguous task, like an issue marked _"good first bug,"_ to get their feet wet. If you have time, consider mentoring them through their first contribution, or find someone else in your community who might be willing to mentor them. -## Leverage your community +## 커뮤니티 활용하기 You don't have to do everything yourself. Your project's community exists for a reason! Even if you don't yet have an active contributor community, if you have a lot of users, put them to work. -### Share the workload +### 작업량을 분할하기 If you're looking for others to pitch in, start by asking around. @@ -190,7 +190,7 @@ If other people are enthusiastic about its direction, give them commit access or > 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. -### Let others build the solutions they need +### 다른 사람들이 필요한 솔루션을 구축하게하기 If a potential contributor has a different opinion on what your project should do, you may want to gently encourage them to work on their own fork. @@ -208,7 +208,7 @@ The same applies to a user who really wants a solution that you simply don't hav > 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. -## Bring in the robots +## 로봇을 가져오기 Just as there are tasks that other people can help you with, there are also tasks that no human should ever have to do. Robots are your friend. Use them to make your life as a maintainer easier. @@ -230,7 +230,7 @@ If you add tests, make sure to explain how they work in your CONTRIBUTING file.

-### Use tools to automate basic maintenance tasks +### 자동적인 기본 관리 작업 도구를 사용하기 The good news about maintaining a popular project is that other maintainers have probably faced similar issues and built a solution for it. @@ -248,7 +248,7 @@ However, if your standards are too complicated, they can increase the barriers t If you're not sure which tools to use, look at what other popular projects do, especially those in your ecosystem. For example, what does the contribution process look like for other Node modules? Using similar tools and approaches will also make your process more familiar to your target contributors. -## It's okay to hit pause +## 정지를 눌러도 좋습니다 Open source work once brought you joy. Maybe now it's starting to make you feel avoidant or guilty. @@ -274,6 +274,6 @@ Do your best to find support for your users and community while you're away from Taking breaks applies to more than just vacations, too. If you don't want to do open source work on weekends, or during work hours, communicate those expectations to others, so they know not to bother you. -## Take care of yourself first! +## 먼저 자신을 돌보기! Maintaining a popular project requires different skills than the earlier stages of growth, but it's no less rewarding. As a maintainer, you'll practice leadership and personal skills on a level that few people get to experience. While it's not always easy to manage, setting clear boundaries and only taking on what you're comfortable with will help you stay happy, refreshed, and productive. From a88d9bdb308870e750f9581c0ab1174c073b9ecb Mon Sep 17 00:00:00 2001 From: minwook Date: Tue, 10 Oct 2017 17:54:17 +0900 Subject: [PATCH 06/87] Delete CNAME --- CNAME | 1 - 1 file changed, 1 deletion(-) delete mode 100644 CNAME diff --git a/CNAME b/CNAME deleted file mode 100644 index cec092fcb40..00000000000 --- a/CNAME +++ /dev/null @@ -1 +0,0 @@ -kr.opensource.guide \ No newline at end of file From b685f157fe4b5bbaf2b3958a564bfd078f8184e0 Mon Sep 17 00:00:00 2001 From: minwook Date: Tue, 10 Oct 2017 17:55:22 +0900 Subject: [PATCH 07/87] Create CNAME --- CNAME | 1 + 1 file changed, 1 insertion(+) create mode 100644 CNAME diff --git a/CNAME b/CNAME new file mode 100644 index 00000000000..cec092fcb40 --- /dev/null +++ b/CNAME @@ -0,0 +1 @@ +kr.opensource.guide \ No newline at end of file From e849d5a3934f00ef4b9afbb17a7f3ac3bc3c54ed Mon Sep 17 00:00:00 2001 From: minwook Date: Tue, 10 Oct 2017 17:57:49 +0900 Subject: [PATCH 08/87] Delete CNAME --- CNAME | 1 - 1 file changed, 1 deletion(-) delete mode 100644 CNAME diff --git a/CNAME b/CNAME deleted file mode 100644 index cec092fcb40..00000000000 --- a/CNAME +++ /dev/null @@ -1 +0,0 @@ -kr.opensource.guide \ No newline at end of file From a4d45c5be6be3c3ad4aa1bb2c275efd75d64c79a Mon Sep 17 00:00:00 2001 From: minwook Date: Tue, 10 Oct 2017 17:58:52 +0900 Subject: [PATCH 09/87] Create CNAME --- CNAME | 1 + 1 file changed, 1 insertion(+) create mode 100644 CNAME diff --git a/CNAME b/CNAME new file mode 100644 index 00000000000..cec092fcb40 --- /dev/null +++ b/CNAME @@ -0,0 +1 @@ +kr.opensource.guide \ No newline at end of file From 962f13224aafe642f57a112cff317e7ed17f0702 Mon Sep 17 00:00:00 2001 From: minwook Date: Tue, 10 Oct 2017 18:16:06 +0900 Subject: [PATCH 10/87] update translate --- _articles/ko-KR/best-practices.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/_articles/ko-KR/best-practices.md b/_articles/ko-KR/best-practices.md index 56e94cd36e4..de77a80b89e 100644 --- a/_articles/ko-KR/best-practices.md +++ b/_articles/ko-KR/best-practices.md @@ -19,11 +19,11 @@ related: ## 메인테이너가 된다는 것은 무엇을 의미하나요? -If you maintain an open source project that a lot of people use, you may have noticed you're coding less and responding to issues more. +많은 사람들이 사용하는 오픈 소스 프로젝트를 유지한다면, 적은 양으로 코딩하고 더 많은 이슈에 대응할 수 있습니다. -In the early stages of a project, you're experimenting with new ideas and making decisions based on what you want. As your project increases in popularity, you'll find yourself working with your users and contributors more. +프로젝트 초기 단계에서 새로운 아이디어를 실험하고 원하는 것을 기반으로 의사 결정을 내리고 있습니다. 프로젝트의 인기가 높아짐에 따라 사용자와 기여자들과 더 잘 일할 수 있습니다. -Maintaining a project requires more than code. These tasks are often unexpected, but they're just as important to a growing project. We've gathered a few ways to make your life easier, from documenting processes to leveraging your community. +프로젝트를 유지하려면 코드 이상을 요구합니다. 이러한 작업은 예상치 못한 경우가 많지만 성장하는 프로젝트와 마찬가지로 중요합니다. 우리는 프로세스 문서화에서부터 커뮤니티 활용에 이르기까지 당신의 삶을 편하게 해주는 몇 가지 방법을 모아봤습니다. ## 진행과정을 문서화하기 From 4a01d716e76a6d86a51a3739372d079b2a0ffcf1 Mon Sep 17 00:00:00 2001 From: minwook Date: Tue, 10 Oct 2017 18:22:53 +0900 Subject: [PATCH 11/87] rollback english config --- _config.yml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/_config.yml b/_config.yml index 1f0b81e4161..f26ed45720e 100644 --- a/_config.yml +++ b/_config.yml @@ -4,6 +4,10 @@ description: "프로젝트를 시작하고 성장시키는 방법에 대해 알 # See: docs/translations.md locale: ko-KR translations: + en-US: + name: English (US) + url: https://opensource.guide + ko-KR: name: Korean url: https://kr.opensource.guide From 011a9a82433c3114ce4a8ea045291628b0e6e308 Mon Sep 17 00:00:00 2001 From: minwook Date: Wed, 11 Oct 2017 11:08:13 +0900 Subject: [PATCH 12/87] change cname(kr to ko) --- CNAME | 2 +- _config.yml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/CNAME b/CNAME index cec092fcb40..0cb97e277bb 100644 --- a/CNAME +++ b/CNAME @@ -1 +1 @@ -kr.opensource.guide \ No newline at end of file +ko.opensource.guide \ No newline at end of file diff --git a/_config.yml b/_config.yml index f26ed45720e..2e9f8ab6132 100644 --- a/_config.yml +++ b/_config.yml @@ -10,7 +10,7 @@ translations: ko-KR: name: Korean - url: https://kr.opensource.guide + url: https://ko.opensource.guide exclude: - bin From 3b9ddcd77e97f1e945bac6462abdaa94eb3ebf69 Mon Sep 17 00:00:00 2001 From: minwook Date: Sat, 14 Oct 2017 11:26:21 +0900 Subject: [PATCH 13/87] Translating to the documenting part --- _articles/ko-KR/best-practices.md | 44 +++++++++++++++---------------- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/_articles/ko-KR/best-practices.md b/_articles/ko-KR/best-practices.md index de77a80b89e..9904b66f407 100644 --- a/_articles/ko-KR/best-practices.md +++ b/_articles/ko-KR/best-practices.md @@ -27,58 +27,58 @@ related: ## 진행과정을 문서화하기 -Writing things down is one of the most important things you can do as a maintainer. +글을 작성하는 것은 메인테이너가 할 수있는 가장 중요한 일 중 하나입니다. -Documentation not only clarifies your own thinking, but it helps other people understand what you need or expect, before they even ask. +문서는 자신의 생각을 분명히 할 뿐만 아니라, 다른 사람들이 물어보기도 전에 필요하거나 기대하는 것을 이해하도록 도와줍니다. -Writing things down makes it easier to say no when something doesn't fit into your scope. It also makes it easier for people to pitch in and help. You never know who might be reading or using your project. +글을 쓰게되면 무언가가 당신의 범위에 맞지 않을 때 아무 말도 하지 않게됩니다. 또한 사람들이 쉽게 참여하고 도움을 줍니다. 누가 프로젝트를 읽고 사용하는지 알 수 없습니다. -Even if you don't use full paragraphs, jotting down bullet points is better than not writing at all. +전체 단락을 사용하지 않더라도, 글 머리 기호를 적어 두는 것이 아에 작성하지 않는것보다 좋습니다. ### 프로젝트의 비전을 써내려가기 -Start by writing down the goals of your project. Add them to your README, or create a separate file called VISION. If there are other artifacts that could help, like a project roadmap, make those public as well. +먼저 프로젝트의 목표를 써내려갑니다. README에 추가하거나, VISION이라 불리는 별도의 파일을 작성하십시오. 프로젝트 로드맵과 같이 도움이 될 수있는 다른 인위적인 결과물이 있는 경우, 이를 공개 할 수도 있습니다. -Having a clear, documented vision keeps you focused and helps you avoid "scope creep" from others' contributions. +명확하고, 문서화 된 비전을 가지고 있으면 집중력을 유지하고 다른 기여자로부터 "scope creep"를 피할 수 있습니다. -For example, @lord discovered that having a project vision helped him figure out which requests to spend time on. As a new maintainer, he regretted not sticking to his project's scope when he got his first feature request for [Slate](https://github.com/lord/slate). +예를 들어, @lord는 프로젝트 비전을 가짐으로써 시간을 보낼 요청을 파악하는 데 도움이 된다는 것을 발견했습니다. 새로운 관리자인, 그는 [Slate](https://github.com/lord/slate)에 대한 첫 번째 기능 요청을 받았을 때 프로젝트의 범위를 고수하지 않은 것을 후회했습니다. ### 생각을 소통하기 -Rules can be nerve-wracking to write down. Sometimes you might feel like you're policing other people's behavior or killing all the fun. +규칙은 신경 쓰면 더 쓰일 수 있습니다. 때로는 다른 사람들의 행동을 감시하거나 모든 재미를 없애는 것처럼 느껴질 수도 있습니다. -Written and enforced fairly, however, good rules empower maintainers. They prevent you from getting dragged into doing things you don't want to do. +그러나 공정하게 작성되고 시행되면, 좋은 규칙은 메인테이너에게 힘을 줍니다. 그것들은 당신이 하고 싶지 않은 일을 하도록 끌리지 못하게 합니다. -Most people who come across your project don't know anything about you or your circumstances. They may assume you get paid to work on it, especially if it's something they regularly use and depend on. Maybe at one point you put a lot of time into your project, but now you're busy with a new job or family member. +프로젝트를 직접 경험하는 대부분의 사람들은 당신 혹은 당신이 겪는 상황에 대해 알지 못합니다. 그들은 당신이 그것에 대해 일하기 위해 돈을 받는다고 가정 할 지도 모릅니다, 특히 그들이 정기적으로 사용하고 의존하는 것이지요. 어쩌면 한번에 프로젝트에다가 많은 시간을 할애하지만, 이제는 새로운 직업이나 가족 구성원으로 바쁩니다. -All of this is perfectly okay! Just make sure other people know about it. +이 모든 것은 완벽하게 괜찮습니다! 다른 사람들이 그것에 대해 알고 있는지 확인하시기 바랍니다. -If maintaining your project is part-time or purely volunteered, be honest about how much time you have. This is not the same as how much time you think the project requires, or how much time others want you to spend. +당신의 프로젝트를 파트 타임으로 유지하거나 순수하게 자원봉사하는 경우, 당신이 가진 시간에 대해 솔직하게 말하십시오. 이것은 프로젝트가 요구하는 시간, 또는 다른 사람들이 당신의 개발에 소비하기를 원하는 시간과 같지 않습니다. -Here are a few rules that are worth writing down: +다음과 같은 몇 가지 규칙을 적어 두는 것이 좋습니다: -* How a contribution is reviewed and accepted (_Do they need tests? An issue template?_) -* The types of contributions you'll accept (_Do you only want help with a certain part of your code?_) -* When it's appropriate to follow up (_ex. "You can expect a response from a maintainer within 7 days. If you haven't heard anything by then, feel free to ping the thread."_) -* How much time you spend on the project (_ex. "We only spend about 5 hours per week on this project"_) +* 기여를 검토하고 수락하는 방법 (_Do they need tests? An issue template?_) +* 당신이 수락할 기여 유형 (_Do you only want help with a certain part of your code?_) +* 후속 조치가 필요한 순간 (_ex. "You can expect a response from a maintainer within 7 days. If you haven't heard anything by then, feel free to ping the thread."_) +* 프로젝트에 할애하는 시간 (_ex. "We only spend about 5 hours per week on this project"_) -[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) are several examples of projects with ground rules for maintainers and contributors. +[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), 및 [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md)는 메인테이너와 기여자를 위한 기본 원칙이 있는 프로젝트의 몇 가지 예시입니다. ### 열린 소통을 유지하기 -Don't forget to document your interactions, too. Wherever you can, keep communication about your project public. If somebody tries to contact you privately to discuss a feature request or support need, politely direct them to a public communication channel, such as a mailing list or issue tracker. +상호 작용을 문서화하는 것을 잊지 마십시오. 가능한 모든 곳에서 프로젝트 공개에 대한 소통을 유지하십시오. 누군가가 개인적으로 연락하여 기능 요청 또는 지원 필요성에 대해 토론하려고하면, 정중하게 메일링 리스트 또는 이슈 트래커와 같은 공개 소통 채널로 안내합니다. -If you meet with other maintainers, or make a major decision in private, document these conversations in public, even if it's just posting your notes. +다른 관리자와 만나거나, 비공개로 중요한 결정을 내릴 경우, 또는 메모를 게시하는 경우에도 마찬가지로, 공개적으로 문서를 기록하십시오. -That way, anybody who joins your community will have access to the same information as someone who's been there for years. +그러면, 커뮤니티에 가입 한 사람은 수년간 그 곳에 있었던 사람과 동일한 정보에 접근 할 수 있습니다. ## 아니오라고 말하는 것을 배우기 From a3a4884dccc7d2bf68d053f616d6a88bfaa27849 Mon Sep 17 00:00:00 2001 From: minwook Date: Sat, 14 Oct 2017 11:56:54 +0900 Subject: [PATCH 14/87] more...translating.. --- _articles/ko-KR/best-practices.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/_articles/ko-KR/best-practices.md b/_articles/ko-KR/best-practices.md index 9904b66f407..ccd001c9480 100644 --- a/_articles/ko-KR/best-practices.md +++ b/_articles/ko-KR/best-practices.md @@ -82,23 +82,24 @@ related: ## 아니오라고 말하는 것을 배우기 -You've written things down. Ideally, everybody would read your documentation, but in reality, you'll have to remind others that this knowledge exists. +당신이 글을 썼습니다. 이상적으로 모든 사람이 당신의 문서를 읽을 것이지만, 실제로, 이 지식이 존재한다는 것을 다른 사람들에게 상기시켜야 할 것입니다. -Having everything written down, however, helps depersonalize situations when you do need to enforce your rules. +그러나 모든 것을 적어두면, 규칙을 집행해야 할 상황일때 평범한 상황으로 만드는 것에 도움이 됩니다. -Saying no isn't fun, but _"Your contribution doesn't match this project's criteria"_ feels less personal than _"I don't like your contribution"_. +아니오라고 말하는 것은 재미 없지만, _"Your contribution doesn't match this project's criteria"_ 는 _"I don't like your contribution"_ 보다 개인적인 느낌이 들었습니다. + +당신이 메인테이너로서 만날 수 있는 많은 상황에 적용됩니다: 범위에 맞지 않는 기능 요청, 토론을 이탈한 사람, 불필요한 다른 일을 하는 사람. -Saying no applies to many situations you'll come across as a maintainer: feature requests that don't fit the scope, someone derailing a discussion, doing unnecessary work for others. ### 친근한 대화를 유지하기 -One of the most important places you'll practice saying no is on your issue and pull request queue. As a project maintainer, you'll inevitably receive suggestions that you don't want to accept. +가장 중요한 장소 중 하나인 No라고 말하면서 이슈와 pull request 대기열을 가져옵니다. 프로젝트 메인테이너로서, 여러분은 받아들이기를 원치 않는 제안을 필연적으로 받게됩니다. -Maybe the contribution changes your project's scope or doesn't match your vision. Maybe the idea is good, but the implementation is poor. +기여 내용이 프로젝트의 범위를 변경하거나 비전과 일치하지 않을 수 있습니다. 어쩌면 그 아이디어가 좋지만 구현도가 낮을 수 있습니다. -Regardless of the reason, it is possible to tactfully handle contributions that don't meet your project's standards. +이유에 관계없이, 프로젝트 표준에 맞지 않는 기여 내용을 현명하게 처리 할 수 있습니다. -If you receive a contribution you don't want to accept, your first reaction might be to ignore it or pretend you didn't see it. Doing so could hurt the other person's feelings and even demotivate other potential contributors in your community. +동의를 원하지않는 기여를 받는 경우, 첫 번째 반응은 그것을 무시하거나 보지 못했다고 가장 할 수 있습니다. 이렇게 하면 다른 사람의 감정에 해를 끼칠 수 있으며 커뮤니티 내의 다른 잠재적인 기여자의 능력을 떨어뜨릴 수도 있습니다. -Don't leave an unwanted contribution open because you feel guilty or want to be nice. Over time, your unanswered issues and PRs will make working on your project feel that much more stressful and intimidating. +죄책감을 느끼거나 좋은 사람이 되기위해 원하지 않는 기여는 하지마십시오. 시간이 지남에 귀하의 답변되지 않은 이슈와 PR은 프로젝트에 대한 작업을 훨씬 더 스트레스와 협박으로 느낄 것입니다. -It's better to immediately close the contributions you know you don't want to accept. If your project already suffers from a large backlog, @steveklabnik has suggestions for [how to triage issues efficiently](http://words.steveklabnik.com/how-to-be-an-open-source-gardener). +수락하고 싶지 않은 기여는 즉시 닫는 것이 좋습니다. 프로젝트에 이미 많은 양의 백로그가있는 경우 @steveklabnik 는 [문제를 효율적으로 분류하는 방법](http://words.steveklabnik.com/how-to-be-an-open-source-gardener)에 대한 제안 사항을 제공합니다. -Secondly, ignoring contributions sends a negative signal to your community. Contributing to a project can be intimidating, especially if it's someone's first time. Even if you don't accept their contribution, acknowledge the person behind it and thank them for their interest. It's a big compliment! +둘째로, 기여를 무시하면 귀하의 커뮤니티에 부정적인 신호가 보내집니다. 프로젝트에 기여하는 것은 위협적일 수 있습니다. 특히 다른 사람이 처음 인 경우에는 더욱 그렇습니다. 기여를 수락하지 않더라도 그 뒤에 있는 사람을 인정하고 관심을 가져 주신 것에 감사하길 바랍니다. 큰 칭찬입니다! -If you don't want to accept a contribution: +기여를 받지 않는 경우: -* **Thank them** for their contribution -* **Explain why it doesn't fit** into the scope of the project, and offer clear suggestions for improvement, if you're able. Be kind, but firm. -* **Link to relevant documentation**, if you have it. If you notice repeated requests for things you don't want to accept, add them into your documentation to avoid repeating yourself. -* **Close the request** +* 그들의 기여에 **감사합니다** +* 가능한 경우 프로젝트의 **범위에 맞지 않는 이유를 설명하고** 개선을 위한 명확한 제안을 합니다. 친절하지만 단호하게 하십시오. +* 필요한 경우 **관련 문서에 링크합니다**. 수락하고 싶지 않은 것에 대한 반복적인 요청을 발견 한 경우, 문서를 반복하여 반복하지 않도록 합시다. +* **request를 닫습니다** -You shouldn't need more than 1-2 sentences to respond. For example, when a user of [celery](https://github.com/celery/celery/) reported a Windows-related error, @berkerpeksag [responded with](https://github.com/celery/celery/issues/3383): +응답하는 데 1-2 문장 이상 필요하지 않습니다. 예시로,[celery](https://github.com/celery/celery/)의 사용자가 윈도우 관련 오류를 보고 했을때, @berkerpeksag [이렇게 반응합니다](https://github.com/celery/celery/issues/3383): ![Celery screenshot](/assets/images/best-practices/celery.png) -If the thought of saying no terrifies you, you're not alone. As @jessfraz [put it](https://blog.jessfraz.com/post/the-art-of-closing/): +아무도 말을 하지않는다고 해도, @jessfraz [put it](https://blog.jessfraz.com/post/the-art-of-closing/)처럼 혼자가 아닙니다: > 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. -Don't feel guilty about not wanting to accept someone's contribution. The first rule of open source, [according to](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"No is temporary, yes is forever."_ While empathizing with another person's enthusiasm is a good thing, rejecting a contribution is not the same as rejecting the person behind it. +누군가의 기여를 받아들이지 않으려고 죄책감을 느끼지 마십시오. 오픈소스의 첫 규칙은, @shykes [에 따르면](https://twitter.com/solomonstre/status/715277134978113536): _"아니오는 일시적이며 예는 영원합니다."_ 다른 사람의 열정에 공감하는 것은 좋은 일이지만 기여를 거절하는 것은 그 뒤에있는 사람을 거절하는 것과 동일하지 않습니다. -Ultimately, if a contribution isn't good enough, you're under no obligation to accept it. Be kind and responsive when people contribute to your project, but only accept changes that you truly believe will make your project better. The more often you practice saying no, the easier it becomes. Promise. +궁극적으로, 기여가 충분하지 않은 경우, 기여를 수락 할 의무가 없습니다. 사람들이 프로젝트에 기여할 때 친절하고 반응적이어야 하지만, 프로젝트를 더 좋게 만들 것이라고 생각되는 변경 사항만 수락하십시오. 더 자주 아니오라고 말아는 연습을 하면 쉽게 됩니다. 약속합시다. ### 대책 세우기 -To reduce the volume of unwanted contributions in the first place, explain your project's process for submitting and accepting contributions in your contributing guide. +처음에 원치 않는 기여를 줄이려면, 기여 가이드에 기여를 제출하고 수락하는 프로젝트 프로세스를 설명하십시오. -If you're receiving too many low-quality contributions, require that contributors do a bit of work beforehand, for example: +너무 많은 저품질 기여를 받는다면, 이와 같이 기여자들이 미리 약간의 작업을 해줄 것을 요구하십시오: -* Fill out a issue or PR template/checklist -* Open an issue before submitting a PR +* 이슈 또는 PR 템플릿/체크리스트 작성하기 +* PR을 제출하기 전에 이슈를 열기 -If they don't follow your rules, close the issue immediately and point to your documentation. +만약 그들이 규칙에 따르지 않는다면, 즉시 이슈를 닫고 문서를 가리킵니다. -While this approach may feel unkind at first, being proactive is actually good for both parties. It reduces the chance that someone will put in many wasted hours of work into a pull request that you aren't going to accept. And it makes your workload easier to manage. +이러한 접근 방식이 처음에는 불친절하다고 느낄 수도 있지만, 사전 대책은 실제로 각자에게도 좋습니다. 그것은 누군가가 당신이 받아 들일 수 없는 pull request에 많은 시간 낭비를 초래할 가능성을 줄여줍니다. 또한 작업 부하를 보다 쉽게 ​​관리 할 수 ​​있습니다. -Sometimes, when you say no, your potential contributor may get upset or criticize your decision. If their behavior becomes hostile, [take steps to defuse the situation](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) or even remove them from your community, if they're not willing to collaborate constructively. +때로는 아니오라고 말하면 잠재적 기여자가 결정을 뒤집거나 비판 할 수 있습니다. 그들의 행동이 적대적이된다면, [상황을 완화시키기위한 조치를 취하십시오.](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) 또는 건설적으로 협업하지 않으려는 경우 커뮤니티에서 제거 할 수도 있습니다. + ### 멘토십을 포옹하기 -Maybe someone in your community regularly submits contributions that don't meet your project's standards. It can be frustrating for both parties to repeatedly go through rejections. +커뮤니티의 누군가가 프로젝트 표준에 맞지 않는 기여를 정기적으로 제출할 수도 있습니다. 각자 당사자가 거절을 반복해서 거치는 것은 좌절 할 수 있습니다. -If you see that someone is enthusiastic about your project, but needs a bit of polish, be patient. Explain clearly in each situation why their contributions don't meet the expectations of the project. Try pointing them to an easier or less ambiguous task, like an issue marked _"good first bug,"_ to get their feet wet. If you have time, consider mentoring them through their first contribution, or find someone else in your community who might be willing to mentor them. +누군가 당신의 프로젝트에 열성적이지만 약간의 닦기가 필요하다면 인내심을 가집시다. 그들의 공헌이 프로젝트의 기대에 부합하지 않는 이유를 각 상황에서 분명하게 설명합니다. 발을 젖게하기 위해 _"good first bug,"_라고 표시된 문제와 같이 더 쉽거나 덜 모호한 작업을 가리키도록 하십시오. 시간이 있다면, 첫 번째 기여를 통해 멘토링을 고려하거나 멘토를 기꺼이 도울 수있는 다른 사람을 커뮤니티에서 찾을 수 있습니다. ## 커뮤니티 활용하기 -You don't have to do everything yourself. Your project's community exists for a reason! Even if you don't yet have an active contributor community, if you have a lot of users, put them to work. +당신은 모든 것을 스스로 할 필요가 없습니다. 프로젝트 공동체가 존재합니다! 적극적으로 참여한 커뮤니티가 없는 경우에도 많은 사용자가 있는 경우, 일하도록하십시오. ### 작업량을 분할하기 -If you're looking for others to pitch in, start by asking around. +피치를 받을 다른 사람을 찾고 있다면 주위에 물어보십시오. + +새로운 기여자가 반복적으로 기여를 하는 것을 보았을 때, 더 많은 책임을 제공함으로써 자신의 업무로 인정합시다. 원한다면 다른 사람들이 리더십 역할로 성장할 수 있는 방법을 문서화하십시오. -When you see new contributors making repeated contributions, recognize their work by offering more responsibility. Document how others can grow into leadership roles if they wish. +@lmccart가 프로젝트 [p5.js](https://github.com/processing/p5.js?files=1)에서 발견한대로 [프로젝트 소유권 공유](../building-community/#share-ownership-of-your-project)를 권장하면 자신의 작업량을 크게 줄일 수 있습니다. -Encouraging others to [share ownership of the project](../building-community/#share-ownership-of-your-project) can greatly reduce your own workload, as @lmccart discovered on her project, [p5.js](https://github.com/processing/p5.js?files=1). -If you need to step away from your project, either on hiatus or permanently, there's no shame in asking someone else to take over for you. +프로젝트가 중단되거나 영구히 중단되어야하는 경우, 다른 사람에게 자신을 대신하도록 요청하는 것은 부끄러운 일이 아닙니다. -If other people are enthusiastic about its direction, give them commit access or formally hand over control to someone else. If someone forked your project and is actively maintaining it elsewhere, consider linking to the fork from your original project. It's great that so many people want your project to live on! +다른 사람들이 그 방향에 열성적이라면, 그들에게 접근을 허용하거나 공식적으로 다른 사람에게 통제 권한을 넘겨주도록 하십시오. 다른 사람이 프로젝트를 포크하고 다른 곳에서 적극적으로 유지 관리하는 경우, 원래 프로젝트의 포크에 연결하는 것이 좋습니다. 많은 사람들이 귀하의 프로젝트가 살아가기를 원합니다! -@progrium [found that](http://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) documenting the vision for his project, [Dokku](https://github.com/dokku/dokku), helped those goals live on even after he stepped away from the project: +@progrium은 프로젝트의 비전을 문서화 [한 것으로 밝혀지면서](http://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) [Dokku](https://github.com/dokku/dokku)가 프로젝트에서 물러 난 후에도 이러한 목표를 달성 할 수 있도록 도왔습니다. > 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. ### 다른 사람들이 필요한 솔루션을 구축하게하기 -If a potential contributor has a different opinion on what your project should do, you may want to gently encourage them to work on their own fork. +잠재적 기여자가 프로젝트에서 해야 할 일에 대해 다른 견해를 가지고 있다면, 그들을 자신의 포크로 작업하도록 부드럽게 격려하고 싶을 수 있습니다. -Forking a project doesn't have to be a bad thing. Being able to copy and modify projects is one of the best things about open source. Encouraging your community members to work on their own fork can provide the creative outlet they need, without conflicting with your project's vision. +프로젝트 포킹은 나쁜 일이 아닙니다. 프로젝트를 복사하고 수정할 수 있다는 것이 오픈 소스에 관한 가장 좋은 것 중 하나입니다. 커뮤니티 회원들이 자신의 포크로 작업하도록 권장하면 프로젝트 비전과 상충하지 않고, 필요한 창의적인 판로를 제공 할 수 있습니다. -The same applies to a user who really wants a solution that you simply don't have the bandwidth to build. Offering APIs and customization hooks can help others meet their own needs, without having to modify the source directly. @orta [found that](http://artsy.github.io/blog/2016/07/03/handling-big-projects/) encouraging plugins for CocoaPods led to "some of the most interesting ideas": +실제로 대역폭을 구축 할 필요가 없는 솔루션을 원하는 사용자에게도 마찬가지입니다. API 및 사용자 정의 후크를 제공하면 소스를 직접 수정하지 않고도 다른 사람들이 자신의 필요를 충족시킬 수 있습니다. @orta는 CocoaPods용 플러그인이 "가장 흥미로운 아이디어 중 일부"를 이끌어 냈다는 것을 [알게 되었습니다](http://artsy.github.io/blog/2016/07/03/handling-big-projects/) > 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. ## 로봇을 가져오기 -Just as there are tasks that other people can help you with, there are also tasks that no human should ever have to do. Robots are your friend. Use them to make your life as a maintainer easier. +다른 사람들이 당신을 도울 수있는 작업이있는 것처럼, 인간도 할 일이 없어야합니다. 로봇은 당신의 친구입니다. 그것들을 사용하여 메인테이너로서의 삶을 더 쉽게 만듭니다. -### Require tests and other checks to improve the quality of your code +### 코드의 품질을 향상시키는 데 필요한 테스트 및 기타 검사 One of the most important ways you can automate your project is by adding tests. From da0a078fee6339053e9ae12f5f0ca411fc8ba1d9 Mon Sep 17 00:00:00 2001 From: minwook Date: Mon, 16 Oct 2017 13:48:54 +0900 Subject: [PATCH 16/87] translated this file --- _articles/ko-KR/best-practices.md | 52 ++++++++++++++++--------------- 1 file changed, 27 insertions(+), 25 deletions(-) diff --git a/_articles/ko-KR/best-practices.md b/_articles/ko-KR/best-practices.md index 3208bf7b173..ea0c013c0e8 100644 --- a/_articles/ko-KR/best-practices.md +++ b/_articles/ko-KR/best-practices.md @@ -213,70 +213,72 @@ related: ## 로봇을 가져오기 -다른 사람들이 당신을 도울 수있는 작업이있는 것처럼, 인간도 할 일이 없어야합니다. 로봇은 당신의 친구입니다. 그것들을 사용하여 메인테이너로서의 삶을 더 쉽게 만듭니다. +다른 사람들이 당신을 도울 수있는 작업이 있는 것처럼, 인간도 할 일이 없어야합니다. 로봇은 당신의 친구입니다. 그것들을 사용하여 메인테이너로서의 삶을 더 쉽게 만듭니다. ### 코드의 품질을 향상시키는 데 필요한 테스트 및 기타 검사 -One of the most important ways you can automate your project is by adding tests. +프로젝트를 자동화하는 가장 중요한 방법 중 하나는 테스트를 추가하는 것입니다. -Tests help contributors feel confident that they won't break anything. They also make it easier for you to review and accept contributions quickly. The more responsive you are, the more engaged your community can be. +테스트는 기여자가 아무 것도 깨뜨리지 않을 것이라고 확신하는 데 도움이 됩니다. 또한 기여를 신속하게 검토하고 수락하기가 더 쉽습니다. 반응이 좋을수록 커뮤니티의 참여도가 높아집니다. -Set up automatic tests that will run on all incoming contributions, and ensure that your tests can easily be run locally by contributors. Require that all code contributions pass your tests before they can be submitted. You'll help set a minimum standard of quality for all submissions. [Required status checks](https://help.github.com/articles/about-required-status-checks/) on GitHub can help ensure no change gets merged without your tests passing. +들어오는 모든 기여에 대해 실행할 자동 테스트를 설정하고, 기여자가 테스트를 로컬에서 쉽게 실행할 수 있도록 하십시오. 제출하기 전에 모든 코드가 테스트에 합격해야합니다. 모든 제출물에 대해 최소한의 품질 기준을 설정하는 데 도움이됩니다. GitHub의 [Required status checks](https://help.github.com/articles/about-required-status-checks/)는 테스트 통과없이 변경 사항이 병합되지 않도록 도와줍니다. -If you add tests, make sure to explain how they work in your CONTRIBUTING file. +만약 테스트를 추가한다면, 그들이 당신의 CONTRIBUTING 파일에서 어떻게 작동하는지 설명합시다. ### 자동적인 기본 관리 작업 도구를 사용하기 -The good news about maintaining a popular project is that other maintainers have probably faced similar issues and built a solution for it. +인기있는 프로젝트를 유지하는 것에 대한 좋은 소식은 다른 메인테이너가 비슷한 문제에 직면해 있고 그에 대한 해결책을 마련한다는 것입니다. -There are a [variety of tools available](https://github.com/showcases/tools-for-open-source) to help automate some aspects of maintenance work. A few examples: +유지 보수 작업의 일부 측면을 자동화하는 데 도움이되는 [다양한 도구](https://github.com/showcases/tools-for-open-source)가 있습니다. 약간의 예시입니다: -* [semantic-release](https://github.com/semantic-release/semantic-release) automates your releases -* [mention-bot](https://github.com/facebook/mention-bot) mentions potential reviewers for pull requests -* [Danger](https://github.com/danger/danger) helps automate code review +* [semantic-release](https://github.com/semantic-release/semantic-release) 릴리즈를 자동화하기 +* [mention-bot](https://github.com/facebook/mention-bot) pull requests를 위한 잠재적 검토자 언급하기 +* [Danger](https://github.com/danger/danger) 코드 리뷰 자동화를 도와주기 -For bug reports and other common contributions, GitHub has [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates), which you can create to streamline the communication you receive. You can also set up [email filters](https://github.com/blog/2203-email-updates-about-your-own-activity) to manage your email notifications. -If you want to get a little more advanced, style guides and linters can standardize project contributions and make them easier to review and accept. +버그 보고서 및 기타 일반적인 공헌을 위해 GitHub는 [이슈 템플랫과 Pull Request 템플랫](https://github.com/blog/2111-issue-and-pull-request-templates)를 제공합니다, 귀하가 받을 수있는 커뮤니케이션을 합리화하기 위해 만들 수 있습니다. [이메일 필터](https://github.com/blog/2203-email-updates-about-your-own-activity)를 설정하여 전자 메일 알림을 관리 할 수도 있습니다. -However, if your standards are too complicated, they can increase the barriers to contribution. Make sure you're only adding enough rules to make everyone's lives easier. +좀 더 진보적인 스타일을 원한다면, 스타일 가이드와 linter가 프로젝트 기여를 표준화하고 검토하고 받아들이기가 쉬워질 수 있습니다. -If you're not sure which tools to use, look at what other popular projects do, especially those in your ecosystem. For example, what does the contribution process look like for other Node modules? Using similar tools and approaches will also make your process more familiar to your target contributors. +그러나, 표준이 너무 복잡하면, 기여에 대한 장벽이 높아질 수 있습니다. 모든 사람의 삶을 편하게 하기위한 규칙만 추가하고 있는지 확인하십시오. + +어떤 도구를 사용해야하는지 잘 모르는 경우 다른 인기있는 프로젝트, 특히 생태계에 있는 프로젝트를 살펴보십시오. 예를 들어, 다른 Node 모듈에 대한 기여 프로세스는 어떻게됩니까? 유사한 도구와 접근 방식을 사용하면 프로세스가 대상 기여자에게 더 익숙하게됩니다. ## 정지를 눌러도 좋습니다 -Open source work once brought you joy. Maybe now it's starting to make you feel avoidant or guilty. +오픈 소스 작업은 한 때 기쁨을 가져다주었습니다만. 어쩌면 이제는 회피하거나 죄책감을 느낄 수 있습니다. -Perhaps you're feeling overwhelmed or a growing sense of dread when you think about your projects. And meanwhile, the issues and pull requests pile up. +아마도 당신은 당신의 프로젝트에 대해 생각할 때 압도 당하거나 두려움에 시달리고 있습니다. 그리고 그 동안 이슈와 pull request가 늘어납니다. -Burnout is a real and pervasive issue in open source work, especially among maintainers. As a maintainer, your happiness is a non-negotiable requirement for the survival of any open source project. +Burnout은 특히 메인테이너 간에 오픈소스 작업에서 실제로 발생하는 보편적인 문제입니다. 메인테이너로서 여러분의 행복은 모든 오픈소스 프로젝트의 생존을 위한 협상을 할 수 없는 요구 사항입니다. -Although it should go without saying, take a break! You shouldn't have to wait until you feel burned out to take a vacation. @brettcannon, a Python core developer, decided to take [a month-long vacation](http://www.snarky.ca/why-i-took-october-off-from-oss-volunteering) after 14 years of volunteer OSS work. +아무 말도하지 말고 쉬쉽시오! 휴가를 위해 번아웃될 때까지 기다릴 필요가 없습니다. +파이썬 핵심 개발자인 @brettcannon은 14년간 OSS 자원 봉사를 한 후 [1개월간의 휴가](http://www.snarky.ca/why-i-took-october-off-from-oss-volunteering)를 하기로 결정했습니다. -Just like any other type of work, taking regular breaks will keep you refreshed, happy, and excited about your work. +다른 유형의 일과 마찬가지로 정기적인 휴식을 취하면 일에 대해 새롭고, 행복하며, 흥분을 유지할 수 있습니다. -Sometimes, it can be hard to take a break from open source work when it feels like everybody needs you. People may even try to make you feel guilty for stepping away. +때때로, 모든 사람들이 당신을 필요로 할 때 오픈소스 작업에서 휴식을 취하는 것이 어려울 수 있습니다. 사람들은 심지어 당신이 발걸음을 딛고 죄책감을 갖도록하려고 할 수도 있습니다. -Do your best to find support for your users and community while you're away from a project. If you can't find the support you need, take a break anyway. Be sure to communicate when you're not available, so people aren't confused by your lack of responsiveness. +프로젝트를 떠나려는 동안 사용자와 커뮤니티에 대한 지원을 찾으려면 최선을 다하십시오. 필요한 지원을 찾을 수 없으면 어쨌든 휴식을 취하십시오. 사용할 수 없을 때, 반드시 의사 소통을 해야하므로 응답성이 부족하게하여 사람들에게 혼동을 주지 않도록하십시오. -Taking breaks applies to more than just vacations, too. If you don't want to do open source work on weekends, or during work hours, communicate those expectations to others, so they know not to bother you. +휴식을 취하는 것은 방학기간 이상 적용됩니다. 주말이나 근무 시간 중에 오픈소스 작업을 하고싶지 않다면, 그 계획을 다른 사람들에게 알려줌으로써 그들은 당신을 귀찮게하지 않을 것입니다. ## 먼저 자신을 돌보기! -Maintaining a popular project requires different skills than the earlier stages of growth, but it's no less rewarding. As a maintainer, you'll practice leadership and personal skills on a level that few people get to experience. While it's not always easy to manage, setting clear boundaries and only taking on what you're comfortable with will help you stay happy, refreshed, and productive. +인기있는 프로젝트를 유지하려면 성장 초기 단계와는 다른 기술이 필요하지만 그다지 보람이 없습니다. 메인테이너로서, 소수의 사람들이 경험할 수 있는 수준에서 리더십과 개인 기술을 연습하게됩니다. 관리가 항상 쉬운 것은 아니지만, 명확한 경계를 설정하고 자신이 편안하게 느끼는 것을 취하는 것만으로도 행복하고 생기 넘치며 생산적으로 머물 수 있습니다. From c086b419ecf7c8d570dc8b40b888861c1ec968fe Mon Sep 17 00:00:00 2001 From: minwook Date: Mon, 16 Oct 2017 13:58:36 +0900 Subject: [PATCH 17/87] starting translation this file --- _articles/ko-KR/building-community.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/_articles/ko-KR/building-community.md b/_articles/ko-KR/building-community.md index fb3cc512335..82a890a413b 100644 --- a/_articles/ko-KR/building-community.md +++ b/_articles/ko-KR/building-community.md @@ -1,12 +1,12 @@ --- -locale: en-US -title: Building Welcoming Communities -description: Building a community that encourages people to use, contribute to, and evangelize your project. -class: building +locale: ko-KR +title: 환영하는 커뮤니티 구축 +description: 사람들이 프로젝트를 사용하고, 기여하고, 전파하도록 격려하는 커뮤니티를 구축합니다. +class: 구축 toc: - setting-your-project-up-for-success: "Setting your project up for success" - growing-your-community: "Growing your community" - resolving-conflicts: "Resolving conflicts" + setting-your-project-up-for-success: "성공을 위한 프로젝트 설정하기" + growing-your-community: "커뮤니티 성장하기" + resolving-conflicts: "충돌 해결하기" order: 4 image: /assets/images/cards/building.png related: From 3f74d0ec2d000db20ac34c0a0f12f2ac292efa09 Mon Sep 17 00:00:00 2001 From: minwook Date: Mon, 16 Oct 2017 14:09:24 +0900 Subject: [PATCH 18/87] translate title --- _articles/ko-KR/building-community.md | 34 +++++++++++++-------------- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/_articles/ko-KR/building-community.md b/_articles/ko-KR/building-community.md index 82a890a413b..2d0339d4f10 100644 --- a/_articles/ko-KR/building-community.md +++ b/_articles/ko-KR/building-community.md @@ -14,13 +14,13 @@ related: - coc --- -## Setting your project up for success +## 성공을 위한 프로젝트 설정하기 You've launched your project, you're spreading the word, and people are checking it out. Awesome! Now, how do you get them to stick around? A welcoming community is an investment into your project's future and reputation. If your project is just starting to see its first contributions, start by giving early contributors a positive experience, and make it easy for them to keep coming back. -### Make people feel welcome +### 사람들이 환영받는다고 느끼게하기 One way to think about your project's community is through what @MikeMcQuaid calls the [contributor funnel](https://speakerdeck.com/mikemcquaid/the-open-source-contributor-funnel): @@ -52,7 +52,7 @@ The majority of open source contributors are "casual contributors": people who c Encouraging other contributors is an investment in yourself, too. When you empower your biggest fans to run with the work they're excited about, there's less pressure to do everything yourself. -### Document everything +### 모든 곳에 문서화하기 -### Pick your battles wisely +### 현명하게 전투를 선택하기 Context is important. Consider who is involved in the discussion and how they represent the rest of the community. @@ -266,7 +266,7 @@ Is everybody in the community upset about, or even engaged with, this issue? Or If the issue does not represent the broader needs of your community, you may just need to acknowledge the concerns of a few people. If this is a recurring issue without a clear resolution, point them to previous discussions on the topic and close the thread. -### Identify a community tiebreaker +### 커뮤니티 동점자 식별하기 With a good attitude and clear communication, most difficult situations are resolvable. However, even in a productive conversation, there can simply be a difference in opinion on how to proceed. In these cases, identify an individual or group of people that can serve as a tiebreaker. @@ -274,6 +274,6 @@ A tiebreaker could be the primary maintainer of the project, or it could be a sm Your tiebreaker should be a last resort. Divisive issues are an opportunity for your community to grow and learn. Embrace these opportunities and use a collaborative process to move to a resolution wherever possible. -## Community is the ❤️ of open source +## 커뮤니티는 오픈소스의 ❤️ 입니다 Healthy, thriving communities fuel the thousands of hours poured into open source every week. Many contributors point to other people as the reason for working - or not working - on open source. By learning how to tap into that power constructively, you'll help someone out there have an unforgettable open source experience. From 0bd7b7f34f1e29cbc6cd0f042e3fc56c8a89c237 Mon Sep 17 00:00:00 2001 From: minwook Date: Mon, 16 Oct 2017 14:46:50 +0900 Subject: [PATCH 19/87] update translate --- _articles/ko-KR/building-community.md | 42 +++++++++++++-------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/_articles/ko-KR/building-community.md b/_articles/ko-KR/building-community.md index 2d0339d4f10..bf691764c72 100644 --- a/_articles/ko-KR/building-community.md +++ b/_articles/ko-KR/building-community.md @@ -16,29 +16,29 @@ related: ## 성공을 위한 프로젝트 설정하기 -You've launched your project, you're spreading the word, and people are checking it out. Awesome! Now, how do you get them to stick around? +프로젝트를 시작하고, 단어를 전파하면, 사람들이 그것을 확인하고 있습니다. 굉장합니다! 자, 어떻게 그들을 주변에 붙이게 할까요? -A welcoming community is an investment into your project's future and reputation. If your project is just starting to see its first contributions, start by giving early contributors a positive experience, and make it easy for them to keep coming back. +환영하는 커뮤니티는 프로젝트의 미래와 평판에 대한 투자입니다. 프로젝트가 처음으로 기여한 것을 보기 시작한 경우, 초반 참여자에게 긍정적인 경험을 제공하고, 그들이 계속해서 다시 돌아올 수 있도록 하십시오. ### 사람들이 환영받는다고 느끼게하기 -One way to think about your project's community is through what @MikeMcQuaid calls the [contributor funnel](https://speakerdeck.com/mikemcquaid/the-open-source-contributor-funnel): +프로젝트 커뮤니티에 대해 생각하는 한 가지 방법은 @MikeMcQuaid는 [contributor funnel](https://speakerdeck.com/mikemcquaid/the-open-source-contributor-funnel)라고 했습니다: ![Contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png) -As you build your community, consider how someone at the top of the funnel (a potential user) might theoretically make their way to the bottom (an active maintainer). Your goal is to reduce friction at each stage of the contributor experience. When people have easy wins, they will feel incentivized to do more. +커뮤니티를 구축하면서 깔때기의 맨 위에 있는 누군가(잠재 사용자)가 이론적으로 맨 아래(활동중인 관리자)로 나아갈 수있는 방법을 생각해보십시오. 목표는 기여자 환경의 각 단계에서 마찰을 줄이는 것입니다. 사람들이 쉽게 이를 이겨낸다면, 더 많은 일을 하도록 동기 부여를 느낄 것입니다. -Start with your documentation: +문서화로 시작하기: -* **Make it easy for someone to use your project.** [A friendly README](../starting-a-project/#writing-a-readme) and clear code examples will make it easier for anyone who lands on your project to get started. -* **Clearly explain how to contribute**, using [your CONTRIBUTING file](../starting-a-project/#writing-your-contributing-guidelines) and keeping your issues up-to-date. +* **프로젝트를 쉽게 사용할 수 있도록하십시오.** [친숙한 README](../starting-a-project/#writing-a-readme)와 명확한 코드 예제를 사용하면 프로젝트에 착수한 모든 사람이 쉽게 시작할 수 있습니다. +* **기여 방법을 분명히 설명하십시오.**, [CONTRIBUTING 파일](../starting-a-project/#writing-your-contributing-guidelines)를 사용하고 이슈를 최신 상태로 유지하시기바랍니다. -[GitHub's 2017 Open Source Survey](http://opensourcesurvey.org/2017/) showed incomplete or confusing documentation is the biggest problem for open source users. Good documentation invites people to interact with your project. Eventually, someone will open an issue or pull request. Use these interactions as opportunities to move them down the funnel. +[깃허브의 2017 오픈소스 설문](http://opensourcesurvey.org/2017/)에 따르면 불완전하거나 혼란스러운 문서가 오픈소스 사용자에게 가장 큰 문제임이 드러났습니다. 좋은 문서는 사람들이 프로젝트와 상호 작용하도록 유도합니다. 결국 누군가가 이슈를 열거나 pull request를 합니다. 이러한 상호 작용을 통해 유입 경로로 이동할 수 있습니다. -* **When someone new lands on your project, thank them for their interest!** It only takes one negative experience to make someone not want to come back. -* **Be responsive.** If you don't respond to their issue for a month, chances are, they've already forgotten about your project. -* **Be open-minded about the types of contributions you'll accept.** Many contributors start with a bug report or small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help. -* **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#learning-to-say-no) it doesn't fit into the scope of the project, linking to relevant documentation if you have it. +* **누군가 새로운 프로젝트를 시작했을 때 관심을 가져주셔서 감사합니다!** 누군가가 돌아오고 싶지 않게 만드는 것은 오직 하나의 부정적인 경험을 필요로 합니다. +* **반응합니다.** 한 달 동안 문제에 답변하지 않으면, 프로젝트에 대해 이미 잊어 버렸을 가능성이 있습니다. +* **받아 들일 수있는 기여 유형에 대해 개방적이어야합니다.** 많은 기여자는 버그 신고 또는 작은 수정으로 시작합니다.프로젝트에 [기여 할 수 있는 많은 방법](../how-to-contribute/#what-it-means-to-contribute)이 있습니다. 사람들이 어떻게 도와주고 싶어하는지 돕도록하십시오. +* **당신이 동의하지 않는 기여가 있다면,** 그들에게 아이디어에 대해 감사하고, 프로젝트의 범위에 맞지 않는 [이유를 설명](../best-practices/#learning-to-say-no)하고, 관련 문서에 링크하면됩니다. -The majority of open source contributors are "casual contributors": people who contribute to a project only occasionally. A casual contributor may not have time to get fully up to speed with your project, so your job is to make it easy for them to contribute. +오픈 소스 제공자의 대다수는 "임시 기여자"입니다. 때때로 프로젝트에만 기여하는 사람들입니다. 캐주얼 기여자는 프로젝트 진행 속도를 최대로 끌어 올릴 시간이 없을 수도 있기 때문에, 당신의 일은 그들이 기여하기 쉽게 만드는 것입니다. -Encouraging other contributors is an investment in yourself, too. When you empower your biggest fans to run with the work they're excited about, there's less pressure to do everything yourself. +다른 참여자를 격려하는 것은 자신에게도 투자입니다. 가장 열렬한 팬에게 흥분을 줄 수있는 힘을 실어 줄 때, 모든 것을 스스로 할 수있는 부담이 줄어 듭니다. ### 모든 곳에 문서화하기 @@ -62,19 +62,19 @@ Encouraging other contributors is an investment in yourself, too. When you empow

-When you start a new project, it may feel natural to keep your work private. But open source projects thrive when you document your process in public. +새로운 프로젝트를 시작하면, 작업을 비공개로 유지하는 것이 자연스럽게 느껴질 수 있습니다. 그러나 오픈소스 프로젝트는 공개적으로 프로세스를 문서화 할 때 번창합니다. -When you write things down, more people can participate at every step of the way. You might get help on something you didn't even know you needed. +당신이 일을 적을 때, 더 많은 사람들이 모든 단계에서 참여할 수 있습니다. 자신이 필요로 하지 않는 것에 대해서 도움을 받을 수도 있습니다. -Writing things down means more than just technical documentation. Any time you feel the urge to write something down or privately discuss your project, ask yourself whether you can make it public. +사물을 쓰는 것은 기술 문서 이상의 것을 의미합니다. 뭔가를 쓰거나 프로젝트에 대해 개인적으로 토론할 충동을 느낄 때마다, 공개 할 수 있는지 스스로에게 자문 해보십시오. -Be transparent about your project's roadmap, the types of contributions you're looking for, how contributions are reviewed, or why you made certain decisions. +프로젝트의 로드맵, 찾고있는 기여 유형, 기여 검토 방법 또는 특정 결정을 한 이유에 대해 투명하게 하십시오. -If you notice multiple users running into the same problem, document the answers in the README. +여러 사용자가 동일한 문제를 겪고있는 경우, README에 답변을 문서화하십시오. -For meetings, consider publishing your notes or takeaways in a relevant issue. The feedback you'll get from this level of transparency may surprise you. +회의의 경우, 관련 문제에 메모나 테이크아웃을 게시하는 것을 고려하십시오. 이 투명성 수준에서 얻을 수있는 피드백은 당신을 놀라게 할 수 있습니다. -Documenting everything applies to the work you do, too. If you're working on a substantial update to your project, put it into a pull request and mark it as a work in progress (WIP). That way, other people can feel involved in the process early on. +모든 것을 문서화하는 것은 당신이 하는 일에도 적용됩니다. 프로젝트에 대한 실질적인 업데이트를 진행중인 경우, pull request에 넣고 진행중인 작업 (WIP)으로 표시합니다. 그렇게하면 다른 사람들이 조기에 프로세스에 참여할 수 있습니다. ### 반응하기 From e680f0dc4ad545004bc01bce41e9215f711c8ed4 Mon Sep 17 00:00:00 2001 From: minwook Date: Mon, 16 Oct 2017 14:49:23 +0900 Subject: [PATCH 20/87] update translate --- _articles/ko-KR/building-community.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_articles/ko-KR/building-community.md b/_articles/ko-KR/building-community.md index bf691764c72..f4147b88770 100644 --- a/_articles/ko-KR/building-community.md +++ b/_articles/ko-KR/building-community.md @@ -44,7 +44,7 @@ related: avatar Contributing to open source is easier for some than others. There's a lot of fear of being yelled at for not doing something right or just not fitting in. (...) By giving contributors a place to contribute with very low technical proficiency (documentation, web content markdown, etc) you can greatly reduce those concerns.

-— @mikeal, ["Growing a contributor base in modern open source"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source) +— @mikeal, ["평범한 오픈소스를 기반으로하는 기여자 키우기"](https://opensource.com/life/16/5/growing-contributor-base-modern-open-source)

From a2251a6510a3bc9dc956d53daed19858a455ecf7 Mon Sep 17 00:00:00 2001 From: minwook Date: Tue, 17 Oct 2017 13:24:06 +0900 Subject: [PATCH 21/87] update translate --- _articles/ko-KR/building-community.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/_articles/ko-KR/building-community.md b/_articles/ko-KR/building-community.md index f4147b88770..df95ae946eb 100644 --- a/_articles/ko-KR/building-community.md +++ b/_articles/ko-KR/building-community.md @@ -92,13 +92,13 @@ Conversations about your project could also be happening in other places around ### 커뮤니티에 모일 곳을 제공하기 -There are two reasons to give your community a place to congregate. +커뮤니티에 모일 수 있는 이유는 두 가지입니다. -The first reason is for them. Help people get to know each other. People with common interests will inevitably want a place to talk about it. And when communication is public and accessible, anybody can read past archives to get up to speed and participate. +첫번째 이유는 그들을 위한 것입니다. 사람들이 서로를 알게 도와주세요. 공통 관심사를 가진 사람들은 필연적으로 그것에 대해 이야기 할 곳을 원할 것입니다. 커뮤니케이션이 공개되고 접근이 용이할 때, 누구나 과거 아카이브를 읽어 신속하게 참여하고 참여할 수 있습니다. -The second reason is for you. If you don't give people a public place to talk about your project, they will likely contact you directly. In the beginning, it may seem easy enough to respond to private messages "just this once". But over time, especially if your project becomes popular, you will feel exhausted. Resist the temptation to communicate with people about your project in private. Instead, direct them to a designated public channel. +두 번째 이유는 당신을 위한 것입니다. 사람들에게 프로젝트에 관해 이야기 할 수 있는 공공장소를 제공하지 않으면 직접 연락을 취할 것입니다. 처음에는 개인 메시지에 "단지 한 번" 응답하는 것만큼 쉬운 것처럼 보일 수 있습니다. 그러나 시간이 지남에 따라 프로젝트가 대중화되면 특히 고갈 될 것입니다. 개인적으로 프로젝트에 대한 사람들과 소통하려는 유혹에 현혹되지 마십시오. 대신 지정된 공개 채널로 안내하십시오. -Public communication can be as simple as directing people to open an issue instead of emailing you directly or commenting on your blog. You could also set up a mailing list, or create a Twitter account, Slack, or IRC channel for people to talk about your project. Or try all of the above! +공개 커뮤니케이션은 사람들에게 직접 이메일을 보내거나 블로그에 댓글을다는 대신 문제를 열도록 지시하는 것처럼 간단 할 수 있습니다. 또한 메일 링리스트를 설정하거나 Twitter 계정, 슬랙 또는 IRC 채널을 만들어 사람들이 프로젝트에 관해 이야기 할 수 있습니다. 또는 위의 모든 것을 시도하십시오! [Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) sets aside office hours every other week to help community members: From d930f87fa1f74610cda500a8b610640c5924df02 Mon Sep 17 00:00:00 2001 From: minwook Date: Wed, 18 Oct 2017 09:24:01 +0900 Subject: [PATCH 22/87] update some text translate --- _articles/ko-KR/building-community.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/_articles/ko-KR/building-community.md b/_articles/ko-KR/building-community.md index df95ae946eb..c71ca802a47 100644 --- a/_articles/ko-KR/building-community.md +++ b/_articles/ko-KR/building-community.md @@ -58,7 +58,7 @@ related: avatar 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, ["지속가능한 오픈소스"](http://writing.jan.io/2015/11/20/sustainable-open-source.html)

@@ -78,13 +78,13 @@ related: ### 반응하기 -As you [promote your project](../finding-users), people will have feedback for you. They may have questions about how things work, or need help getting started. +당신의 [프로젝트를 홍보](../finding-users)하는 것처럼, 사람들은 당신을 위해 의견을 갖습니다. 그들은 어떻게 일을하는지, 시작하는 데 도움이 필요하다는 것에 대해 질문을 할 수 있습니다. -Try to be responsive when someone files an issue, submits a pull request, or asks a question about your project. When you respond quickly, people will feel they are part of a dialogue, and they'll be more enthusiastic about participating. +누군가가 문제를 제기하거나, pull request를 제출하거나, 프로젝트에 관한 질문을 하면 반응을 좋게 하십시오. 신속하게 대처할 때, 사람들은 대화의 일부라고 느낄 것이며, 참여에 더 열렬해질 것입니다. Even if you can't review the request immediately, acknowledging it early helps increase engagement. Here's how @tdreyno responded to a pull request on [Middleman](https://github.com/middleman/middleman/pull/1466): -![Middleman pull request](/assets/images/building-community/middleman_pr.png) +![중개인 pull request](/assets/images/building-community/middleman_pr.png) [A Mozilla study found that](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) contributors who received code reviews within 48 hours had a much higher rate of return and repeat contribution. @@ -120,7 +120,7 @@ Do your best to adopt a zero-tolerance policy towards these types of people. If avatar The truth is that having a supportive community is key. I'd never be able to do this work without the help of my colleagues, friendly internet strangers, and chatty IRC channels. (...) Don't settle for less. Don't settle for assholes.

-— @karissa, ["How to Run a FOSS Project"](https://karissa.github.io/post/okf-de) +— @karissa, ["FOSS 프로젝트를 어떻게 실행하는가"](https://karissa.github.io/post/okf-de)

From 6bef811716f1d01b51207e5a185352da1187e19e Mon Sep 17 00:00:00 2001 From: minwook Date: Wed, 18 Oct 2017 14:11:11 +0900 Subject: [PATCH 23/87] translate almost this part --- _articles/ko-KR/building-community.md | 107 +++++++++++++------------- 1 file changed, 54 insertions(+), 53 deletions(-) diff --git a/_articles/ko-KR/building-community.md b/_articles/ko-KR/building-community.md index c71ca802a47..bd97f8bbc39 100644 --- a/_articles/ko-KR/building-community.md +++ b/_articles/ko-KR/building-community.md @@ -82,13 +82,13 @@ related: 누군가가 문제를 제기하거나, pull request를 제출하거나, 프로젝트에 관한 질문을 하면 반응을 좋게 하십시오. 신속하게 대처할 때, 사람들은 대화의 일부라고 느낄 것이며, 참여에 더 열렬해질 것입니다. -Even if you can't review the request immediately, acknowledging it early helps increase engagement. Here's how @tdreyno responded to a pull request on [Middleman](https://github.com/middleman/middleman/pull/1466): +요청을 즉시 검토 할 수 없더라도 조기에 이를 인정하면 참여를 늘리는 데 도움이됩니다. @tdreyno가 [Middleman](https://github.com/middleman/middleman/pull/1466)의 pull request에 응답 한 방법은 다음과 같습니다: ![중개인 pull request](/assets/images/building-community/middleman_pr.png) -[A Mozilla study found that](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) contributors who received code reviews within 48 hours had a much higher rate of return and repeat contribution. +48 시간 내에 코드 리뷰를 받은 기여자들이 훨씬 더 높은 수익률과 반복 기여도를 보였습니다는 것을 [모질라 스터디가 발견했습니다](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177). -Conversations about your project could also be happening in other places around the internet, such as Stack Overflow, Twitter, or Reddit. You can set up notifications in some of these places so you are alerted when someone mentions your project. +스택 오버플로우, 트위터 또는 레딧과 같은 인터넷상의 다른 장소에서도 프로젝트에 대한 토의가 발생할 수 있습니다. 이러한 장소중 일부에서 알림을 설정하여 누군가가 프로젝트를 언급 할 때 알림을받을 수 있습니다. ### 커뮤니티에 모일 곳을 제공하기 @@ -100,21 +100,21 @@ Conversations about your project could also be happening in other places around 공개 커뮤니케이션은 사람들에게 직접 이메일을 보내거나 블로그에 댓글을다는 대신 문제를 열도록 지시하는 것처럼 간단 할 수 있습니다. 또한 메일 링리스트를 설정하거나 Twitter 계정, 슬랙 또는 IRC 채널을 만들어 사람들이 프로젝트에 관해 이야기 할 수 있습니다. 또는 위의 모든 것을 시도하십시오! -[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) sets aside office hours every other week to help community members: +[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved)은 커뮤니티 회원들을 돕기 위해 격주로 근무 시간을 따로 지정합니다: -> 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. +> Kops는 또한 격주로 커뮤니티에 도움과 안내를 제공하기 위해 시간을 마련했습니다. Kops 메인테이너는 신규 이민자와의 협력, 홍보 및 새로운 기능 토론에 전념 한 시간을 별도로 마련하기로 동의했습니다. -Notable exceptions to public communication are: 1) security issues and 2) sensitive code of conduct violations. You should always have a way for people to report these issues privately. If you don't want to use your personal email, set up a dedicated email address. +공공 커뮤니케이션에 대한 주목할만한 예외로는: 1) 보안 문제와 2) 민감한 행동 규범 위반이 있습니다. 사람들이 이러한 문제를 개인적으로 보고 할 수있는 방법을 항상 마련해야합니다. 개인 이메일을 사용하지 않으려면 전용 이메일 주소를 설정하십시오. ## 커뮤니티 성장하기 -Communities are extremely powerful. That power can be a blessing or a curse, depending on how you wield it. As your project's community grows, there are ways to help it become a force of construction, not destruction. +커뮤니티는 매우 강력합니다. 그 힘은 어떻게 사용하는지에 따라 축복이나 저주가 될 수 있습니다. 프로젝트 공동체가 성장함에 따라, 그것이 파괴가 아닌 건설의 힘이 될 수 있도록 돕는 방법이 있습니다. ### 나쁜 배우를 용서하지 말기 -Any popular project will inevitably attract people who harm, rather than help, your community. They may start unnecessary debates, quibble over trivial features, or bully others. +모든 인기있는 프로젝트는 필연적으로 커뮤니티를 돕기보다는, 해를 입는 사람들을 끌어 들일 것입니다. 그들은 불필요한 논쟁을 시작하거나, 사소한 기능을 말다툼하거나, 다른 사람들을 괴롭힐 수 있습니다. -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. +이러한 유형의 사람들에 대한 제로-관용 정책을 채택하기 위해 최선을 다하십시오. 선택하지 않는다면, 부정적인 사람들이 커뮤니티의 다른 사람들을 불편하게 만듭니다. 그들은 심지어 떠날지도 모릅니다. -Regular debates over trivial aspects of your project distracts others, including you, from focusing on important tasks. New people who arrive to your project may see these conversations and not want to participate. +프로젝트의 사소한 측면에 대한 정기적인 토의는 중요한 작업에 집중하는 것을 포함하여, 다른 사람을 혼란스럽게합니다. 프로젝트에 도착한 새로운 사람들은 이러한 대화를 보고 참여하기를 원하지 않을 수 있습니다. -When you see negative behavior happening on your project, call it out publicly. Explain, in a kind but firm tone, why their behavior is not acceptable. If the problem persists, you may need to [ask them to leave](../code-of-conduct/#enforcing-your-code-of-conduct). Your [code of conduct](../code-of-conduct/) can be a constructive guide for these conversations. +프로젝트에서 부정적인 행동이 발생하면, 공개적으로 말합니다. 친절하지만 확고한 어조로 왜 그들의 행동이 용납되지 않는지 설명합니다. 문제가 지속되면, [떠날 것을 요청해야 할 수도 있습니다](../code-of-conduct/#enforcing-your-code-of-conduct). [행동 규범](../code-of-conduct/)은 이 대화를 위해 건설적인 가이드가 될겁니다. ### 장소에 있는 기여자를 만나기 -Good documentation only becomes more important as your community grows. Casual contributors, who may not otherwise be familiar with your project, read your documentation to quickly get the context they need. +훌륭한 문서는 커뮤니티가 성장함에 따라 중요해질 것입니다. 프로젝트에 익숙하지 않은 캐주얼 기여자는, 필요한 컨텍스트를 빨리 얻기 위해 문서를 읽습니다. -In your CONTRIBUTING file, explicitly tell new contributors how to get started. You may even want to make a dedicated section for this purpose. [Django](https://github.com/django/django), for example, has a special landing page to welcome new contributors. +CONTRIBUTING 파일에서 새 참여자에게 시작 방법을 명시하십시오. 이러한 목적으로 전용 섹션을 만들고 싶을 수도 있습니다. [Django](https://github.com/django/django)를 예로 들어보면, 새로운 참여자를 환영 할 수 있는 특별 방문 페이지가 있습니다. -![Django new contributors page](/assets/images/building-community/django_new_contributors.png) +![Django 새로운 기여자 페이지](/assets/images/building-community/django_new_contributors.png) -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 bug"_, 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. +이슈 대기열에서, 기여자의 다른 유형에 적합한 버그 라벨을 붙이십시오: 예를 들어, [_"first timers only"_](https://medium.com/@kentcdodds/first-timers-only-78281ea47455#.g1k01jy05), _"good first bug"_, 혹은 _"documentation"_이 있습니다. [이 라벨들은](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) +프로젝트에 익숙하지 않은 사용자가 문제를 신속하게 스캔하고 시작하기가 쉽습니다. -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): +예시로, 여기 [Rubinius](https://github.com/rubinius/rubinius/)가 [기여 가이드](https://github.com/rubinius/rubinius/blob/master/.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. +> Rubinius를 사용해 주셔서 감사드립니다. 이 프로젝트는 사랑의 노동이며, 버그를 포착하고 성능을 개선하며, 문서화에 도움이 되는 모든 사용자에게 감사드립니다. 모든 기여는 의미가 있으므로, 참여해 주셔서 감사합니다. 말하지면, 우리가 귀하의 문제를 성공적으로 해결할 수 있도록 따라야 할 몇 가지 지침이 있습니다. ### 당신의 프로젝트의 소유권 공유하기 @@ -152,49 +153,49 @@ For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts avatar Your leaders will have different opinions, as all healthy communities should! However, you need to take steps to ensure the loudest voice doesn't always win by tiring people out, and that less prominent and minority voices are heard.

-— @sarahsharp, ["What makes a good community?"](http://sarah.thesharps.us/2015/10/06/what-makes-a-good-community/) +— @sarahsharp, ["좋은 커뮤니티는 어떻게 만듭니까?"](http://sarah.thesharps.us/2015/10/06/what-makes-a-good-community/)

-People are excited to contribute to projects when they feel a sense of ownership. That doesn't mean you need to turn over your project's vision or accept contributions you don't want. But the more you give credit to others, the more they'll stick around. +사람들은 소유권을 느낄 때 프로젝트에 기여하게 되어 기쁩니다. 그렇다고 해서 프로젝트의 비전을 뒤집거나 원하지 않는 기여를 받아 들일 필요가 있다는 것을 의미하지는 않습니다. 그러나 당신이 다른 사람에게 더 많은 것을 줄수록, 더 많이 붙어있게됩니다. -See if you can find ways to share ownership with your community as much as possible. Here are some ideas: +가능한 커뮤니티와 소유권을 공유하는 방법을 찾을 수 있는지 확인하십시오. 다음은 몇 가지 아이디어입니다: -* **Resist fixing easy (non-critical) bugs.** Instead, use them as opportunities to recruit new contributors, or mentor someone who'd like to contribute. It may seem unnatural at first, but your investment will pay off over time. For example, @michaeljoseph asked a contributor to submit a pull request on a [Cookiecutter](https://github.com/audreyr/cookiecutter) issue below, rather than fix it himself. +* **쉬운(중요하지 않은) 버그를 수정하는 것을 방지**하는 대신, 그것들로 새로운 기부자를 모집 할 기회로 사용하거나, 기여하고자 하는 사람을 멘토링하십시오. 초기에는 부자연스럽게 보일 수 있지만, 시간이 지남에 따라 투자가 이루어집니다. 예시로, @michaeljoseph가 기여자에게 직접 아래의 [Cookiecutter](https://github.com/audreyr/cookiecutter) 이슈에 대한 pull request을 제출하도록 요청했습니다. -![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png) +![Cookiecutter 이슈](/assets/images/building-community/cookiecutter_submit_pr.png) * **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. -* 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. +* 만약 상당한 규모의 커뮤니티가 있다면, **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. * **Give every contributor commit access.** @felixge found that this made people [more excited to polish their patches](http://felixge.de/2013/03/11/the-pull-request-hack.html), and he even found new maintainers for projects that he hadn't worked on in awhile. -* If your project is on GitHub, **move your project from your personal account to an [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** and add at least one backup admin. Organizations make it easier to work on projects with external collaborators. +* 만약 프로젝트가 깃허브에 있는 경우, **move your project from your personal account to an [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** and add at least one backup admin. 조직에서는 외부 공동 작업자와 함께 프로젝트를 보다 쉽게 ​​작업 할 수 있습니다. -The reality is that [most projects only have](https://peerj.com/preprints/1233.pdf) one or two maintainers who do most of the work. The bigger your project, and the bigger your community, the easier it is to find help. +The reality is that [most projects only have](https://peerj.com/preprints/1233.pdf) one or two maintainers who do most of the work. 프로젝트가 커지고, 커뮤니티가 커질수록 쉽게 도움을 얻을 수 있습니다. -While you may not always find someone to answer the call, putting a signal out there increases the chances that other people will pitch in. And the earlier you start, the sooner people can help. +전화를 받는 사람을 항상 찾지는 못하더라도, 신호를 내보내는 것은 다른 사람들이 들어올 확률을 높입니다. 그리고 일찍 시작할수록 더 빨리 사람들이 도울 수 있습니다. ## 충돌 해결하기 -In the early stages of your project, making major decisions is easy. When you want to do something, you just do it. +프로젝트의 초기 단계에서, 중요한 결정을 내리는 것은 쉽습니다. 당신이 무언가를 하고 싶을 때, 그것을 합니다. -As your project becomes more popular, more people will take interest in the decisions you make. Even if you don't have a big community of contributors, if your project has a lot of users, you'll find people weighing in on decisions or raising issues of their own. +프로젝트가 인기화되면서, 더 많은 사람들이 의사 결정에 관심을 가질 것입니다. 기여자가 큰 커뮤니티에 없더라도, 프로젝트에 많은 사용자가 있는 경우 의사 결정에 중점을 두거나 자신의 문제를 제기하는 사람들을 찾을 수 있습니다. -For the most part, if you've cultivated a friendly, respectful community and documented your processes openly, your community should be able to find resolution. But sometimes you run into an issue that's a bit harder to address. +대부분, 친근하고 정중한 공동체를 육성하고, 공개적으로 프로세스를 문서화 한 경우, 커뮤니티는 해결책을 찾아야합니다. 그러나 때로는 문제를 해결하기가 더 어려워집니다. ### 친절에 대한 바 설정 -When your community is grappling with a difficult issue, tempers may rise. People may become angry or frustrated and take it out on one another, or on you. +귀하의 지역 사회가 어려운 이슈로 어려움을 겪을 때, 기분이 좋아질 수 있습니다. 사람들은 화가 나거나 좌절감을 느껴 다른 사람이나 당신이 다른 사람에게 가져갈 수 있습니다. Your job as a maintainer is to keep these situations from escalating. Even if you have a strong opinion on the topic, try to take the position of a moderator or facilitator, rather than jumping into the fight and pushing your views. If someone is being unkind or monopolizing the conversation, [act immediately](../building-community/#dont-tolerate-bad-actors) to keep discussions civil and productive. @@ -202,13 +203,13 @@ Your job as a maintainer is to keep these situations from escalating. Even if yo avatar As a project maintainer, it's extremely important to be respectful to your contributors. They often take what you say very personally.

-— @kennethreitz, ["Be Cordial or Be on Your Way"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way) +— @kennethreitz, ["정성을 들이거나 당신의 길로 가기"](https://www.kennethreitz.org/essays/be-cordial-or-be-on-your-way)

-Other people are looking to you for guidance. Set a good example. You can still express disappointment, unhappiness, or concern, but do so calmly. +다른 사람들은 당신에게 인도를 구합니다. 좋은 모범을 보입니다. 여전히 실망, 불행 또는 염려를 표현할 수 있지만 침착하게 행동하십시오. -Keeping your cool isn't easy, but demonstrating leadership improves the health of your community. The internet thanks you. +시원하게 유지하는 것은 쉽지 않지만, 리더십을 입증하면 커뮤니티의 건강이 향상됩니다. 인터넷에게 감사합니다. ### README를 헌법으로 다루기 @@ -228,52 +229,52 @@ Under a consensus seeking process, community members discuss major concerns unti avatar Part of the reason why a voting system doesn't exist for Atom Issues is because the Atom team isn't going to follow a voting system in all cases. Sometimes we have to choose what we feel is right even if it is unpopular. (...) What I can offer and pledge to do...is that it is my job to listen to the community.

-— @lee-dohm on [Atom's decisionmaking process](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2) +— @lee-dohm on [Atom의 의사 결정 과정](https://discuss.atom.io/t/prioritize-issues-feature-requests-based-on-voting-system/27642/2)

-Even if you don't actually adopt a consensus seeking process, as a project maintainer, it's important that people know you are listening. Making other people feel heard, and committing to resolving their concerns, goes a long way to diffuse sensitive situations. Then, follow up on your words with actions. +실제로 프로젝트 메인테이너로서, 합의 과정을 추구하지 않더라도 사람들이 듣고 있다는 사실을 아는 것이 중요합니다. 다른 사람들이 느끼는 것을 느끼게하고, 자신의 우려를 해결하기 위해 노력하는 것은 민감한 상황을 확산시키는 데 많은 도움이됩니다. 그런 다음, 당신의 말을 행동으로 후속 조치하십시오. -Don't rush into a decision for the sake of having a resolution. Make sure that everybody feels heard and that all information has been made public before moving toward a resolution. +결단을 내리기 위해 서두르지 마십시오. 모든 사람이 의견을 듣고 모든 정보가 공개되기 전에 공개되도록 해야합니다. ### 대화는 행동에 초점을 맞추기 -Discussion is important, but there is a difference between productive and unproductive conversations. +토론은 중요하지만, 생산적 대화와 비생산적 대화의 차이점이 있습니다. -Encourage discussion so long as it is actively moving towards resolution. If it's clear that conversation is languishing or going off-topic, jabs are getting personal, or people are quibbling about minor details, it's time to shut it down. +그것이 적극적으로 결의안을 향해 움직이는 한 토론을 장려하십시오. 대화가 심해지거나 화제가되는 것이 확실하다면, 잽이 개인적으로 달라 지거나, 사람들이 사소한 세부 사항에 대해 애매한 말을 하고 있습니다. -Allowing these conversations to continue is not only bad for the issue at hand, but bad for the health of your community. It sends a message that these types of conversations are permitted or even encouraged, and it can discourage people from raising or resolving future issues. +이러한 대화를 계속하도록 허용하는 것은 당면 문제에 좋지 않을뿐 아니라 커뮤니티의 건강에 좋지 않습니다. 이러한 유형의 대화가 허용되거나 심지어 권장된다는 메시지를 보내고, 사람들이 향후 문제를 제기하거나 해결하지 못하도록 막을 수 있습니다. -With every point made by you or by others, ask yourself, _"How does this bring us closer to a resolution?"_ +당신이나 다른 사람들이 만든 모든 요점으로, 자신에게 _"이것이 우리를 어떻게 결의안에 더 가까이 가게 할 수 있습니까?"_라고 물어봅니다. -If the conversation is starting to unravel, ask the group, _"Which steps should we take next?"_ to refocus the conversation. +대화가 풀리기 시작하면, 대화에 재집중하고자 _"다음 단계는 무엇입니까?"_라고 그룹에 요청하십시오. -If a conversation clearly isn't going anywhere, there are no clear actions to be taken, or the appropriate action has already been taken, close the issue and explain why you closed it. +대화가 명확하게 어디로도 가지 않는 경우, 명확한 조치가 취해지지 않았거나 적절한 조치가 이미 취해져서, 문제를 종결하며 이유를 설명합니다. ### 현명하게 전투를 선택하기 -Context is important. Consider who is involved in the discussion and how they represent the rest of the community. +상황이 중요합니다. 토론에 참여한 사람과 그들이 커뮤니티의 나머지 부분을 대표하는 방법을 고려하십시오. -Is everybody in the community upset about, or even engaged with, this issue? Or is a lone troublemaker? Don't forget to consider your silent community members, not just the active voices. +커뮤니티의 모든 사람들이 이 문제에 대해 화가 나거나, 심지어 이 이슈에 관여 했습니까? 또는 트러블메이커입니까? 적극적인 목소리가 아닌 조용한 커뮤니티 회원을 고려하는 것을 잊지 마십시오. -If the issue does not represent the broader needs of your community, you may just need to acknowledge the concerns of a few people. If this is a recurring issue without a clear resolution, point them to previous discussions on the topic and close the thread. +이 문제가 커뮤니티의 광범위한 요구를 반영하지 않는다면, 소수의 사람들의 우려를 인정할 필요가 있습니다. 명확한 해결 방법이 없는 반복되는 문제인 경우, 주제에 대한 이전 토론을 지정하고 스레드를 닫습니다. ### 커뮤니티 동점자 식별하기 -With a good attitude and clear communication, most difficult situations are resolvable. However, even in a productive conversation, there can simply be a difference in opinion on how to proceed. In these cases, identify an individual or group of people that can serve as a tiebreaker. +좋은 태도와 명확한 의사 전달을 통해, 가장 어려운 상황을 해결할 수 있습니다. 그러나 생산적인 대화에서 조차, 진행 방법에 대한 견해 차이가 있을 수 있습니다. 이러한 경우에는, 동점자 역할을 할 수 있는 개인 또는 그룹을 식별하십시오. -A tiebreaker could be the primary maintainer of the project, or it could be a small group of people who make a decision based on voting. Ideally, you've identified a tiebreaker and the associated process in a GOVERNANCE file before you ever have to use it. +tiebreaker는 프로젝트의 주요 관리자가 될 수도 있고, 투표를 기반으로 결정을 내릴 수 있는 소규모 그룹 일 수도 있습니다. 이상적으로, 당신은 tiebreaker와 관련 프로세스를 GOVERNANCE 파일에서 식별하여 사용해야합니다. -Your tiebreaker should be a last resort. Divisive issues are an opportunity for your community to grow and learn. Embrace these opportunities and use a collaborative process to move to a resolution wherever possible. +당신의 tiebreaker는 최후의 수단이어야합니다. 분열적인 이슈는 커뮤니티가 성장하고 배울 수있는 기회입니다. 이러한 기회를 포용하고 협업 프로세스를 사용하여 가능하면 해결 방법으로 이동하십시오. ## 커뮤니티는 오픈소스의 ❤️ 입니다 -Healthy, thriving communities fuel the thousands of hours poured into open source every week. Many contributors point to other people as the reason for working - or not working - on open source. By learning how to tap into that power constructively, you'll help someone out there have an unforgettable open source experience. +건강하고, 번영하는 커뮤니티는 매주 수천 시간을 오픈소스에 쏟아 붓고 있습니다. 많은 기여자가 오픈소스에서 일하는 이유 - 또는 일하지 않는 이유 - 를 다른 사람들에게 지적합니다. 그 힘을 건설적인 방법으로 활용하는 방법을 배우면, 잊지 못할 오픈소스 경험이 있는 누군가를 도울 수 있습니다. From b225ac548b36aa3015347b352271bc5649ffdae2 Mon Sep 17 00:00:00 2001 From: minwook Date: Thu, 19 Oct 2017 11:23:16 +0900 Subject: [PATCH 24/87] translated this file --- _articles/ko-KR/building-community.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/_articles/ko-KR/building-community.md b/_articles/ko-KR/building-community.md index bd97f8bbc39..2dcc3a9f4b0 100644 --- a/_articles/ko-KR/building-community.md +++ b/_articles/ko-KR/building-community.md @@ -167,13 +167,13 @@ CONTRIBUTING 파일에서 새 참여자에게 시작 방법을 명시하십시 * **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. -* 만약 상당한 규모의 커뮤니티가 있다면, **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. +* 만약 상당한 규모의 커뮤니티가 있다면, 기여자들에게 감사하는 **뉴스 레터를 보내거나 블로그 포스트를 작성하십시오**. Rust의 [This Week in Rust](https://this-week-in-rust.org/)와 Hoodie의 [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html)는 두개의 좋은 예시입니다. -* **Give every contributor commit access.** @felixge found that this made people [more excited to polish their patches](http://felixge.de/2013/03/11/the-pull-request-hack.html), and he even found new maintainers for projects that he hadn't worked on in awhile. +* **모든 참여자에게 커밋 접근 권한을 부여하십시오.** @felixge는 이것이 사람들로 하여금 [패치를 작성하는 것에 더 흥분하도록](http://felixge.de/2013/03/11/the-pull-request-hack.html) 만들었고, 잠시동안 일하지 않은 프로젝트에 대한 새로운 메인테이너를 발견했습니다. -* 만약 프로젝트가 깃허브에 있는 경우, **move your project from your personal account to an [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** and add at least one backup admin. 조직에서는 외부 공동 작업자와 함께 프로젝트를 보다 쉽게 ​​작업 할 수 있습니다. +* 만약 프로젝트가 깃허브에 있는 경우, .**프로젝트를 개인 계정에서 [조직](https://help.github.com/articles/creating-a-new-organization-account/)으로 옮기고** 하나 이상의 백업 관리자를 추가하십시오. 조직에서는 외부 공동 작업자와 함께 프로젝트를 보다 쉽게 ​​작업 할 수 있습니다. -The reality is that [most projects only have](https://peerj.com/preprints/1233.pdf) one or two maintainers who do most of the work. 프로젝트가 커지고, 커뮤니티가 커질수록 쉽게 도움을 얻을 수 있습니다. +실제로 [대부분의 프로젝트](https://peerj.com/preprints/1233.pdf)는 대부분의 작업을 수행하는 1 ~ 2 명의 메인테이너만 있습니다. 프로젝트가 커지고, 커뮤니티가 커질수록 쉽게 도움을 얻을 수 있습니다. 전화를 받는 사람을 항상 찾지는 못하더라도, 신호를 내보내는 것은 다른 사람들이 들어올 확률을 높입니다. 그리고 일찍 시작할수록 더 빨리 사람들이 도울 수 있습니다. @@ -197,7 +197,7 @@ The reality is that [most projects only have](https://peerj.com/preprints/1233.p 귀하의 지역 사회가 어려운 이슈로 어려움을 겪을 때, 기분이 좋아질 수 있습니다. 사람들은 화가 나거나 좌절감을 느껴 다른 사람이나 당신이 다른 사람에게 가져갈 수 있습니다. -Your job as a maintainer is to keep these situations from escalating. Even if you have a strong opinion on the topic, try to take the position of a moderator or facilitator, rather than jumping into the fight and pushing your views. If someone is being unkind or monopolizing the conversation, [act immediately](../building-community/#dont-tolerate-bad-actors) to keep discussions civil and productive. +메인테이너로서의 당신의 임무는 이러한 상황이 악화되는 것을 막는 것입니다. 주제에 대해 강한 의견을 갖고 있다고해도, 시합에 뛰어 들고 의견을 피하는 대신 메인테이너 또는 진행자의 입장을 취하십시오. 누군가가 불친절하거나 대화를 독점한다면, 토론을 시민적이고 생산적으로 유지하기 위해 [즉시 행동하십시오](../ building-community / # dont-tolerate-bad-actors). @@ -104,7 +104,7 @@ If you're [new to public speaking](http://speaking.io/), start by finding a loca avatar I was pretty nervous about going to PyCon. I was giving a talk, I was only going to know a couple of people there, I was going for an entire week. (...) I shouldn't have worried, though. PyCon was phenomenally awesome! (...) Everyone was incredibly friendly and outgoing, so much that I rarely found time not to talk to people!

-— @jhamrick, ["How I learned to Stop Worrying and Love PyCon"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/) +— @jhamrick, ["나는 PyCon을 걱정하지않고 좋아하는 방법을 어떻게 배웠나"](http://www.jesshamrick.com/2014/04/18/how-i-learned-to-stop-worrying-and-love-pycon/)

@@ -116,7 +116,7 @@ As you write your talk, focus on what your audience will find interesting and ge avatar When you start writing your talk, no matter what your topic is, it can help if you see your talk as a story that you tell people.

-— Lena Reinhard, ["How to Prepare and Write a Tech Conference Talk"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/) +— Lena Reinhard, ["Tech Conference Talk를 준비하고 작성하는 방법"](http://wunder.schoenaberselten.com/2016/02/16/how-to-prepare-and-write-a-tech-conference-talk/)

@@ -128,7 +128,7 @@ Look for conferences that are specific to your language or ecosystem. Before you avatar I wrote very nicely to the JSConf people and begged them to give me a slot where I could present it at JSConf EU. (...) I was extremely scared, presenting this thing that I had been working on for six months. (...) The whole time I was just thinking, oh my God. What am I doing here?

-— @ry, ["History of Node.js" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s) +— @ry, ["Node.js의 기록" (video)](https://www.youtube.com/watch?v=SAc0vQCC6UQ&t=24m57s)

@@ -144,7 +144,7 @@ Sometimes, these relationships can even lead to official partnerships with the w avatar The only reason urllib3 is the most popular third-party Python library today is because it's part of requests.

-— @shazow, ["How to make your open source project thrive"](https://text.sourcegraph.com/how-to-make-your-open-source-project-thrive-with-andrey-petrov-6463b935c540#.mk31f8fgf) +— @shazow, ["오픈소스 프로젝트를 번성하게 만드는 방법"](https://text.sourcegraph.com/how-to-make-your-open-source-project-thrive-with-andrey-petrov-6463b935c540#.mk31f8fgf)

@@ -156,10 +156,10 @@ There is no overnight solution to building an audience. Gaining the trust and re avatar PhantomJS was released for the first time in the beginning of 2011. (...) I spread the word in the usual ways: I tweeted about it, I wrote blog posts on things you could do with it, I mentioned it during various discussions in meetups. When it became more well known in 2014, I started giving presentations about it.

-— @ariya, ["Maintainer Stories"](https://github.com/open-source/stories/ariya) +— @ariya, ["메인테이너 이야기"](https://github.com/open-source/stories/ariya)

## 견딥시다! -Sometimes, it takes a long time before people notice your open source project. That's okay! Some of the most popular projects today took years to reach high levels of activity. Focus on building relationships instead of a magic bullet. Be patient, and keep sharing your work with those who appreciate it. +때로는, 사람들이 오픈소스 프로젝트에 주목하기까지는 시간이 오래 걸립니다. 괜찮습니다! 오늘날 가장 인기있는 프로젝트 중 일부는 높은 수준의 활동에 도달하기까지 수년이 걸렸습니다. 마술 총알 대신 관계를 구축하는 데에 집중하십시오. 인내심을 갖고, 감사해하는 사람들과 일하는 결과물을 계속 공유하십시오. From 188edbedd4b2adbebe8e540ddb85613ed22743cd Mon Sep 17 00:00:00 2001 From: minwook Date: Sun, 22 Oct 2017 17:51:48 +0900 Subject: [PATCH 32/87] It was half --- _articles/ko-KR/finding-users.md | 44 ++++++++++++++++---------------- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/_articles/ko-KR/finding-users.md b/_articles/ko-KR/finding-users.md index e73d8cb97b4..c405feccfa7 100644 --- a/_articles/ko-KR/finding-users.md +++ b/_articles/ko-KR/finding-users.md @@ -23,17 +23,17 @@ related: ## 매시지 이해하기 -Before you start the actual work of promoting your project, you should be able to explain what it does, and why it matters. +프로젝트를 홍보하기 위한 실제 작업을 시작하기 전에, 프로젝트의 기능과 중요한 이유를 설명 할 수 있어야합니다. -What makes your project different or interesting? Why did you create it? Answering these questions for yourself will make it easier to convince others. +무엇이 당신의 프로젝트를 다양하고 흥미롭게 만드나요? 왜 그것을 만들었습니까? 이러한 질문을 스스로 해결하면 다른 사람들을 설득하기가 더 쉬울 것입니다. -Remember that people get involved as users, and eventually contributors, because it solves a problem for them. As you think about your project's message and value, try to view it through the lens of what _they_ might want. +사람들이 문제를 해결하기 때문에, 사용자들은 궁극적으로는 참여자로서만 참여한다는 것을 기억하십시오. 프로젝트의 메시지와 가치에 대해 생각할 때 _그들이_ 무엇을 원하는 것인지에 대한 렌즈를 통해 보도록 하십시오. -For example, @robb uses code examples to clearly communicate why his project, [Cartography](https://github.com/robb/Cartography), is useful: +예시로, @robb는 코드 예제를 사용하여 자신의 프로젝트, [Cartography](https://github.com/robb/Cartography),를 효율적으로 했습니다: ![Cartography README](/assets/images/finding-users/cartography.jpg) -For a deeper dive into messaging, check out Mozilla's ["Personas and Pathways"](http://mozillascience.github.io/working-open-workshop/personas_pathways/) exercise for developing user personas. +메시징에 대해 더 자세히 알고 싶으면, Mozilla의 ["Personas and Pathways"](http://mozillascience.github.io/working-open-workshop/personas_pathways/) 개발자용 연습 personas를 확인하십시오. ## 사람들이 프로젝트를 찾고 팔로우하도록 도와주기 @@ -44,11 +44,11 @@ For a deeper dive into messaging, check out Mozilla's ["Personas and Pathways"](

-Help people find and remember your project by pointing them to a single namespace. +사람들이 단일 네임스페이스를 가리켜 프로젝트를 찾고 기억하도록 돕습니다. -**Have a clear handle to promote your work.** A Twitter handle, GitHub URL, or IRC channel is an easy way to point people to your project. They also give your project's growing community a place to convene. +**작업을 홍보하기 위해 명확히 처리를 하기.** 트위터 핸들, GitHub URL 또는 IRC 채널을 통해 사람들을 프로젝트에 쉽게 안내 할 수 있습니다. 그들은 또한 귀하의 프로젝트가 성장하는 커뮤니티에 모일 장소를 제공합니다. -If you don't wish to set up these channels for your project yet, promote your own Twitter or GitHub handle in everything you do. For example, make sure it is included in your bio or slides if you speak at a meetup or event. That way, people know how to reach you or follow your work. +프로젝트에 이 채널을 아직 설정하고 싶지 않다면, 자신의 모든 트위터 또는 GitHub 핸들을 홍보하십시오. 예를 들어, 만남이나 행사에서 말하는 경우, 소개 또는 슬라이드에 포함되어 있는지 확인하십시오. 그런식으로 사람들은 당신에게 연락하거나 일을 수행하는 방법을 알고 있습니다. -**Consider creating a website for your project.** A website makes your project friendlier and easier to navigate, especially paired with clear documentation and tutorials. It also suggests that your project is active, which will make your audience feel more comfortable using it. Use examples to give people ideas for how to use your project. +**프로젝트를 위한 웹 사이트를 만드는 것을 고려하기.** 웹 사이트는 프로젝트를 보다 편리하고 쉽게 탐색 할 수 있게 해주며, 특히 명확한 문서 및 자습서와 함께 사용할 수 있습니다. 또한 프로젝트가 활성화되어있어 시청자가 더 편안하게 사용할 수 있습니다. 예시를 사용하여 사람들에게 프로젝트 사용 방법에 대한 아이디어를 제공하십시오. -[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-creator of Django, said that a website was _"by far the best thing we did with Django in the early days"_. +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), Django의 협력자가, 말하기를 웹사이트는 _"by far the best thing we did with Django in the early days"_이라고 했습니다. -If your project is hosted on GitHub, you can use [GitHub Pages](https://pages.github.com/) to easily make a website. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) are [a few examples](https://github.com/showcases/github-pages-examples) of excellent, comprehensive websites. +만약 당신의 프로젝트가 깃허브에 호스팅된다면, [GitHub 페이지](https://pages.github.com/)를 통해 웹사이트를 쉽게 만드는 것을 보실 수 있습니다. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/),와 [Middleman](https://middlemanapp.com/)은 포괄적인 사이트 중, 훌륭한 [예시입니다](https://github.com/showcases/github-pages-examples). ![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png) -Now that you have a message for your project, and an easy way for people to find your project, let's get out there and talk to your audience! +이제 프로젝트에 대한 메시지와 사람들이 프로젝트를 쉽게 찾을 수 있는 방법을 얻었으므로, 거기서 나와서 지지자와 대화를 나눠보십시오. ## 프로젝트의 지지자가 있는 (온라인)으로 이동하기 -Online outreach is a great way to share and spread the word quickly. Using online channels, you have the potential to reach a very wide audience. +온라인 홍보는 단어를 빠르게 공유하고 전파 할 수 있는 좋은 방법입니다. 온라인 채널을 사용하면 매우 광범위한 잠재적 지지자에게 도달 할 수 있습니다. -Take advantage of existing online communities and platforms to reach your audience. If your open source project is a software project, you can probably find your audience on [Stack Overflow](http://stackoverflow.com/), [Reddit](http://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/). Find the channels where you think people will most benefit from or be excited about your work. +기존 온라인 커뮤니티 및 플랫폼을 활용하여 잠재 고객에게 도달하십시오. 만약 오픈소스 프로젝트가 소프트웨어 프로젝트라면, 아마도 [스택 오버플로우](http://stackoverflow.com/), [레딧](http://www.reddit.com), [해커 뉴스](https://news.ycombinator.com/), 또는 [Quora](https://www.quora.com/)에서 지지자를 찾을 수 있을 것입니다. 사람들이 당신의 작품에 대해 가장 많은 이익을 보거나 즐거워한다고 생각하는 채널을 찾으십시오. -See if you can find ways to share your project in relevant ways: +관련 방법으로 프로젝트를 공유하는 방법을 찾을 수 있는지 확인하십시오: -* **Get to know relevant open source projects and communities.** Sometimes, you don't have to directly promote your project. If your project is perfect for data scientists who use Python, get to know the Python data science community. As people get to know you, natural opportunities will arise to talk about and share your work. -* **Find people experiencing the problem that your project solves.** Search through related forums for people who fall into your project's target audience. Answer their question and find a tactful way, when appropriate, to suggest your project as a solution. -* **Ask for feedback.** Introduce yourself and your work to an audience that would find it relevant and interesting. Be specific about who you think would benefit from your project. Try to finish the sentence: _"I think my project would really help X, who are trying to do Y_". Listen and respond to others' feedback, rather than simply promoting your work. +* **관련 오픈 소스 프로젝트와 커뮤니티에 대해 알아보십시오.** 때로는 프로젝트를 직접 홍보 할 필요가 없습니다. 프로젝트가 파이썬을 사용하는 데이터 과학자에게 완벽하면, 파이썬 데이터 과학 커뮤니티에 대해 알아보십시오. 사람들이 당신을 알게되면, 자연스런 기회가 생겨 대화를 나누고 작업을 공유하게됩니다. +* **프로젝트가 해결하는 문제를 겪고있는 사람들을 찾으십시오.** 프로젝트의 타겟층에 속한 사람들을 관련 포럼을 통해 검색하십시오. 그들의 질문에 답하고 적절한 방법으로 프로젝트를 솔루션으로 제안하십시오. +* **피드백 요청하기.** 관련성 높고 흥미로운 청중에게 자신과 자신의 작업을 소개하십시오. 프로젝트에서 누가 이익을 얻을지 생각하는 사람에 대해 구체적으로 설명합시다. 이렇게 문장을 끝내봅니다: _"I think my project would really help X, who are trying to do Y_".단순히 귀하의 작업을 홍보하는 것이 아니라, 다른 사람들의 의견을 경청하고 이에 응답해봅니다. -Generally speaking, focus on helping others before asking for things in return. Because it is easy for anybody to promote a project online, there will be a lot of noise. Give people context for who you are, not just what you want, to stand out from the crowd. +일반적으로 말하면, 보답하기 전에 다른 사람들을 돕는 데 집중하십시오. 누구나 온라인으로 프로젝트를 홍보하기 쉽기 때문에, 많은 소음이 발생할 것입니다. 자신이 원하는 사람이 아니라, 무리에서 눈에 띄기 위해서 자신이 누구인지를 사람들에게 알릴 수 있습니다. -If nobody pays attention or responds to your initial outreach, don't get discouraged! Most project launches are an iterative process that can take months or years. If you don't get a response the first time, try a different tactic, or look for ways to add value to others' work first. These things take time and dedication. +아무도 주의를 기울이지 않거나 초기 봉사 활동에 응답하지 않으면, 낙심하지 마십시오! 대부분의 프로젝트 시작은 수개월 또는 수년이 걸릴 수 있는 반복 프로세스입니다. 처음으로 응답을 얻지 못하면 다른 전술을 시도하거나 다른 사람들의 작품에 가치를 더하는 방법을 먼저 찾으십시오. 이러한 일에는 시간과 헌신이 필요합니다. ## 프로젝트의 지지자가 있는 (오프라인)으로 이동하기 @@ -148,9 +148,9 @@ Sometimes, these relationships can even lead to official partnerships with the w

-It's never too early, or too late, to start building your reputation. Even if you've launched your own project already, continue looking for ways to help others. +평판을 얻기 시작하는 것이 너무 빠르거나, 혹은 너무 늦지 않았습니다. 이미 자신의 프로젝트를 시작했더라도, 다른 사람들을 도울 수 있는 방법을 모색하십시오. -There is no overnight solution to building an audience. Gaining the trust and respect of others takes time, and reputation building work never ends. +지지자를 키우는 데는 밤새도 해결책이 없습니다. 다른 사람들의 신뢰와 존경심을 얻는 데는 시간이 걸리고 명성을 쌓는 작업은 끝나지 않습니다. @@ -59,13 +59,13 @@ Paid work also enables people from different walks of life to make meaningful co avatar 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, ["현금과 오픈소스"](https://medium.com/open-source-life/money-and-open-source-d44a1953749c#.ftnd5qez0)

If you're looking for financial support, there are two paths to consider. You can fund your own time as a contributor, or you can find organizational funding for the project. -## Funding your own time +## 시간 펀딩하기 Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer. @@ -75,7 +75,7 @@ It's easier to make a case for open source work if your employer actually uses t avatar Like many in open source, I was struggling with the burden of maintaining a project. When I first started doing open source, I used to just stay late to work on it or right when I got home. (...) I was able to discuss with my boss the issues I was facing and we came up with ideas on how we could incorporate open source tasks given our own use of Babel.

-— @hzoo, ["Maintainer Stories"](https://github.com/open-source/stories/hzoo) +— @hzoo, ["메인테이너 이야기"](https://github.com/open-source/stories/hzoo)

@@ -93,7 +93,7 @@ If your company goes down this route, it's important to keep the boundaries betw avatar Getting paid to work on open source is a rare and wonderful opportunity, but you should not have to give up your passion in the process. Your passion should be why companies want to pay you.

-— @jessfraz, ["Blurred Lines"](https://blog.jessfraz.com/post/blurred-lines/) +— @jessfraz, ["흐린 선"](https://blog.jessfraz.com/post/blurred-lines/)

@@ -109,7 +109,7 @@ Finally, depending on your personal circumstances, you can try raising money ind * @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](http://redux.js.org/) * @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) -## Finding funding for your project +## 프로젝트 펀딩 찾기 Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work. @@ -126,7 +126,7 @@ A few examples of sponsored projects include: * **[Vue](https://github.com/vuejs/vue)** is [funded through Patreon](https://github.com/open-source/stories/yyx990803) * **[Ruby Together](https://rubytogether.org/),** a nonprofit organization that pays for work on [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems), and other Ruby infrastructure projects -### Create a revenue stream +### 수입원 만들기 Depending on your project, you may be able to charge for commercial support, hosted options, or additional features. A few examples include: @@ -136,7 +136,7 @@ Depending on your project, you may be able to charge for commercial support, hos Some popular projects, like [npm](https://github.com/npm/npm) and [Docker](https://github.com/docker/docker), even raise venture capital to support their business growth. -### Apply for grant funding +### 보조금 신청하기 Some software foundations and companies offer grants for open source work. Sometimes, grants can be paid out to individuals without setting up a legal entity for the project. @@ -147,29 +147,29 @@ Some software foundations and companies offer grants for open source work. Somet For more detailed options and case studies, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) to getting paid for open source work. Different types of funding require different skills, so consider your strengths to figure out which option works best for you. -## Building a case for financial support +## 재정 지원 사례 구축하기 Whether your project is a new idea, or has been around for years, you should expect to put significant thought into identifying your target funder and making a compelling case. Whether you're looking to pay for your own time, or fundraise for a project, you should be able to answer the following questions. -### Impact +### 임펙트 Why is this project useful? Why do your users, or potential users, like it so much? Where will it be in five years? -### Traction +### 끌어주기 -Try to collect evidence that your project matters, whether it's metrics, anecdotes, or testimonials. Are there any companies or noteworthy people using your project right now? If not, has a prominent person endorsed it? +메트릭, 일화 또는 고객의 견해와 상관없이 프로젝트가 중요하다는 증거를 수집하십시오. 현재 귀사의 프로젝트를 사용하고 있는 회사나, 주목할만한 사람들이 있습니까? 그렇지 않다면 저명한 사람이 그것을 지지합니까? -### Value to funder +### 자금 제공자에 주는 가치 Funders, whether your employer or a grantmaking foundation, are frequently approached with opportunities. Why should they support your project over any other opportunity? How do they personally benefit? -### Use of funds +### 펀드 사용 What, exactly, will you accomplish with the proposed funding? Focus on project milestones or outcomes rather than paying a salary. -### How you'll receive the funds +### 펀드로 송금하기 Does the funder have any requirements around disbursal? For example, you may need to be a nonprofit or have a nonprofit fiscal sponsor. Or perhaps the funds must be given to an individual contractor rather than an organization. These requirements vary between funders, so be sure to do your research beforehand. @@ -177,12 +177,11 @@ Does the funder have any requirements around disbursal? For example, you may nee avatar For years, we've been the leading resource of website friendly icons, with a community of over 20 million people and been featured on over 70 million websites, including Whitehouse.gov. (...) Version 4 was three years ago. Web tech's changed a lot since then, and frankly, Font Awesome's gotten a bit stale. (...) That's why we're introducing Font Awesome 5. We're modernizing and rewriting the CSS and redesigning every icon from top to bottom. We're talking better design, better consistency, and better readability.

-— @davegandy, [Font Awesome Kickstarter video](https://www.kickstarter.com/projects/232193852/font-awesome-5) +— @davegandy, [Font Awesome 킥스타터 영상](https://www.kickstarter.com/projects/232193852/font-awesome-5)

-## 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. +## 실험적이고 포기하지 말기 +오픈 소스 프로젝트, 비영리 단체, 소프트웨어 스타트업 등 많은 돈을 모으는 것은 쉽지 않습니다. 대부분의 경우 창의력을 발휘해야합니다. 어떻게 돈을 받고, 연구를 하고, 재밌는 사람의 신발에 몸을 두는지를 확인하면 자금 지원에 대한 설득력있는 사례를 구축하는 데 도움이됩니다. > From 4d5655ef9057dd30191f0aa0b40f9f9f5d98d55d Mon Sep 17 00:00:00 2001 From: minwook Date: Sun, 29 Oct 2017 21:13:05 +0900 Subject: [PATCH 36/87] Translated main text --- _articles/ko-KR/how-to-contribute.md | 4 ++-- _articles/ko-KR/leadership-and-governance.md | 4 ++-- _articles/ko-KR/legal.md | 4 ++-- _articles/ko-KR/metrics.md | 4 ++-- _articles/ko-KR/starting-a-project.md | 4 ++-- 5 files changed, 10 insertions(+), 10 deletions(-) diff --git a/_articles/ko-KR/how-to-contribute.md b/_articles/ko-KR/how-to-contribute.md index 2fe45edc25d..21fb6712a11 100644 --- a/_articles/ko-KR/how-to-contribute.md +++ b/_articles/ko-KR/how-to-contribute.md @@ -1,7 +1,7 @@ --- locale: ko-KR -title: How to Contribute to Open Source -description: Want to contribute to open source? A guide to making open source contributions, for first-timers and for veterans. +title: 오픈소스에 기여하는 방법 +description: 오픈소스에 기여하고 싶습니까? 초보자와 숙련자를 위한 오픈소스 기여에 대한 가이드입니다. class: contribute toc: why-contribute-to-open-source: "Why contribute to open source?" diff --git a/_articles/ko-KR/leadership-and-governance.md b/_articles/ko-KR/leadership-and-governance.md index 3311095f1a1..9197e9a0563 100644 --- a/_articles/ko-KR/leadership-and-governance.md +++ b/_articles/ko-KR/leadership-and-governance.md @@ -1,7 +1,7 @@ --- locale: ko-KR -title: Leadership and Governance -description: Growing open source projects can benefit from formal rules for making decisions. +title: 리더십과 정치 +description: 오픈소스 프로젝트가 성장하면서 공식적인 의사 결정 규칙의 혜택을 볼 수 있습니다. class: leadership toc: what-are-examples-of-formal-roles-used-in-open-source-projects: "What are examples of formal roles used in open source projects?" diff --git a/_articles/ko-KR/legal.md b/_articles/ko-KR/legal.md index 9b893ca7a05..e2ac3a32126 100644 --- a/_articles/ko-KR/legal.md +++ b/_articles/ko-KR/legal.md @@ -1,7 +1,7 @@ --- locale: ko-KR -title: The Legal Side of Open Source -description: Everything you've ever wondered about the legal side of open source, and a few things you didn't. +title: 오픈소스의 법적 측면 +description: 오픈소스의 법적 측면과 당신이 하지 않은 몇가지 사항에 대해 궁금해하는 모든 것. class: legal toc: why-do-people-care-so-much-about-the-legal-side-of-open-source: "Why do people care so much about the legal side of open source?" diff --git a/_articles/ko-KR/metrics.md b/_articles/ko-KR/metrics.md index 9bc41d50290..49d8e3be4ef 100644 --- a/_articles/ko-KR/metrics.md +++ b/_articles/ko-KR/metrics.md @@ -1,7 +1,7 @@ --- locale: ko-KR -title: Open Source Metrics -description: Make informed decisions to help your open source project thrive by measuring and tracking its success. +title: 오픈소스 측정항목 +description: 성공을 측정하고 추적함으로써 오픈소스 프로젝트가 성공할 수 있도록 정보에 입각한 의사 결정을하십시오. class: metrics toc: why-measure-anything: "Why measure anything?" diff --git a/_articles/ko-KR/starting-a-project.md b/_articles/ko-KR/starting-a-project.md index 0d5c8671653..08b9ebc1ff7 100644 --- a/_articles/ko-KR/starting-a-project.md +++ b/_articles/ko-KR/starting-a-project.md @@ -1,7 +1,7 @@ --- locale: ko-KR -title: Starting an Open Source Project -description: Learn more about the world of open source and get ready to launch your own project. +title: 오픈소스 프로젝트 시작하기 +description: 오픈소스의 세계에 대해 자세히 알아보고 자신만의 프로젝트를 시작할 준비를 하십시오. class: beginners toc: the-what-and-why-of-open-source: "The what and why of open source" From a55f754903a5959342424201bf7139f209f491b0 Mon Sep 17 00:00:00 2001 From: minwook Date: Sun, 29 Oct 2017 21:14:55 +0900 Subject: [PATCH 37/87] fix typo --- _articles/ko-KR/legal.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_articles/ko-KR/legal.md b/_articles/ko-KR/legal.md index e2ac3a32126..5bcf669a480 100644 --- a/_articles/ko-KR/legal.md +++ b/_articles/ko-KR/legal.md @@ -1,7 +1,7 @@ --- locale: ko-KR title: 오픈소스의 법적 측면 -description: 오픈소스의 법적 측면과 당신이 하지 않은 몇가지 사항에 대해 궁금해하는 모든 것. +description: 오픈소스의 법적 측면과 당신이 하지 않은 몇가지 사항에 대해 궁금해하는 모든 것입니다. class: legal toc: why-do-people-care-so-much-about-the-legal-side-of-open-source: "Why do people care so much about the legal side of open source?" From 99db510c41ad47dd119f66ae5fb0bed7d4149c39 Mon Sep 17 00:00:00 2001 From: minwook Date: Mon, 30 Oct 2017 12:30:05 +0900 Subject: [PATCH 38/87] update translate and fix typo --- _articles/ko-KR/best-practices.md | 12 +++++----- _articles/ko-KR/building-community.md | 2 +- _articles/ko-KR/code-of-conduct.md | 2 +- _articles/ko-KR/finding-users.md | 2 +- _articles/ko-KR/getting-paid.md | 32 +++++++++++++-------------- 5 files changed, 25 insertions(+), 25 deletions(-) diff --git a/_articles/ko-KR/best-practices.md b/_articles/ko-KR/best-practices.md index ce637fc607b..7ae3b0852e4 100644 --- a/_articles/ko-KR/best-practices.md +++ b/_articles/ko-KR/best-practices.md @@ -1,7 +1,7 @@ --- locale: ko-KR title: 메인테이너를 위한 모범 사례 -description: 문서화 과정에서 커뮤니티 활용에 이르기까지 오픈 소스 메인테이너로서 여러분의 삶을 편하게 만들어줍니다. +description: 문서화 과정에서 커뮤니티 활용에 이르기까지 오픈소스 메인테이너로서 여러분의 삶을 편하게 만들어줍니다. class: best-practices toc: what-does-it-mean-to-be-a-maintainer: "메인테이너가 된다는 것은 무엇을 의미하나요?" @@ -19,7 +19,7 @@ related: ## 메인테이너가 된다는 것은 무엇을 의미하나요? -많은 사람들이 사용하는 오픈 소스 프로젝트를 유지한다면, 적은 양으로 코딩하고 더 많은 이슈에 대응할 수 있습니다. +많은 사람들이 사용하는 오픈소스 프로젝트를 유지한다면, 적은 양으로 코딩하고 더 많은 이슈에 대응할 수 있습니다. 프로젝트 초기 단계에서 새로운 아이디어를 실험하고 원하는 것을 기반으로 의사 결정을 내리고 있습니다. 프로젝트의 인기가 높아짐에 따라 사용자와 기여자들과 더 잘 일할 수 있습니다. @@ -47,7 +47,7 @@ related: avatar I fumbled it. I didn't put in the effort to come up with a complete solution. Instead of an half-assed solution, I wish I had said "I don't have time for this right now, but I'll add it to the long term nice-to-have list."

-— @lord, ["새로운 오픈 소스 메인테이너를 위한 팁"](https://lord.io/blog/2014/oss-tips/) +— @lord, ["새로운 오픈소스 메인테이너를 위한 팁"](https://lord.io/blog/2014/oss-tips/)

@@ -181,7 +181,7 @@ related: avatar I’d been saying, “Yeah, anyone can be involved, you don’t have to have a lot of coding expertise [...].” We had people sign up to come [to an event] and that’s when I was really wondering: is this true, what I’ve been saying? There are gonna be 40 people who show up, and it’s not like I can sit with each of them...But people came together, and it just sort of worked. As soon as one person got it, they could teach their neighbor.

-— @lmccart, [""오픈 소스"란 무엇을 의미합니까? p5.js Edition"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39#.chnjlag7p) +— @lmccart, [""오픈소스"란 무엇을 의미합니까? p5.js Edition"](https://medium.com/@kenjagan/what-does-open-source-even-mean-p5-js-edition-98c02d354b39#.chnjlag7p)

@@ -197,7 +197,7 @@ related: 잠재적 기여자가 프로젝트에서 해야 할 일에 대해 다른 견해를 가지고 있다면, 그들을 자신의 포크로 작업하도록 부드럽게 격려하고 싶을 수 있습니다. -프로젝트 포킹은 나쁜 일이 아닙니다. 프로젝트를 복사하고 수정할 수 있다는 것이 오픈 소스에 관한 가장 좋은 것 중 하나입니다. 커뮤니티 회원들이 자신의 포크로 작업하도록 권장하면 프로젝트 비전과 상충하지 않고, 필요한 창의적인 판로를 제공 할 수 있습니다. +프로젝트 포킹은 나쁜 일이 아닙니다. 프로젝트를 복사하고 수정할 수 있다는 것이 오픈소스에 관한 가장 좋은 것 중 하나입니다. 커뮤니티 회원들이 자신의 포크로 작업하도록 권장하면 프로젝트 비전과 상충하지 않고, 필요한 창의적인 판로를 제공 할 수 있습니다. -오픈 소스 제공자의 대다수는 "임시 기여자"입니다. 때때로 프로젝트에만 기여하는 사람들입니다. 캐주얼 기여자는 프로젝트 진행 속도를 최대로 끌어 올릴 시간이 없을 수도 있기 때문에, 당신의 일은 그들이 기여하기 쉽게 만드는 것입니다. +오픈소스 제공자의 대다수는 "임시 기여자"입니다. 때때로 프로젝트에만 기여하는 사람들입니다. 캐주얼 기여자는 프로젝트 진행 속도를 최대로 끌어 올릴 시간이 없을 수도 있기 때문에, 당신의 일은 그들이 기여하기 쉽게 만드는 것입니다. 다른 참여자를 격려하는 것은 자신에게도 투자입니다. 가장 열렬한 팬에게 흥분을 줄 수있는 힘을 실어 줄 때, 모든 것을 스스로 할 수있는 부담이 줄어 듭니다. diff --git a/_articles/ko-KR/code-of-conduct.md b/_articles/ko-KR/code-of-conduct.md index 11daf81aa6b..27fe9d76898 100644 --- a/_articles/ko-KR/code-of-conduct.md +++ b/_articles/ko-KR/code-of-conduct.md @@ -34,7 +34,7 @@ related: * 누군가가 행동강령을 위반하면 어떻게되는가 * 누군가가 위반 사례를 신고 할 수 있는 방법 -가능한 모든 곳에서 이전 기술을 사용하십시오. [기여자 규약](http://contributor-covenant.org/)은 Kubernetes, Rails 및 Swift를 포함하여 40,000 개 이상의 오픈 소스 프로젝트에서 사용되는 행동강령입니다. +가능한 모든 곳에서 이전 기술을 사용하십시오. [기여자 규약](http://contributor-covenant.org/)은 Kubernetes, Rails 및 Swift를 포함하여 40,000 개 이상의 오픈소스 프로젝트에서 사용되는 행동강령입니다. [Django 행동강령](https://www.djangoproject.com/conduct/)과 [Citizen 행동강령](http://citizencodeofconduct.org/)은 두가지 훌륭한 행동강령입니다. diff --git a/_articles/ko-KR/finding-users.md b/_articles/ko-KR/finding-users.md index 4cf897ae26f..8de3824963f 100644 --- a/_articles/ko-KR/finding-users.md +++ b/_articles/ko-KR/finding-users.md @@ -84,7 +84,7 @@ related: 관련 방법으로 프로젝트를 공유하는 방법을 찾을 수 있는지 확인하십시오: -* **관련 오픈 소스 프로젝트와 커뮤니티에 대해 알아보십시오.** 때로는 프로젝트를 직접 홍보 할 필요가 없습니다. 프로젝트가 파이썬을 사용하는 데이터 과학자에게 완벽하면, 파이썬 데이터 과학 커뮤니티에 대해 알아보십시오. 사람들이 당신을 알게되면, 자연스런 기회가 생겨 대화를 나누고 작업을 공유하게됩니다. +* **관련 오픈소스 프로젝트와 커뮤니티에 대해 알아보십시오.** 때로는 프로젝트를 직접 홍보 할 필요가 없습니다. 프로젝트가 파이썬을 사용하는 데이터 과학자에게 완벽하면, 파이썬 데이터 과학 커뮤니티에 대해 알아보십시오. 사람들이 당신을 알게되면, 자연스런 기회가 생겨 대화를 나누고 작업을 공유하게됩니다. * **프로젝트가 해결하는 문제를 겪고있는 사람들을 찾으십시오.** 프로젝트의 타겟층에 속한 사람들을 관련 포럼을 통해 검색하십시오. 그들의 질문에 답하고 적절한 방법으로 프로젝트를 솔루션으로 제안하십시오. * **피드백 요청하기.** 관련성 높고 흥미로운 청중에게 자신과 자신의 작업을 소개하십시오. 프로젝트에서 누가 이익을 얻을지 생각하는 사람에 대해 구체적으로 설명합시다. 이렇게 문장을 끝내봅니다: _"I think my project would really help X, who are trying to do Y_".단순히 귀하의 작업을 홍보하는 것이 아니라, 다른 사람들의 의견을 경청하고 이에 응답해봅니다. diff --git a/_articles/ko-KR/getting-paid.md b/_articles/ko-KR/getting-paid.md index 1aba80ed0cd..0094699264e 100644 --- a/_articles/ko-KR/getting-paid.md +++ b/_articles/ko-KR/getting-paid.md @@ -1,7 +1,7 @@ --- locale: ko-KR -title: 오픈 소스 작업에 대한 비용 지불하기 -description: 시간이나 프로젝트에 대한 재정적 지원을 받음으로써 오픈 소스에서의 작업을 지속합니다. +title: 오픈소스 작업에 대한 비용 지불하기 +description: 시간이나 프로젝트에 대한 재정적 지원을 받음으로써 오픈소스에서의 작업을 지속합니다. class: getting-paid toc: why-some-people-seek-financial-support: "어떤 사람들은 왜 재정 지원을 요청 하는가" @@ -17,7 +17,7 @@ related: ## 어떤 사람들은 왜 재정 지원을 요청 하는가 -Much of open source work is volunteered. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time. +대부분의 오픈소스 작업은 자원봉사입니다. 예를 들어, 누군가가 사용하는 프로젝트에서 버그를 발견하고 빠른 버그픽스를 제출하거나, 여가 시간에 오픈소스 프로젝트를 사용하여 재미있는 작업을 할 수 있습니다. -There are many reasons why a person would not want to be paid for their open source work. +사람들이 오픈소스 작업을 위해 돈을 내고 싶어하지 않는 데에는 여러 가지 이유가 있습니다. -* **They may already have a full-time job that they love,** which enables them to contribute to open source in their spare time. -* **They enjoy thinking of open source as a hobby** or creative escape and don't want to feel financially obligated to work on their projects. -* **They get other benefits from contributing to open source,** such as building their reputation or portfolio, learning a new skill, or feeling closer to a community. +* **그들은 이미 좋아하는 정규직을 가질 수 있어서,** 여유 시간에 오픈소스에 기여할 수 있습니다. +* **그들은 오픈소스를 취미** 또는 창조적인 탈출구로 생각하고 프로젝트에 대한 재정적 의무를 느끼고 싶지 않습니다. +* **그들은 오픈소스에 기여함으로써 다른 이익을 얻고,** 자신의 평판이나 포트폴리오를 구축하고, 새로운 기술을 배우며, 커뮤니티에 더 가까이 다가가는 느낌을 주는 일을 합니다. -For others, especially when contributions are ongoing or require significant time, getting paid to contribute to open source is the only way they can participate, either because the project requires it, or for personal reasons. +다른 사람들에게, 특히 기여가 진행 중이거나 상당한 시간이 필요한 경우, 프로젝트가 요구하거나 개인적인 이유로 참여할 수있는 유일한 방법은 오픈소스에 기여하기 위해 값을 지불하는 것입니다. -Maintaining popular projects can be a significant responsibility, taking up 10 or 20 hours per week instead of a few hours per month. +대중적인 프로젝트를 유지하는 것은 한 달에 몇 시간이라 하기보다는 주당 10-20시간을 소비하는 중요한 책임입니다. -Paid work also enables people from different walks of life to make meaningful contributions. Some people cannot afford to spend unpaid time on open source projects, based on their current financial position, debt, or family or other caretaking obligations. That means the world never sees contributions from talented people who can't afford to volunteer their time. This has ethical implications, as @ashedryden [has described](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), since work that is done is biased in favor of those who already have advantages in life, who then gain additional advantages based on their volunteer contributions, while others who are not able to volunteer then don't get later opportunities, which reinforces the current lack of diversity in the open source community. +또한 유료 작업을 통해 여러 계층의 사람들이 의미있는 기여를 할 수 있습니다. 어떤 사람들은 현재 재무 상태, 부채, 또는 가족 또는 다른 보살필 의무를 다하지않고 오픈소스 프로젝트에 시간을 보낼 여력이 없습니다. 즉, 세상은 자신의 시간을 자원봉사할 여력이없는 재능있는 사람들에게서 기여를 결코 볼 수 없다는 것을 의미합니다. @ashryden이 [설명한대로] (https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community) 윤리적 함의가 있습니다. 이미 인생에 여유가 있는 사람들에게 치우친다는 것은, 자원 봉사자들의 기여에 기초하여 추가적인 이점을 얻는 반면, 자원봉사를 할 수 없는 사람들에게는 나중에 기회를 얻지 못하여, 더더욱 오픈소스의 다양성이 부족해집니다. -If you're looking for financial support, there are two paths to consider. You can fund your own time as a contributor, or you can find organizational funding for the project. +재정 지원을 찾고 있다면, 고려해야 할 두 가지 경로가 있습니다. 기여자로서 자신의 시간을 투자하거나, 프로젝트에 대한 조직 자금을 찾을 수 있습니다. ## 시간 펀딩하기 -Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer. +오늘날, 많은 사람들이 오픈소스에서 파트 타임 또는 풀 타임으로 일하기 위해 돈을 받습니다. 당신의 시간에 대한 대금을 받는 가장 일반적인 방법은 고용주와 상담하는 것입니다. -It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general. +고용주가 프로젝트를 실제로 사용하고 오픈소스 작업에 대한 사례를 만드는 것이 더 쉽지만, 자신의 계획대로 창의력을 발휘하십시오. 어쩌면 고용주가 프로젝트를 사용하지 않고 파이썬을 이용한 인기있는 파이썬 프로젝트를 유지한다면, 새로운 파이썬 개발자를 유치 할 수 있습니다. 어쩌면 고용주가 일반적으로 더 개발자 친화적인 것처럼 보일 수도 있습니다. -If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software. +기존의 오픈소스 프로젝트가 없지만 현재 작업 결과물이 오픈소스인 경우, 고용주가 내부 소프트웨어의 일부를 소스로 오픈할 수있는 사례를 작성하십시오. -Many companies are developing open source programs to build their brand and recruit quality talent. +많은 기업들이 브랜드를 구축하고 우수한 인재를 영입하기 위해 오픈소스 프로그램을 개발하고 있습니다. @hueniverse, for example, found that there were financial reasons to justify [Walmart's investment in open source](http://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). And @jamesgpearce found that Facebook's open source program [made a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) in recruiting: @@ -183,5 +183,5 @@ Does the funder have any requirements around disbursal? For example, you may nee ## 실험적이고 포기하지 말기 -오픈 소스 프로젝트, 비영리 단체, 소프트웨어 스타트업 등 많은 돈을 모으는 것은 쉽지 않습니다. 대부분의 경우 창의력을 발휘해야합니다. 어떻게 돈을 받고, 연구를 하고, 재밌는 사람의 신발에 몸을 두는지를 확인하면 자금 지원에 대한 설득력있는 사례를 구축하는 데 도움이됩니다. +오픈소스 프로젝트, 비영리 단체, 소프트웨어 스타트업 등 많은 돈을 모으는 것은 쉽지 않습니다. 대부분의 경우 창의력을 발휘해야합니다. 어떻게 돈을 받고, 연구를 하고, 재밌는 사람의 신발에 몸을 두는지를 확인하면 자금 지원에 대한 설득력있는 사례를 구축하는 데 도움이됩니다. > From 9df4e475c8df098faca9100692ed6869429a96fb Mon Sep 17 00:00:00 2001 From: minwook Date: Thu, 2 Nov 2017 17:26:39 +0900 Subject: [PATCH 39/87] fix typo and update string --- _articles/ko-KR/getting-paid.md | 16 ++++++++-------- _articles/ko-KR/metrics.md | 2 +- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/_articles/ko-KR/getting-paid.md b/_articles/ko-KR/getting-paid.md index 0094699264e..27d8f9d6174 100644 --- a/_articles/ko-KR/getting-paid.md +++ b/_articles/ko-KR/getting-paid.md @@ -85,9 +85,9 @@ I was looking for a "hobby" programming project that would keep me occupied duri @hueniverse, for example, found that there were financial reasons to justify [Walmart's investment in open source](http://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). And @jamesgpearce found that Facebook's open source program [made a difference](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) in recruiting: -> 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. +> 이는 해커 문화와 밀접하게 연계되어 있으며, 조직이 어떻게 인식되었는지를 보여줍니다. 우리는 직원들에게 "페이스북에서 쓰이는 오픈소스 소프트웨어 프로그램에 대해 알고 있었습니까?"라고 물었습니다. 3분의2가 "그렇다"고 답했습니다. 절반정도는 이 프로그램이 우리를 위해 일하기로 한 결정에 긍정적으로 기여했다고 전했습니다. 이것들은 한계적인 숫자가 아니며 희망을 말합니다. -If your company goes down this route, it's important to keep the boundaries between community and corporate activity clear. Ultimately, open source sustains itself through contributions from people all over the world, and that's bigger than any one company or location. +회사가 이 경로를 따라 간다면, 커뮤니티와 기업 활동의 경계를 분명하게 유지하는 것이 중요합니다. 궁극적으로 오픈소스는 전 세계 모든 사람들의 공헌을 통해 스스로를 유지하며, 이는 어느 회사의 위치보다 큽니다. -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](http://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 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: +마지막으로, 개인적인 상황에 따라, 오픈소스 작업을 위해 독립적으로 돈을 모으는 노력을 할 수 있습니다. 예시: * @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](http://redux.js.org/) * @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) ## 프로젝트 펀딩 찾기 -Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work. +개인 기여자를 위한 준비 외에도, 때로는 프로젝트가 회사, 개인 또는 다른 사람들로부터 지속적인 자금 마련을 위해 펀드를 모으는 경우가 있습니다. -Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing into new features or ideas. +조직 펀딩은 현재 참여자에게 비용을 지불하거나, 프로젝트 수행 비용 (호스팅 비용 등)을 충당하거나, 새로운 기능이나 아이디어에 투자하는 쪽으로 갈 수 있습니다. -As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available. +오픈소스의 대중성이 높아짐에 따라, 프로젝트 펀딩은 아직 실험적이지만, 몇가지 공통적인 옵션이 있습니다. -### Raise money for your work through crowdfunding campaigns or sponsorships +### 크라우드 펀딩(crowdfunding) 캠페인이나 스폰서십을 통해 당신의 업무에 돈을 모으기 Finding sponsorships works well if you have a strong audience or reputation already, or your project is very popular. A few examples of sponsored projects include: diff --git a/_articles/ko-KR/metrics.md b/_articles/ko-KR/metrics.md index 49d8e3be4ef..8954b1ec582 100644 --- a/_articles/ko-KR/metrics.md +++ b/_articles/ko-KR/metrics.md @@ -1,7 +1,7 @@ --- locale: ko-KR title: 오픈소스 측정항목 -description: 성공을 측정하고 추적함으로써 오픈소스 프로젝트가 성공할 수 있도록 정보에 입각한 의사 결정을하십시오. +description: 성공을 측정하고 추적함으로써 오픈소스 프로젝트가 성공할 수 있도록 정보에 입각한 의사 결정을 하십시오. class: metrics toc: why-measure-anything: "Why measure anything?" From 892d83554d477be39c9fec234ca5ea0adba29945 Mon Sep 17 00:00:00 2001 From: minwook Date: Thu, 2 Nov 2017 19:01:56 +0900 Subject: [PATCH 40/87] fix link --- _articles/ko-KR/getting-paid.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_articles/ko-KR/getting-paid.md b/_articles/ko-KR/getting-paid.md index 27d8f9d6174..490fd95caea 100644 --- a/_articles/ko-KR/getting-paid.md +++ b/_articles/ko-KR/getting-paid.md @@ -53,7 +53,7 @@ I was looking for a "hobby" programming project that would keep me occupied duri

-또한 유료 작업을 통해 여러 계층의 사람들이 의미있는 기여를 할 수 있습니다. 어떤 사람들은 현재 재무 상태, 부채, 또는 가족 또는 다른 보살필 의무를 다하지않고 오픈소스 프로젝트에 시간을 보낼 여력이 없습니다. 즉, 세상은 자신의 시간을 자원봉사할 여력이없는 재능있는 사람들에게서 기여를 결코 볼 수 없다는 것을 의미합니다. @ashryden이 [설명한대로] (https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community) 윤리적 함의가 있습니다. 이미 인생에 여유가 있는 사람들에게 치우친다는 것은, 자원 봉사자들의 기여에 기초하여 추가적인 이점을 얻는 반면, 자원봉사를 할 수 없는 사람들에게는 나중에 기회를 얻지 못하여, 더더욱 오픈소스의 다양성이 부족해집니다. +또한 유료 작업을 통해 여러 계층의 사람들이 의미있는 기여를 할 수 있습니다. 어떤 사람들은 현재 재무 상태, 부채, 또는 가족 또는 다른 보살필 의무를 다하지않고 오픈소스 프로젝트에 시간을 보낼 여력이 없습니다. 즉, 세상은 자신의 시간을 자원봉사할 여력이없는 재능있는 사람들에게서 기여를 결코 볼 수 없다는 것을 의미합니다. @ashryden이 [설명한대로](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community) 윤리적 함의가 있습니다. 이미 인생에 여유가 있는 사람들에게 치우친다는 것은, 자원 봉사자들의 기여에 기초하여 추가적인 이점을 얻는 반면, 자원봉사를 할 수 없는 사람들에게는 나중에 기회를 얻지 못하여, 더더욱 오픈소스의 다양성이 부족해집니다. -### Do you like organizing? +### 조직하는 것을 좋아합니까? * Link to duplicate issues, and suggest new issue labels, to keep things organized * Go through open issues and suggest closing old ones, [like @nzakas did for ESLint](https://github.com/eslint/eslint/issues/6765) * Ask clarifying questions on recently opened issues to move the discussion forward -### Do you like to code? +### 코드 작성하고 싶습니까? * Find an open issue to tackle, [like @dianjin did for Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) * Ask if you can help write a new feature * Automate project setup * Improve tooling and testing -### Do you like helping people? +### 사람들을 돕는 것을 좋아합니까? * Answer questions about the project on e.g., Stack Overflow ([like this Postgres example](http://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) or Reddit * Answer questions for people on open issues * Help moderate the discussion boards or conversation channels -### Do you like helping others code? +### 다른 사람들의 코드를 돕는 것을 좋아합니까? * Review code on other people's submissions * Write tutorials for how a project can be used * Offer to mentor another contributor, [like @ereichert did for @bronzdoc on Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) -### You don't just have to work on software projects! +### 소프트웨어 프로젝트만으로 작업할 필요는 없습니다! While "open source" often refers to software, you can collaborate on just about anything. There are books, recipes, lists, and classes that get developed as open source projects. -For example: +예시로 아래와 같습니다: * @sindresorhus curates a [list of "awesome" lists](https://github.com/sindresorhus/awesome) * @h5bp maintains a [list of potential interview questions](https://github.com/h5bp/Front-end-Developer-Interview-Questions) for front-end developer candidates * @stuartlynn and @nicole-a-tesla made a [collection of fun facts about puffins](https://github.com/stuartlynn/puffin_facts) -Even if you're a software developer, working on a documentation project can help you get started in open source. It's often less intimidating to work on projects that don't involve code, and the process of collaboration will build your confidence and experience. +비록 당신이 소프트웨어 개발자일지라도, 문서 프로젝트 작업은 오픈소스에서 시작하는 데 도움이 될 수 있습니다. 코드를 포함하지 않는 프로젝트에서 작업하는 것이 종종 위협적이지 않으며, 협업 프로세스가 자신감과 경험을 쌓을 수 있습니다. -## Orienting yourself to a new project +## 새로운 프로젝트에 동참하기 -## How to submit a contribution +## 기여 제출 방법 -You've found a project you like, and you're ready to make a contribution. Finally! Here's how to get your contribution in the right way. +원하는 프로젝트를 찾았으면 기꺼이 기여할 준비가되었습니다. 마침내! 올바른 방법으로 기여를 받는 방법은 다음과 같습니다. -### Communicating effectively +### 효과적으로 의사 소통하기 -Whether you're a one-time contributor or trying to join a community, working with others is one of the most important skills you'll develop in open source. +일회 기여자이든 커뮤니티에 참여하려고하든, 관계없이 다른 사람들과 협력하는 것은 오픈소스에서 개발할 가장 중요한 기술 중 하나입니다. -Before you open an issue or pull request, or ask a question in chat, keep these points in mind to help your ideas come across effectively. +이슈를 열거나 pull request를 하기 전에, 또는 채팅에서 질문을 하기 전에, 아이디어를 효과적으로 전달할 수 있도록 이러한 점을 명심하십시오. -**Give context.** Help others get quickly up to speed. If you're running into an error, explain what you're trying to do and how to reproduce it. If you're suggesting a new idea, explain why you think it'd be useful to the project (not just to you!). +**context 제공하기.** 다른 사람들이 신속하게 속도를 낼 수 있도록 도와주십시오. 오류가 발생하는 경우, 수행하려는 작업과 오류를 재현하는 방법을 설명하십시오. 새로운 아이디어를 제안하는 경우, 프로젝트에 유용하다고 생각하는 이유를 설명하십시오 (귀하뿐 아니라!). -> 😇 _"X doesn't happen when I do Y"_ +> 😇 _"제가 Y를 하려면 X가 안됩니다"_ > -> 😢 _"X is broken! Please fix it."_ +> 😢 _"X 가 망가졌네요! 이거 고쳐주세요."_ **Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate when you demonstrate that you're trying to learn. -> 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_ +> 😇 _"X를 구현하는 방법을 잘 모르겠네요. 도움말 문서를 확인했고 모든 멘션도 찾지 못했습니다."_ > -> 😢 _"How do I X?"_ +> 😢 _"X는 어떻게 해요?"_ **Keep requests short and direct.** Much like sending an email, every contribution, no matter how simple or helpful, requires someone else's review. Many projects have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you. -> 😇 _"I'd like to write an API tutorial."_ +> 😇 _"API 튜토리얼을 작성하고 싶습니다."_ > -> 😢 _"I was driving down the highway the other day and stopped for gas, and then I had this amazing idea for something we should be doing, but before I explain that, let me show you..."_ +> 😢 _"저는 다른 날 고속도로를 몰고 가스로 달려 들었어요. 그리고 나서 저는 우리가 해야 할 일에 대해 이 놀라운 생각을 가지고 있었고요. 그렇지만 제가가 설명하기 전에, 님께 보여주기 위해서..."_ **Keep all communication public.** Although it's tempting, don't reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation). When you keep the conversation public, more people can learn and benefit from your exchange. Discussions can be, in themselves, contributions. -> 😇 _(as a comment) "@-maintainer Hi there! How should we proceed on this PR?"_ +> 😇 _(댓글로) "@-메인테이너 안녕하세요! 이 PR은 어떻게 진행되고 있나요?"_ > -> 😢 _(as an email) "Hey there, sorry to bother you over email, but I was wondering if you've had a chance to review my PR"_ +> 😢 _(이메일로) "안녕하세요, 이메일을 보내서 죄송합니다만.제 PR을 검토할 기회가 있었는지 궁금합니다."_ **It's okay to ask questions (but be patient!).** Everybody was new to the project at some point, and even experienced contributors need to get up to speed when they look at a new project. By the same token, even longtime maintainers are not always familiar with every part of the project. Show them the same patience that you'd want them to show to you. -> 😇 _"Thanks for looking into this error. I followed your suggestions. Here's the output."_ +> 😇 _"이 오류 찾아주셔서 고맙습니다. 저는 이 제안에 따를게요. 이렇게 출력되네요."_ > -> 😢 _"Why can't you fix my problem? Isn't this your project?"_ +> 😢 _"왜 내 문제를 해결할 수 없어요? 이 프로젝트는 님이 만든게 아닌가요?"_ **Respect community decisions.** Your ideas may differ from the community's priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project. -> 😇 _"I'm disappointed you can't support my use case, but as you've explained it only affects a minor portion of users, I understand why. Thanks for listening."_ +> 😇 _"제 use case를 지원할 수 없다는 점에 실망했지만, 사용자의 작은 부분에만 영향을 주었다고 설명하셨으니 이해됩니다. 들어주셔서 감사합니다."_ > -> 😢 _"Why won't you support my use case? This is unacceptable!"_ +> 😢 _"왜 use case를 지원하지 않나요? 납득할 수 없네요!"_ **Above all, keep it classy.** Open source is made up of collaborators from all over the world. Context gets lost across languages, cultures, geographies, and time zones. In addition, written communication makes it harder to convey a tone or mood. Assume good intentions in these conversations. It's fine to politely push back on an idea, ask for more context, or further clarify your position. Just try to leave the internet a better place than when you found it. @@ -457,11 +453,11 @@ If you want to make a substantial contribution, open an issue to ask before work avatar You'll learn a lot from taking a single project you actively use, "watching" it on GitHub and reading every issue and PR.

-— @gaearon [on joining projects](https://twitter.com/dan_abramov/status/819555257055322112) +— @gaearon [프로젝트 합류](https://twitter.com/dan_abramov/status/819555257055322112)

-### Opening an issue +### 이슈 열기 You should usually open an issue in the following situations: @@ -475,7 +471,7 @@ Tips for communicating on issues: * **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work. * **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project. -### Opening a pull request +### pull request 열기 You should usually open a pull request in the following situations: @@ -495,13 +491,13 @@ If the project is on GitHub, here's how to submit a pull request: If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a free walkthrough resource. -## What happens after you submit a contribution +## 기여를 제출하면 어떻게됩니까? -You did it! Congratulations on becoming an open source contributor. We hope it's the first of many. +훌륭합니다! 오픈소스 기여자가 되신 것을 축하드립니다. 우리는 그것이 많은 사람들 중 첫번째가 되기를 바랍니다. -After you submit a contribution, one of the following will happen: +기여를 제출하면 다음 중 하나가 발생합니다. -### 😭 You don't get a response. +### 😭 당신은 응답을 얻지 못합니다. Hopefully you [checked the project for signs of activity](#a-checklist-before-you-contribute) before making a contribution. Even on an active project, however, it's possible that your contribution won't get a response. @@ -511,7 +507,7 @@ If you haven't gotten a response in over a week, it's fair to politely respond i If you make a polite bump and still nobody responds, it's possible that nobody will respond, ever. It's not a great feeling, but don't let that discourage you. It's happened to everyone! There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive. -### 🚧 Someone requests changes to your contribution. +### 🚧 누군가 기여를 변경 요청해야합니다. It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code. @@ -519,13 +515,13 @@ When someone requests changes, be responsive. They've taken the time to review y If you don't have time to work on the issue anymore (for example, if the conversation has been going on for months, and your circumstances have changed), let the maintainer know so they're not expecting a response. Someone else may be happy to take over. -### 👎 Your contribution doesn't get accepted. +### 👎 귀하의 기여가 받아지지 않았습니다. -Your contribution may or may not be accepted in the end. Hopefully you didn't put too much work into it already. If you're not sure why it wasn't accepted, it's perfectly reasonable to ask the maintainer for feedback and clarification. Ultimately, however, you'll need to respect that this is their decision. Don't argue or get hostile. You're always welcome to fork and work on your own version if you disagree! +귀하의 기여는 결국 받아지거나 수락되지 않을 수도 있습니다. 다행히도 이미 너무 많은 작업을 하지 않았으면 합니다. 왜 그것이 받아들여지지 않았는지 확신할 수 없다면, 메인테이너 담당자에게 피드백과 설명을 요청하는 것이 합리적입니다. 그러나 궁극적으로 이것이 자신의 결정임을 존중해야합니다. 논쟁하거나 적대적인 태도를 취하지 마십시오. 동의하지 않으면, 항상 자신의 버전을 포크하고 작업할 수 있습니다! -### 🎉 Your contribution gets accepted. +### 🎉 귀하의 기여가 받아졌습니다. -Hooray! You've successfully made an open source contribution! +만세! 성공적으로 오픈소스 기여를 만들었습니다! ## 훌륭합니다! From db15d8dfb7d032461349a9f2b3799419853b507c Mon Sep 17 00:00:00 2001 From: minwook Date: Wed, 20 Dec 2017 19:24:18 +0900 Subject: [PATCH 48/87] fix typo --- _articles/ko-KR/getting-paid.md | 2 +- _data/locale/ko-KR.yml | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/_articles/ko-KR/getting-paid.md b/_articles/ko-KR/getting-paid.md index 9743eb6856f..bff02f271c7 100644 --- a/_articles/ko-KR/getting-paid.md +++ b/_articles/ko-KR/getting-paid.md @@ -85,7 +85,7 @@ I was looking for a "hobby" programming project that would keep me occupied duri @hueniverse, for example, found that there were financial reasons to justify [Walmart's investment in open source] -예를 들어 @hueniverse는, [Walmart의 오픈소스에 대한 투자](http://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html)를 정당화 할 재정적인 이유가 있음을 발견했습니다. 그리고 @jamesgpearce는 Facebook의 오픈 소스 프로그램이 채용에서 [차이를 만들었다](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon)는 사실을 발견했습니다: +예를 들어 @hueniverse는, [Walmart의 오픈소스에 대한 투자](http://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html)를 정당화 할 재정적인 이유가 있음을 발견했습니다. 그리고 @jamesgpearce는 Facebook의 오픈소스 프로그램이 채용에서 [차이를 만들었다](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon)는 사실을 발견했습니다: > 이는 해커 문화와 밀접하게 연계되어 있으며, 조직이 어떻게 인식되었는지를 보여줍니다. 우리는 직원들에게 "페이스북에서 쓰이는 오픈소스 소프트웨어 프로그램에 대해 알고 있었습니까?"라고 물었습니다. 3분의2가 "그렇다"고 답했습니다. 절반정도는 이 프로그램이 우리를 위해 일하기로 한 결정에 긍정적으로 기여했다고 전했습니다. 이것들은 한계적인 숫자가 아니며 희망을 말합니다. diff --git a/_data/locale/ko-KR.yml b/_data/locale/ko-KR.yml index 100104da17f..4921374accf 100644 --- a/_data/locale/ko-KR.yml +++ b/_data/locale/ko-KR.yml @@ -3,7 +3,7 @@ nav: contribute: 기여 index: - lead: 오픈 소스 소프트웨어는 당신과 비슷한 사람들이 만듭니다. 프로젝트를 시작하고 성장시키는 방법에 대해 배워보십시오. + lead: 오픈소스 소프트웨어는 당신과 비슷한 사람들이 만듭니다. 프로젝트를 시작하고 성장시키는 방법에 대해 배워보십시오. article: table_of_contents: 목차 @@ -11,11 +11,11 @@ article: footer: contribute: heading: 기여 - description: 제안 하기 원하시나요? 이 내용은 오픈 소스입니다.개선 할 수 있도록 도와주세요. + description: 제안 하기 원하시나요? 이 내용은 오픈소스입니다.개선 할 수 있도록 도와주세요. button: 기여하기 subscribe: heading: 계속 소식 받기 - description: GitHub의 최신 오픈 소스 팁과 리소스에 대해 먼저 들어보십시오. + description: GitHub의 최신 오픈소스 팁과 리소스에 대해 먼저 들어보십시오. label: 이메일 주소 button: 구독하기 byline: From b3735a5a6cacf76a1e6558465218f095c0989e28 Mon Sep 17 00:00:00 2001 From: minwook Date: Wed, 20 Dec 2017 20:22:33 +0900 Subject: [PATCH 49/87] update translation --- _articles/ko-KR/how-to-contribute.md | 90 ++++++++++++++-------------- 1 file changed, 45 insertions(+), 45 deletions(-) diff --git a/_articles/ko-KR/how-to-contribute.md b/_articles/ko-KR/how-to-contribute.md index 3ac37ad5e7e..5fb03209f1e 100644 --- a/_articles/ko-KR/how-to-contribute.md +++ b/_articles/ko-KR/how-to-contribute.md @@ -4,7 +4,7 @@ title: 오픈소스에 기여하는 방법 description: 오픈소스에 기여하고 싶습니까? 초보자와 숙련자를 위한 오픈소스 기여에 대한 가이드입니다. class: contribute toc: - why-contribute-to-open-source: "왜 오픈 소스에 기여 하나요?" + why-contribute-to-open-source: "왜 오픈소스에 기여 하나요?" what-it-means-to-contribute: "기여한다는 것의 의미" orienting-yourself-to-a-new-project: "새로운 프로젝트에 동참하기" finding-a-project-to-contribute-to: "기여할 프로젝트 찾기" @@ -63,7 +63,7 @@ related: ### 코드를 제공할 필요가 없습니다 -오픈 소스에 기여하는 것에 대한 일반적인 오해는 코드를 작성해야한다는 것입니다. 실제로 대부분 프로젝트에서 [무시되거나 간과되는 부분](https://github.com/blog/2195-the-shape-of-open-source)입니다 . 이러한 유형의 기여를 제공하도록 제안함으로써 프로젝트에 큰 도움을 줄 것입니다! +오픈소스에 기여하는 것에 대한 일반적인 오해는 코드를 작성해야한다는 것입니다. 실제로 대부분 프로젝트에서 [무시되거나 간과되는 부분](https://github.com/blog/2195-the-shape-of-open-source)입니다 . 이러한 유형의 기여를 제공하도록 제안함으로써 프로젝트에 큰 도움을 줄 것입니다! -For anything more than a typo fix, contributing to open source is like walking up to a group of strangers at a party. If you start talking about llamas, while they were deep in a discussion about goldfish, they'll probably look at you a little strangely. +오타를 수정하는 이상의 것, 오픈소스에 기여하는 것은 파티에서 낯선 사람들에게 다가가는 것과 같습니다. 라마에 대해 이야기하기 시작하면, 금붕어에 관한 토론이 깊어지면서 아마 당신을 조금 이상하게 보게 될 것입니다. -Before jumping in blindly with your own suggestions, start by learning how to read the room. Doing so increases the chances that your ideas will be noticed and heard. +자신의 제안으로 맹목적으로 뛰어 들기 전에, 먼저 방을 읽는 법을 배우십시오. 그렇게하면 아이디어가 눈에 띄고 들리게 될 확률이 높아집니다. ### 오픈소스 프로젝트의 해부학 모든 오픈소스 커뮤니티는 다릅니다. -Spending years on one open source project means you've gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different. +하나의 오픈소스 프로젝트에 수년을 보내다 보면 하나의 오픈소스 프로젝트를 알게되었다는 것을 의미합니다. 다른 프로젝트로 이동하면 어휘, 규범 및 의사 소통 스타일이 완전히 다른 것을 알 수 있습니다. -That said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project. +즉, 많은 오픈소스 프로젝트는 비슷한 조직 구조를 따릅니다. 서로 다른 커뮤니티 역할과 전반적인 프로세스를 이해하면 새로운 프로젝트를 신속하게 수행할 수 있습니다. -A typical open source project has the following types of people: +일반적인 오픈소스 프로젝트에는 다음 유형의 사람들이 있습니다: -* **작성자:** The person/s or organization that created the project -* **소유자:** The person/s who has administrative ownership over the organization or repository (not always the same as the original author) -* **메인테이너:** 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.) -* **기여자:** Everyone who has contributed something back to the project. -* **커뮤니티 맴버:** 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. -A project also has documentation. These files are usually listed in the top level of a repository. +프로젝트에도 문서가 있습니다. 이러한 파일은 대개 저장소의 최상위 레벨에 나열됩니다. * **라이선스:** By definition, every open source project must have an [open source license](https://choosealicense.com). If the project does not have a license, it is not open source. * **README:** The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started. @@ -198,23 +198,23 @@ Finally, open source projects use the following tools to organize discussion. Re ## 기여할 프로젝트 찾기 -Now that you've figured out how open source projects work, it's time to find a project to contribute to! +이제 오픈소스 프로젝트가 어떻게 작동하는지 알게 되었으니, 이제는 기여할 프로젝트를 찾아야 할 때입니다! -If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said, _"Ask not what your country can do for you - ask what you can do for your country."_ +이전에 오픈소스에 기여한 적이 없다면, John F. Kennedy 미국 대통령의 _"Ask not what your country can do for you - ask what you can do for your country."_ 발언에서 조언을 구하십시오. -Contributing to open source happens at all levels, across projects. You don't need to overthink what exactly your first contribution will be, or how it will look. +오픈소스에 기여하는 것은 프로젝트 전반에 걸쳐 모든 수준에서 발생합니다. 첫 번째 기여가 정확히 무엇인지 또는 어떻게 보일지를 생각할 필요가 없습니다. -Instead, start by thinking about the projects you already use, or want to use. The projects you'll actively contribute to are the ones you find yourself coming back to. +대신, 이미 사용하고 있거나 사용하고 싶은 프로젝트에 대해 생각해보십시오. 적극적으로 기여할 프로젝트는 자신이 다시 찾아 오는 프로젝트입니다. -Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct. +그 프로젝트 내에서, 뭔가가 더 좋거나 다를 수 있다고 생각할 때마다 본능에 따라 행동하십시오. -Open source isn't an exclusive club; it's made by people just like you. "Open source" is just a fancy term for treating the world's problems as fixable. +오픈소스는 독점적인 클럽이 아닙니다; 그것은 당신 같은 사람들에 의해 만들어졌습니다. "오픈소스"는 전세계 문제를 유연하게 해결할 수 있는 멋진 용어입니다. -You might scan a README and find a broken link or a typo. Or you're a new user and you noticed something is broken, or an issue that you think should really be in the documentation. Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That's what open source is all about! +README를 스캔하여 깨진 링크 또는 오타를 찾을 수 있습니다. 또는 새로운 사용자이고 무언가가 고장 났거나, 실제로 문서에 있어야한다고 생각되는 문제를 발견했습니다. 그것을 무시하고 계속 나아가거나, 다른 사람에게 그것을 고치라고 요구하는 대신, 피칭을 통해 도움을 줄 수 있는지 확인하십시오. 오픈소스가 무엇인지 알아보십시오! -> [28% of casual contributions](http://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as a typo fix, reformatting, or writing a translation. +> [일반적인 기여의 28%](http://www.igor.pro.br/publica/papers/saner2016.pdf)는 오타 수정, 서식 재 지정 또는 번역 작성과 같은 문서입니다. -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) @@ -403,49 +403,49 @@ You can also use one of the following resources to help you discover and contrib > > 😢 _"X 가 망가졌네요! 이거 고쳐주세요."_ -**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate when you demonstrate that you're trying to learn. +**미리 과제하기.** 무언가 알지는 못하지만 시도한 것을 보여주십시오. 도움을 요청하기 전에 프로젝트의 README, 문서, 이슈 (공개 또는 비공개), 메일링 리스트를 확인하고 인터넷에서 답변을 검색하십시오. 사람들은 당신이 배우려고한다는 것을 증명할 때 감사해할 것입니다. > 😇 _"X를 구현하는 방법을 잘 모르겠네요. 도움말 문서를 확인했고 모든 멘션도 찾지 못했습니다."_ > > 😢 _"X는 어떻게 해요?"_ -**Keep requests short and direct.** Much like sending an email, every contribution, no matter how simple or helpful, requires someone else's review. Many projects have more incoming requests than people available to help. Be concise. You will increase the chance that someone will be able to help you. +**요청을 짧고 직접적으로 유지하기.** 이메일을 보내는 것과 마찬가지로 모든 기여는 아무리 간단하거나 도움이된다 하더라도, 다른 사람의 검토가 필요합니다. 많은 프로젝트는 도움을 줄 수있는 사람들보다 많은 요청을 받고 있습니다. 간결하게 하십시오. 누군가가 당신을 도울 수있는 기회를 증가시킬 것입니다. > 😇 _"API 튜토리얼을 작성하고 싶습니다."_ > -> 😢 _"저는 다른 날 고속도로를 몰고 가스로 달려 들었어요. 그리고 나서 저는 우리가 해야 할 일에 대해 이 놀라운 생각을 가지고 있었고요. 그렇지만 제가가 설명하기 전에, 님께 보여주기 위해서..."_ +> 😢 _"저는 다른 날 고속도로를 몰고 가스로 달려 들었어요. 그리고 나서 저는 우리가 해야 할 일에 대해 이 놀라운 생각을 가지고 있었고요. 그렇지만 제가 설명하기 전에, 님께 보여주기 위해서..."_ -**Keep all communication public.** Although it's tempting, don't reach out to maintainers privately unless you need to share sensitive information (such as a security issue or serious conduct violation). When you keep the conversation public, more people can learn and benefit from your exchange. Discussions can be, in themselves, contributions. +**모든 커뮤니케이션을 공개하기.** 유혹스러운 일이긴하지만, 중요한 정보(예 : 보안 문제 또는 심각한 행동 위반)를 공유해야하는 경우가 아니면 메인테이너에게 개인적으로 연락하지 마십시오. 대화를 공개 할 때 더 많은 사람들이 귀하의 교류를 통해 배우고 이익을 얻을 수 있습니다. 토론은 그 자체로 기여할 수 있습니다. > 😇 _(댓글로) "@-메인테이너 안녕하세요! 이 PR은 어떻게 진행되고 있나요?"_ > > 😢 _(이메일로) "안녕하세요, 이메일을 보내서 죄송합니다만.제 PR을 검토할 기회가 있었는지 궁금합니다."_ -**It's okay to ask questions (but be patient!).** Everybody was new to the project at some point, and even experienced contributors need to get up to speed when they look at a new project. By the same token, even longtime maintainers are not always familiar with every part of the project. Show them the same patience that you'd want them to show to you. +**질문을 하는 것은 괜찮습니다(그러나 참을성 있으십시오!).** 누구나 프로젝트를 처음 접했을뿐 아니라 경험 많은 공헌자도 새로운 프로젝트를 볼 때 속도를 높여야 합니다. 마찬가지로, 오랜 기간의 메인테이너가 프로젝트의 모든 부분을 항상 잘 알고있는 것은 아닙니다. 그들에게 당신이 보여주기를 바라는 것과 같은 인내심을 보여주십시오. > 😇 _"이 오류 찾아주셔서 고맙습니다. 저는 이 제안에 따를게요. 이렇게 출력되네요."_ > > 😢 _"왜 내 문제를 해결할 수 없어요? 이 프로젝트는 님이 만든게 아닌가요?"_ -**Respect community decisions.** Your ideas may differ from the community's priorities or vision. They may offer feedback or decide not to pursue your idea. While you should discuss and look for compromise, maintainers have to live with your decision longer than you will. If you disagree with their direction, you can always work on your own fork or start your own project. +**커뮤니티의 의사 결정을 존중하기.** 귀하의 아이디어는 커뮤니티의 우선 순위 또는 비전과 다를 수 있습니다. 그들은 의견을 제시하거나 아이디어를 추구하지 않기로 결정할 수 있습니다. 토론하고 타협을 찾아야하지만, 메인테이너는 당신보다 더 오래 결정을 내리지 않고 살아야합니다. 당신이 그들의 방향에 동의하지 않으면, 당신은 항상 자신의 포크에서 일하거나 자신의 프로젝트를 시작할 수 있습니다. > 😇 _"제 use case를 지원할 수 없다는 점에 실망했지만, 사용자의 작은 부분에만 영향을 주었다고 설명하셨으니 이해됩니다. 들어주셔서 감사합니다."_ > > 😢 _"왜 use case를 지원하지 않나요? 납득할 수 없네요!"_ -**Above all, keep it classy.** Open source is made up of collaborators from all over the world. Context gets lost across languages, cultures, geographies, and time zones. In addition, written communication makes it harder to convey a tone or mood. Assume good intentions in these conversations. It's fine to politely push back on an idea, ask for more context, or further clarify your position. Just try to leave the internet a better place than when you found it. +**무엇보다도 고급스러움을 유지하기.** 오픈소스는 전 세계의 공동 작업자로 구성됩니다. 컨텍스트는 언어, 문화, 지역 및 시간대에 걸쳐 손실됩니다. 또한 서면 의사 소통을 통해 분위기 나 분위기를 전달하기가 더 어려워집니다. 이 대화에서 좋은 의도를 가정하십시오. 정중하게 생각을 뒤로 밀거나, 더 많은 맥락을 묻거나, 더 자세하게 설명하는 것은 좋습니다. 인터넷을 찾은 때보다 더 나은 곳을 떠나보십시오. -### Gathering context +### 컨텍스트 수집 Before doing anything, do a quick check to make sure your idea hasn't been discussed elsewhere. Skim the project's README, issues (open and closed), mailing list, and Stack Overflow. You don't have to spend hours going through everything, but a quick search for a few key terms goes a long way. If you can't find your idea elsewhere, you're ready to make a move. If the project is on GitHub, you'll likely communicate by opening an issue or pull request: -* **Issues** are like starting a conversation or discussion -* **Pull requests** are for starting work on a solution -* **For lightweight communication,** such as a clarifying or how-to question, try asking on Stack Overflow, IRC, Slack, or other chat channels, if the project has one +* **이슈**는 대화나 토론을 시작하는 것과 같습니다 +* **Pull requests** 는 솔루션에서 일을 시작하기 위한 것입니다 +* 명확한 질문이나 How-To 질문과 같은 **간단한 커뮤니케이션의 경우,** 프로젝트에 하나의 채팅 채널이있으면 스택 오버플로우, IRC, 슬랙 또는 다른 채팅 채널을 요청합니다 -Before you open an issue or pull request, check the project's contributing docs (usually a file called CONTRIBUTING, or in the README), to see whether you need to include anything specific. For example, they may ask that you follow a template, or require that you use tests. +이슈를 열거나 pull request을 요청하기 전에, 프로젝트의 기여 문서(일반적으로 CONTRIBUTING 또는 README 파일)를 확인하여 구체적인 내용을 포함해야하는지 확인하십시오. 예를 들어, 템플릿을 따르거나 테스트를 사용하도록 요청할 수 있습니다. If you want to make a substantial contribution, open an issue to ask before working on it. It's helpful to watch the project for a while (on GitHub, [you can click "Watch"](https://help.github.com/articles/watching-repositories/) to be notified of all conversations), and get to know community members, before doing work that might not get accepted. @@ -459,13 +459,13 @@ If you want to make a substantial contribution, open an issue to ask before work ### 이슈 열기 -You should usually open an issue in the following situations: +일반적으로 다음과 같은 상황에서 이슈를 열어야합니다: -* Report an error you can't solve yourself -* Discuss a high-level topic or idea (ex. community, vision, policies) -* Propose a new feature or other project idea +* 스스로 해결할 수 없는 오류를 보고 +* 높은 수준의 주제 또는 아이디어 (예시. 커뮤니티, 비전, 정책) 토론 +* 새로운 기능이나 다른 프로젝트 아이디어 제안 -Tips for communicating on issues: +이슈에서 의사소통을 위한 팁: * **If you see an open issue that you want to tackle,** comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work. * **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work. @@ -473,14 +473,14 @@ Tips for communicating on issues: ### pull request 열기 -You should usually open a pull request in the following situations: +일반적으로 다음 상황에서 pull request를 열어야합니다: * Submit trivial fixes (ex. a typo, broken link, or obvious error) * Start work on a contribution that was already asked for, or that you've already discussed, in an issue A pull request doesn't have to represent finished work. It's usually better to open a pull request early on, so others can watch or give feedback on your progress. Just mark it as a "WIP" (Work in Progress) in the subject line. You can always add more commits later. -If the project is on GitHub, here's how to submit a pull request: +프로젝트가 GitHub에 있는 경우, pull request을 제출하는 방법은 다음과 같습니다: * **[Fork the repository](https://guides.github.com/activities/forking/)** and clone it locally. Connect your local to the original "upstream" repository by adding it as a remote. Pull in changes from "upstream" often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely. (See more detailed instructions [here](https://help.github.com/articles/syncing-a-fork/).) * **[Create a branch](https://guides.github.com/introduction/flow/)** for your edits. @@ -505,15 +505,15 @@ If you haven't gotten a response in over a week, it's fair to politely respond i **Don't** reach out to that person privately; remember that public communication is vital to open source projects. -If you make a polite bump and still nobody responds, it's possible that nobody will respond, ever. It's not a great feeling, but don't let that discourage you. It's happened to everyone! There are many possible reasons why you didn't get a response, including personal circumstances that may be out of your control. Try to find another project or way to contribute. If anything, this is a good reason not to invest too much time in making a contribution before other community members are engaged and responsive. +정중한 충돌을 하고도 아직 아무도 응답하지 않으면, 아무도 응답하지 않을 가능성이 있습니다. 그것은 큰 감정이 아니지만, 그것이 당신을 낙담하게 하지마십시오. 모두에게 일어난 일입니다! 귀하가 통제 할 수 없는 개인적 상황을 포함하여 응답을 받지 못한 이유는 여러 가지가 있을 수 있습니다. 다른 프로젝트나 기여 방법을 찾으십시오. 다른 커뮤니티 구성원들이 참여하고 반응하기 전에 기여에 많은 시간을 투자하지 않는 것이 좋은 이유입니다. ### 🚧 누군가 기여를 변경 요청해야합니다. -It's common that you'll be asked to make changes to your contribution, whether that's feedback on the scope of your idea, or changes to your code. +아이디어의 범위에 대한 피드백이든 코드의 변경 사항이든, 기여 내용을 변경하라는 메시지가 표시되는 것이 일반적입니다. -When someone requests changes, be responsive. They've taken the time to review your contribution. Opening a PR and walking away is bad form. If you don't know how to make changes, research the problem, then ask for help if you need it. +누군가 변경 사항을 요청하면, 반응적입니다. 그들은 당신의 기여를 검토할 시간을 가졌습니다. PR을 열고 멀리두는 것은 나쁜 형태입니다. 만약 변경 방법을 모르는 경우, 문제를 조사한 다음 필요한 경우 도움을 요청하십시오. -If you don't have time to work on the issue anymore (for example, if the conversation has been going on for months, and your circumstances have changed), let the maintainer know so they're not expecting a response. Someone else may be happy to take over. +만약 더 이상 문제를 해결할 시간이 없다면 (예를 들어, 대화가 몇 달 동안 계속되고 상황이 변경된 경우), 메인테이너에게 알려서 응답을 기대하지 않도록 하십시오. 다른 사람이 기꺼이 받아 들일 수 있습니다. ### 👎 귀하의 기여가 받아지지 않았습니다. From edb9ae9939789095c5c102a5c74d95acf9198bb3 Mon Sep 17 00:00:00 2001 From: minwook Date: Thu, 21 Dec 2017 14:42:17 +0900 Subject: [PATCH 50/87] improve translation --- _articles/ko-KR/best-practices.md | 106 +++++++++++++++--------------- 1 file changed, 53 insertions(+), 53 deletions(-) diff --git a/_articles/ko-KR/best-practices.md b/_articles/ko-KR/best-practices.md index 7ae3b0852e4..acae3459626 100644 --- a/_articles/ko-KR/best-practices.md +++ b/_articles/ko-KR/best-practices.md @@ -9,7 +9,7 @@ toc: learning-to-say-no: "아니오라고 말하는 것을 배우기" leverage-your-community: "커뮤니티 활용하기" bring-in-the-robots: "로봇 가져오기" - its-okay-to-hit-pause: "정지를 눌러도 좋습니다" + its-okay-to-hit-pause: "멈추는것도 좋습니다" order: 5 image: /assets/images/cards/best-practices.png related: @@ -23,7 +23,7 @@ related: 프로젝트 초기 단계에서 새로운 아이디어를 실험하고 원하는 것을 기반으로 의사 결정을 내리고 있습니다. 프로젝트의 인기가 높아짐에 따라 사용자와 기여자들과 더 잘 일할 수 있습니다. -프로젝트를 유지하려면 코드 이상을 요구합니다. 이러한 작업은 예상치 못한 경우가 많지만 성장하는 프로젝트와 마찬가지로 중요합니다. 우리는 프로세스 문서화에서부터 커뮤니티 활용에 이르기까지 당신의 삶을 편하게 해주는 몇 가지 방법을 모아봤습니다. +프로젝트를 유지하려면 코드 이상의 것을 요구합니다. 이러한 작업은 예상치 못한 경우가 많지만 성장하는 프로젝트와 마찬가지로 중요합니다. 우리는 진행 문서화에서 시작해서 커뮤니티 활용에 이르기까지 당신의 삶을 편하게 해주는 몇 가지 방법을 모아봤습니다. ## 진행과정을 문서화하기 @@ -31,17 +31,17 @@ related: 문서는 자신의 생각을 분명히 할 뿐만 아니라, 다른 사람들이 물어보기도 전에 필요하거나 기대하는 것을 이해하도록 도와줍니다. -글을 쓰게되면 무언가가 당신의 범위에 맞지 않을 때 아무 말도 하지 않게됩니다. 또한 사람들이 쉽게 참여하고 도움을 줍니다. 누가 프로젝트를 읽고 사용하는지 알 수 없습니다. +글을 쓰게되면 무언가 범위에 맞지 않을 때 아무 말도 달지 않게됩니다. 또한 사람들이 쉽게 참여하게 도움을 줍니다. 다만 누가 프로젝트를 읽고 사용하는지 알 수는 없습니다. -전체 단락을 사용하지 않더라도, 글 머리 기호를 적어 두는 것이 아에 작성하지 않는것보다 좋습니다. +전체 단락을 사용하지 않더라도, 글 머리 기호라도 적어둔다면 아에 작성하지 않는 것보다는 좋습니다. ### 프로젝트의 비전을 써내려가기 -먼저 프로젝트의 목표를 써내려갑니다. README에 추가하거나, VISION이라 불리는 별도의 파일을 작성하십시오. 프로젝트 로드맵과 같이 도움이 될 수있는 다른 인위적인 결과물이 있는 경우, 이를 공개 할 수도 있습니다. +먼저 프로젝트의 목표를 써내려갑니다. README에 추가하거나, VISION이라 불리는 별도의 파일을 작성하십시오. 프로젝트 로드맵과 같이 도움이 될 수 있는 다른 인위적인 결과물이 있는 경우, 이를 공개 할 수도 있습니다. -명확하고, 문서화 된 비전을 가지고 있으면 집중력을 유지하고 다른 기여자로부터 "scope creep"를 피할 수 있습니다. +명확하고, 문서화된 비전을 가지고 있으면 집중력을 유지하고 다른 기여자로부터 "scope creep"를 피할 수 있습니다. -예를 들어, @lord는 프로젝트 비전을 가짐으로써 시간을 보낼 요청을 파악하는 데 도움이 된다는 것을 발견했습니다. 새로운 메인테이너인, 그는 [Slate](https://github.com/lord/slate)에 대한 첫 번째 기능 요청을 받았을 때 프로젝트의 범위를 고수하지 않은 것을 후회했습니다. +예를 들어, @lord는 프로젝트 비전을 가짐으로써 시간을 보낼 요청을 파악하는 데 도움이 된다는 것을 발견했습니다. 새로운 메인테이너인 그는 [Slate](https://github.com/lord/slate)에 대한 첫번째 기능 요청을 받았을 때 프로젝트의 범위를 고수하지 않은 것을 후회했습니다. @@ -256,7 +256,7 @@ Whether it's official documentation or a casual email, your writing style is par avatar 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), ["지속 가능한 오픈소스"](http://writing.jan.io/2015/11/20/sustainable-open-source.html)

From 65f3acb21996aedc59d0b259999874eeba18e655 Mon Sep 17 00:00:00 2001 From: minwook Date: Mon, 8 Jan 2018 18:47:17 +0900 Subject: [PATCH 68/87] translated this file --- _articles/ko-KR/metrics.md | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/_articles/ko-KR/metrics.md b/_articles/ko-KR/metrics.md index c961528a753..d34d8671967 100644 --- a/_articles/ko-KR/metrics.md +++ b/_articles/ko-KR/metrics.md @@ -53,19 +53,19 @@ If you _are_ interested in understanding your project on a deeper level, read on * **인기 컨텐츠:** 방문자가 프로젝트에서 어디로 이동했는지 알려주며, 페이지 뷰와 고유 방문자별로 세분화됩니다. -[GitHub stars](https://help.github.com/articles/about-stars/) can also help provide a baseline measure of popularity. While GitHub stars don't necessarily correlate to downloads and usage, they can tell you how many people are taking notice of your work. +[GitHub stars](https://help.github.com/articles/about-stars/)는 또한 인기의 기준치 측정을 제공하는 데 도움이 될 수 있습니다. GitHub star는 반드시 다운로드 및 사용량과 상관 관계가 있는 것은 아니지만, 얼마나 많은 사람들이 귀하의 작업에 주의를 기울이고 있는지 말해 줄 수 있습니다. -You may also want to [track discoverability in specific places](https://opensource.com/business/16/6/pirate-metrics): for example, Google PageRank, referral traffic from your project's website, or referrals from other open source projects or websites. +[특정 장소에서 검색 가능성을 추적](https://opensource.com/business/16/6/pirate-metrics) 할 수도 있습니다: 예를 들어, Google 페이지랭크, 프로젝트 웹 사이트의 추천 트래픽 또는 다른 오픈소스 프로젝트 또는 웹 사이트의 추천을 포함 할 수 있습니다. ## 사용 -People are finding your project on this wild and crazy thing we call the internet. Ideally, when they see your project, they'll feel compelled to do something. The second question you'll want to ask is: _are people using this project?_ +사람들은 우리가 인터넷이라고 부르는 이 거칠고 미친 일로 프로젝트를 찾고 있습니다. 이상적으로는, 프로젝트를 보았을 때 뭔가 할 것을 강요 당할 것입니다. 두 번째 질문은 다음과 같습니다: _이 프로젝트를 사용하는 사람들입니까?_ npm 또는 RubyGems.org와 같은 패키지 관리자를 사용하여 프로젝트를 배포하는 경우 프로젝트 다운로드를 추적할 수 있습니다. -Each package manager may use a slightly different definition of "download", and downloads do not necessarily correlate to installs or use, but it provides some baseline for comparison. Try using [Libraries.io](https://libraries.io/) to track usage statistics across many popular package managers. +각 패키지 매니저는 "다운로드"와 약간 다른 정의를 사용할 수 있으며, 다운로드가 반드시 설치 또는 사용과 관련이 있는 것은 아니지만 비교를 위한 기준을 제공합니다. [Libraries.io](https://libraries.io/)를 사용해 많은 인기있는 패키지 매니저의 사용 통계를 추적 해보십시오. -If your project is on GitHub, navigate again to the "Traffic" page. You can use the [clone graph](https://github.com/blog/1873-clone-graphs) to see how many times your project has been cloned on a given day, broken down by total clones and unique cloners. +만약 프로젝트가 깃허브에 있다면, "Traffic"페이지로 사디 이동하보십시오. [clone graph](https://github.com/blog/1873-clone-graphs)를 사용하여 주어진 날에 프로젝트가 복제 된 횟수를 전체 클론 및 클론 받은 사람으로 세분화 할 수 있습니다. ![Clone graph](/assets/images/metrics/clone_graph.png) @@ -82,25 +82,25 @@ If your project is on GitHub, navigate again to the "Traffic" page. You can use ## 보유 -People are finding your project and they're using it. The next question you'll want to ask yourself is: _are people contributing back to this project?_ +사람들이 프로젝트를 찾고 있으며 프로젝트를 사용하고 있습니다. 다음 질문은 스스로에게 물어볼 것입니다: _이 프로젝트에 다시 기여한 사람들입니까?_ -It's never too early to start thinking about contributors. Without other people pitching in, you risk putting yourself into an unhealthy situation where your project is _popular_ (many people use it) but not _supported_ (not enough maintainer time to meet demand). +기여자를 생각하는 것은 너무 이릅니다.다른 사람이 참여하지 않으면 프로젝트가 _인기있고_(많은 사람들이 그것을 사용하지만) _지원_되지 않는(요구 사항을 충족시키는 데 필요한 유지 보수 시간이 충분하지 않음) 좋지 못한 상황에 처할 위험이 있습니다. -Retention also requires an [inflow of new contributors](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), as previously active contributors will eventually move on to other things. +보유자는 이전에 활동적인 기여자가 결국 다른 것들로 이동하기 때문에 [새로운 기여자가 유입](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2)되어야합니다. 정기적으로 추적할 수 있는 커뮤니티 측정 항목의 예는 다음과 같습니다: -* **Total contributor count and number of commits per contributor:** Tells you how many contributors you have, and who's more or less active. On GitHub, you can view this under "Graphs" -> "Contributors." Right now, this graph only counts contributors who have committed to the default branch of the repository. +* **기여자 중 총 기여 수 및 커밋 수 :** 얼마나 많은 기여자가 있고, 누가 더 많이 또는 적게 활동 하는지를 알려줍니다. GitHub에서는 "Graphs"-> "Contributors"에서 볼 수 있습니다. 현재 이 그래프는 저장소의 기본 브랜치에 작성한 기여자만 계산합니다. ![Contributor graph](/assets/images/metrics/repo_contributors_specific_graph.png) -* **First time, casual, and repeat contributors:** Helps you track whether you're getting new contributors, and whether they come back. (Casual contributors are contributors with a low number of commits. Whether that's one commit, less than five commits, or something else is up to you.) Without new contributors, your project's community can become stagnant. +* **처음, 캐주얼, 그리고 다시 기여한 사람:** 새로운 참여자를 얻었는지 여부와 그들이 다시 돌아 왔는지 여부를 추적하는 데 도움이됩니다. (캐주얼 기여자는 커밋 수가 적고 커밋 수가 5회 이하이거나, 또 다른 기준은 당신에게 달려 있습니다.) 새로운 참여자가 없으면 프로젝트 커뮤니티가 정체 될 수 있습니다. -* **Number of open issues and open pull requests:** If these numbers get too high, you might need help with issue triaging and code reviews. +* **열린 이슈와 pull requests의 수:** 수치가 너무 높으면 이슈 검토 및 코드 검토에 대한 도움이 필요할 수 있습니다. -* **Number of _opened_ issues and _opened_ pull requests:** Opened issues means somebody cares enough about your project to open an issue. If that number increases over time, it suggests people are interested in your project. +* **_열렸던_ 이슈와 _열렸던_ pull requests의 수:** 열렸던 이슈는 누군가가 프로젝트의 이슈를 열어 신청할 수 있음을 의미합니다. 그 숫자가 시간이 지남에 따라 증가하면 사람들이 귀하의 프로젝트에 관심을 보였다고 나타낼수 있습니다. -* **Types of contributions:** For example, commits, fixing typos or bugs, or commenting on an issue. +* **기여 유형:** 예시로, 커밋, 오타 혹은 버그 수정, 또는 이슈에 답변하기가 있습니다. -As your project grows, your community may need more than just code from you. Responding to issues, reviewing code, and evangelizing your project are all important tasks in an open source project. +프로젝트가 성장함에 따라 커뮤니티는 단순한 코드 그 이상을 필요로 할 수 있습니다. 이슈에 대응하고, 코드를 검토하고, 프로젝트를 홍보하는 것은 오픈소스 프로젝트에서 중요한 작업입니다. -While the amount of time you spend on non-coding tasks will depend on the size and scope of your project, you should be prepared as a maintainer to address them yourself or find someone to help you. +비코딩 작업에 소요되는 시간은 프로젝트의 크기와 범위에 따라 다르지만, 직접 해결하거나 도움을 줄 담당자를 준비해야합니다. **If you're part of a company open sourcing a project,** make sure your project has the internal resources it needs to thrive. You'll want to identify who's responsible for maintaining the project after launch, and how you'll share those tasks with your community. @@ -107,26 +107,26 @@ If you need a dedicated budget or staffing for promotion, operations and maintai ### 다른 프로젝트에 기여하기 -If your goal is to learn how to collaborate with others or understand how open source works, consider contributing to an existing project. Start with a project that you already use and love. Contributing to a project can be as simple as fixing typos or updating documentation. +다른 사람들과 협력하거나 오픈소스가 어떻게 작동하는지 이해하는 방법을 배우는 것이 목표라면, 기존 프로젝트에 기여하는 것을 고려하십시오. 이미 사용하고 사랑하는 프로젝트부터 시작하십시오. 프로젝트에 기여하는 것은 오타를 수정하거나 문서를 업데이트하는 것만큼 간단합니다. If you're not sure how to get started as a contributor, check out our [How to Contribute to Open Source guide](../how-to-contribute/). ## 나만의 오픈소스 프로젝트 시작하기 -There is no perfect time to open source your work. You can open source an idea, a work in progress, or after years of being closed source. +당신의 일을 오픈 소스화 할 완벽한 시간은 없습니다. 아이디어, 진행중인 작업 또는 독점 소스가 된 이후의 수년이 지난 뒤에도 오픈소스화 할 수 있습니다. -Generally speaking, you should open source your project when you feel comfortable having others view, and give feedback on, your work. +일반적으로 말하면, 다른 사람들이 보기에 편하게 느끼고 프로젝트에 대한 피드백을 주려면 프로젝트를 오픈소스화 해야합니다. -No matter which stage you decide to open source your project, every project should include the following documentation: +프로젝트를 오픈소스로 결정한 단계에 관계없이, 모든 프로젝트에는 다음과 같은 문서가 포함되어야합니다: -* [Open source license](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) +* [오픈소스 라이선스](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) -* [Contributing guidelines](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +* [기여 가이드라인](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) * [Code of conduct](../code-of-conduct/) -As a maintainer, these components will help you communicate expectations, manage contributions, and protect everyone's legal rights (including your own). They significantly increase your chances of having a positive experience. +메인테이너는 이러한 구성 요소를 사용하여 기대를 전달하고, 기여를 관리하고, (자신의 권리를 포함한) 모든 사람의 법적 권리를 보호 할 수 있습니다. 그들은 긍정적인 경험을 가질 기회를 상당히 증가시킵니다. -If your project is on GitHub, putting these files in your root directory with the recommended filenames will help GitHub recognize and automatically surface them to your readers. +프로젝트가 GitHub에 있는 경우, 권장 파일 이름을 사용하여 이러한 파일을 루트 디렉토리에 저장하면 GitHub에서 해당 파일을 인식하여 자동으로 사용자에게 보여줍니다. ### 라이선스 선택하기 From bf2b326ed0d81cab51dd8fb37712a58539e1982f Mon Sep 17 00:00:00 2001 From: minwook Date: Tue, 9 Jan 2018 20:26:53 +0900 Subject: [PATCH 73/87] update translation --- _articles/ko-KR/starting-a-project.md | 40 +++++++++++++-------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/_articles/ko-KR/starting-a-project.md b/_articles/ko-KR/starting-a-project.md index b2f8ec3a190..5e089ae3080 100644 --- a/_articles/ko-KR/starting-a-project.md +++ b/_articles/ko-KR/starting-a-project.md @@ -22,7 +22,7 @@ related: ### "오픈소스"란 무엇을 의미합니까? -프로젝트가 오픈소스일 때,, that means **anybody can view, use, modify, and distribute your project for any purpose.** These permissions are enforced through [an open source license](https://opensource.org/licenses). +즉 **누구나 프로젝트를 보고, 사용하고, 수정하고, 배포 할 수 있습니다.** 이러한 권한은 [오픈소스 라이선스](https://opensource.org/licenses)를 통해 시행됩니다. 오픈소스는 채택의 장벽을 낮추어 아이디어가 빠르게 확산될 수 있기 때문에 강력합니다. @@ -51,7 +51,7 @@ related: * **채택과 재가공:** 오픈소스 프로젝트는 거의 모든 목적으로 누구나 사용할 수 있습니다. 사람들은 그것을 사용하여 다른 것을 만들 수도 있습니다. [WordPress](https://github.com/WordPress)를 예시로 들면, [b2](https://github.com/WordPress/book/blob/master/Content/Part%201/2-b2-cafelog.md)라는 기존 프로젝트의 포크로 시작되었습니다. -* **투명도:** 누구나 오픈소스 프로젝트에서 오류나 불일치를 검사 할 수 있습니다. 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). +* **투명도:** 누구나 오픈소스 프로젝트에서 오류나 불일치를 검사 할 수 있습니다. 투명성은 [불가리아](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)에서 다른 오픈소스 아이디어를 확인하십시오. @@ -75,11 +75,11 @@ related: ### 목표 설정하기 -목표는 어떤 일을 해야할 건지, 어떤 말을 하지 않을건지, 다른 사람들에게 도움이 필요한 곳을 파악하는 것에 도움이 될 수 있습니다. Start by asking yourself, _why am I open sourcing this project?_ +목표는 어떤 일을 해야할 건지, 어떤 말을 하지 않을건지, 다른 사람들에게 도움이 필요한 곳을 파악하는 것에 도움이 될 수 있습니다. 스스로에게 물어보십시오, _왜 내가 이 프로젝트를 오픈 소스로 만들었습니까?_ 이 질문에 대한 정답은 아무도 없습니다. 한 프로젝트에 대해 여러 가지 목표를 가질 수도 있고, 다른 목표를 가진 다른 프로젝트를 가질 수도 있습니다. -If your only goal is to show off your work, you may not even want contributions, and even say so in your README. On the other hand, if you do want contributors, you'll invest time into clear documentation and making newcomers feel welcome. +귀하의 유일한 목표가 귀하의 업무를 과시하는 것이라면, 귀하는 README에 기여를 원한다고 말할 수 없습니다. 다른 한편으로는, 기여자를 원한다면 명확한 문서화에 시간을 투자를 통해 신규 방문자가 환영받는다고 느끼게 될 것입니다. -Finally, a code of conduct helps set ground rules for behavior for your project's participants. This is especially valuable if you're launching an open source project for a community or company. A code of conduct empowers you to facilitate healthy, constructive community behavior, which will reduce your stress as a maintainer. +마지막으로, 행동강령은 프로젝트 참가자의 행동에 대한 기본 규칙을 설정하는 데 도움이 됩니다. 이는 커뮤니티나 회사를 위해 오픈소스 프로젝트를 시작하는 경우 특히 유용합니다. 행동강령은 건강하고 건설적인 커뮤니티 행동을 촉진하도록 권한을 부여하며, 이는 메인테이너로서의 스트레스를 감소시킵니다. -For more information, check out our [Code of Conduct guide](../code-of-conduct/). +자세한 정보를 확인하려면, [행동강령 가이드](../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](http://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. +오픈소스 라이선스와 마찬가지로 행동강령에 대한 새로운 기준도 있으므로, 사용자가 직접 작성할 필요는 없습니다. [Contributor Covenant](http://contributor-covenant.org/)는 Kubernetes, Rails 및 Swift를 포함하여 [40,000개 이상의 오픈소스 프로젝트](http://contributor-covenant.org/adopters/)에서 사용되는 행동 강령입니다. 어떤 텍스트를 사용하든 필요에 따라 행동강령을 시행 할 준비가 되어 있어야합니다. -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. +텍스트를 저장소의 CODE_OF_CONDUCT 파일에 직접 붙여 넣으십시오. 프로젝트의 루트 디렉토리에 파일을 보관하여 찾기 쉽도록 하고, README에서 링크를 연결하십시오. ## 프로젝트 네이밍 및 브랜딩 @@ -225,26 +228,26 @@ Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the ### 올바른 이름 고르기 -Pick a name that is easy to remember and, ideally, gives some idea of what the project does. For example: +기억하기 쉬운 이름을 골라야하며, 이상적으로 프로젝트가 하는 일에 대한 아이디어를 제공하십시오. 예시입니다: -* [Sentry](https://github.com/getsentry/sentry) monitors apps for crash reporting -* [Thin](https://github.com/macournoyer/thin) is a fast and simple Ruby web server +* [Sentry](https://github.com/getsentry/sentry)는 충돌보고를 위해 앱을 모니터링합니다 +* [Thin](https://github.com/macournoyer/thin)은 빠르고 간단한 Ruby 웹 서버입니다 -If you're building upon an existing project, using their name as a prefix can help clarify what your project does (ex. [node-fetch](https://github.com/bitinn/node-fetch) brings `window.fetch` to Node.js). +기존 프로젝트를 기반으로 하는 경우, 그 이름을 접두사로 사용하면 프로젝트가 수행하는 작업을 분명히 알 수 있습니다 (예시. [node-fetch](https://github.com/bitinn/node-fetch)는 Node.js에서 `window.fetch`를 가져옵니다). -Consider clarity above all. Puns are fun, but remember that some jokes might not translate to other cultures or people with different experiences from you. Some of your potential users might be company employees: you don't want to make them uncomfortable when they have to explain your project at work! +무엇보다 명확성을 고려하십시오. 농담은 재미 있지만, 일부 농담은 다른 문화나 다른 경험을 가진 사람들로 번역되지 않을 수도 있음을 기억하십시오. 잠재적인 사용자 중 일부는 회사 직원일 수 있습니다: 그들이 직장에서 당신의 프로젝트를 설명해야 할 때 불편하게 하고 싶지는 않습니다! ### 이름 충돌 방지하기 -[Check for open source projects with a similar name](http://ivantomic.com/projects/ospnc/), especially if you share the same language or ecosystem. If your name overlaps with a popular existing project, you might confuse your audience. +[비슷한 이름의 오픈소스 프로젝트가 있는지 확인하십시오](http://ivantomic.com/projects/ospnc/), 특히 동일한 언어 또는 같은 생태계를 공유하는 경우, 이름이 기존의 인기있는 프로젝트와 겹치면 잠재적인 고객을 혼동시킬 수 있습니다. -If you want a website, Twitter handle, or other properties to represent your project, make sure you can get the names you want. Ideally, [reserve those names now](https://instantdomainsearch.com/) for peace of mind, even if you don't intend to use them just yet. +웹 사이트, Twitter 핸들 또는 프로젝트를 나타내는 다른 속성을 원하면 원하는 이름을 가져올 수 있는지 확인하십시오. 이상적으로는, 아직 사용하지 않으려는 경우에도 마음의 평화를 위해 [지금 해당 이름을 예약하십시오](https://instantdomainsearch.com/). -Make sure that your project's name doesn't infringe upon any trademarks. A company might ask you to take down your project later on, or even take legal action against you. It's just not worth the risk. +프로젝트 이름이 상표를 침해하지 않는지 확인하십시오. 회사는 나중에 프로젝트를 중단하거나, 법적 조치를 취할 것을 요구할 수 있습니다. 위험 부담이 되지 않습니다. 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/). -Finally, do a quick Google search for your project name. Will people be able to easily find your project? Does something else appear in the search results that you wouldn't want them to see? +마지막으로, 프로젝트 이름에 대한 빠른 Google 검색을 수행하십시오. 사람들이 프로젝트를 쉽게 찾을 수 있습니까? 검색 결과에 표시하고 싶지 않은 것이 있습니까? ### 당신이 쓰는 방법(그리고 코드)은 당신의 브랜드에도 영향을 미칩니다! From a8fd69720f1a37eeb6128d0c6d142bd772f5b248 Mon Sep 17 00:00:00 2001 From: minwook Date: Tue, 9 Jan 2018 22:10:17 +0900 Subject: [PATCH 75/87] translated this file --- _articles/ko-KR/starting-a-project.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/_articles/ko-KR/starting-a-project.md b/_articles/ko-KR/starting-a-project.md index 73524bc7606..d747c542834 100644 --- a/_articles/ko-KR/starting-a-project.md +++ b/_articles/ko-KR/starting-a-project.md @@ -251,9 +251,9 @@ You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) ### 당신이 쓰는 방법(그리고 코드)은 당신의 브랜드에도 영향을 미칩니다! -Throughout the life of your project, you'll do a lot of writing: READMEs, tutorials, community documents, responding to issues, maybe even newsletters and mailing lists. +프로젝트가 진행되는 동안, 많은 글을 쓸 것입니다: README, 튜토리얼, 커뮤니티 문서, 이슈에 대한 회신, 뉴스레터 및 메일링 리스트 등. -Whether it's official documentation or a casual email, your writing style is part of your project's brand. Consider how you might come across to your audience and whether that is the tone you wish to convey. +그것이 공식적인 문서이건 캐주얼 이메일이건, 당신의 작문 스타일은 프로젝트의 브랜드의 일부입니다. 잠재 고객에게 도달하는 방법과 전달하려는 톤인지 여부를 고려하십시오. -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](http://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines. +단어 작성 방법 이외에도, 코딩 스타일이 프로젝트 브랜드의 일부가 될 수도 있습니다. [Angular](https://github.com/johnpapa/angular-styleguide)와 [jQuery](http://contribute.jquery.org/style-guide/js/)는 엄격한 코딩 스타일과 가이드 라인을 가진 프로젝트의 두 가지 예시입니다. -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. +프로젝트를 시작할 때 스타일 가이드를 작성할 필요가 없으며, 어쨌든 다른 코딩 스타일을 프로젝트에 통합하는 것을 즐긴다는 것을 알 수 있습니다. 그러나 글쓰기와 코딩 스타일이 다른 유형의 사람들을 끌어 모으거나 방해 할 수있는 방법을 예상해야합니다. 프로젝트의 가장 초기 단계는 보고자하는 선례를 설정할 기회입니다. ## 출시 전 체크리스트 From 9183cabb867e8a87b28c09065a62c8387bb4c4d5 Mon Sep 17 00:00:00 2001 From: minwook Date: Tue, 9 Jan 2018 22:13:16 +0900 Subject: [PATCH 76/87] Create CNAME --- CNAME | 1 + 1 file changed, 1 insertion(+) create mode 100644 CNAME diff --git a/CNAME b/CNAME new file mode 100644 index 00000000000..0cb97e277bb --- /dev/null +++ b/CNAME @@ -0,0 +1 @@ +ko.opensource.guide \ No newline at end of file From 5e53a41c2c7d8743a35b6b7fca66b8e69f011b5b Mon Sep 17 00:00:00 2001 From: minwook Date: Wed, 10 Jan 2018 23:08:27 +0900 Subject: [PATCH 77/87] update full locale --- CNAME | 2 +- _config.yml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/CNAME b/CNAME index 0cb97e277bb..8a97ebe7da6 100644 --- a/CNAME +++ b/CNAME @@ -1 +1 @@ -ko.opensource.guide \ No newline at end of file +ko-kr.opensource.guide \ No newline at end of file diff --git a/_config.yml b/_config.yml index 2e9f8ab6132..fa85a853b9e 100644 --- a/_config.yml +++ b/_config.yml @@ -10,7 +10,7 @@ translations: ko-KR: name: Korean - url: https://ko.opensource.guide + url: https://ko-kr.opensource.guide exclude: - bin From 1550ea3ef208e7749e887f75959f9d2d64f19c9b Mon Sep 17 00:00:00 2001 From: Mike McQuaid Date: Wed, 14 Feb 2018 09:22:01 +0000 Subject: [PATCH 78/87] Fix article-alt header This was misaligned. --- _layouts/article-alt.html | 2 +- assets/css/covers.scss | 4 ++++ 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/_layouts/article-alt.html b/_layouts/article-alt.html index 90daf114b9d..8e51078a893 100644 --- a/_layouts/article-alt.html +++ b/_layouts/article-alt.html @@ -4,7 +4,7 @@ {% include nav.html %} -
+

{{ page.title }}

{{ page.description }}

diff --git a/assets/css/covers.scss b/assets/css/covers.scss index e9385ac9d61..7576986c755 100644 --- a/assets/css/covers.scss +++ b/assets/css/covers.scss @@ -13,6 +13,10 @@ } } +.article-alt-header { + margin: -40px 0; +} + .guide-cover-img { height: 200px; From 4d34eb16b76705b72d4f327f43f38d1f0d224872 Mon Sep 17 00:00:00 2001 From: Mike McQuaid Date: Wed, 14 Feb 2018 09:22:24 +0000 Subject: [PATCH 79/87] js/locale: fix language switcher. Correctly handle switching from non-English to another non-English page. --- assets/js/locale.js | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/assets/js/locale.js b/assets/js/locale.js index 91c464286d6..88c7dca0b3b 100644 --- a/assets/js/locale.js +++ b/assets/js/locale.js @@ -5,10 +5,11 @@ $(document).ready(function() { }); function loadLanguage(lang) { + base_pathname = window.location.pathname.replace(/^\/[a-z]+([_-][a-z]+)?\//, "/") if (lang === "en") { - url = window.location.pathname.replace(/^\/[a-z]+([_-][a-z]+)?\//, "/") + url = base_pathname } else { - url = "/" + lang + window.location.pathname + url = "/" + lang + base_pathname } window.location.assign(url); } From 08ef04d964c1a8791b57dfefd8a24c17674eef8d Mon Sep 17 00:00:00 2001 From: Mike McQuaid Date: Thu, 15 Feb 2018 10:06:09 +0000 Subject: [PATCH 80/87] Update documentation Make various updates to reflect the current state of the project. --- CONTRIBUTING.md | 7 ++----- README.md | 10 ++-------- docs/new-guides.md | 28 ---------------------------- docs/roadmap.md | 22 ---------------------- 4 files changed, 4 insertions(+), 63 deletions(-) delete mode 100644 docs/new-guides.md delete mode 100644 docs/roadmap.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 76f630e901e..2fe312cdc0b 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -19,15 +19,12 @@ We've put together the following guidelines to help you figure out where you can 0. [Community](#community) ## Types of contributions we're looking for -First and foremost, this project is a forum to discuss open source best practices, then document them in a guide when we've found consensus. Your first contribution might be starting a new conversation, or adding to an existing conversation, around best practices. You can do so under [Issues](https://github.com/github/opensource.guide/issues). - -There are also many ways you can directly contribute to the guides (in descending order of need): +There are many ways you can directly contribute to the guides (in descending order of need): * Fix editorial inconsistencies or inaccuracies * Add stories, examples, or anecdotes that help illustrate a point * Revise language to be more approachable and friendly * [Translate guides into other languages](docs/translations.md) -* Propose a new guide ([here's how](./docs/new-guides.md)) Interested in making a contribution? Read on! @@ -64,7 +61,7 @@ Once you have that set up, run: ## Contribution review process -This repo is currently maintained by @nayafia and @bkeepers, who have commit access. They will likely review your contribution. If you haven't heard from anyone in 10 days, feel free to bump the thread or @-mention a maintainer to review your contribution. +This repo is currently maintained by @nayafia and @mikemcquaid, who have commit access. They will likely review your contribution. If you haven't heard from anyone in 10 days, feel free to bump the thread or @-mention a maintainer to review your contribution. ## Community diff --git a/README.md b/README.md index 45e746437fa..3dc3e2ef109 100644 --- a/README.md +++ b/README.md @@ -5,19 +5,13 @@ Open Source Guides (https://opensource.guide/) are a collection of resources for individuals, communities, and companies who want to learn how to run and contribute to an open source project. ## Background -The first set of Open Source Guides were created and curated by GitHub, along with input from outside community reviewers, but they are not exclusive to GitHub products. +Open Source Guides were created and are curated by GitHub, along with input from outside community reviewers, but they are not exclusive to GitHub products. One reason we started this project is because we felt that there weren't enough resources for people creating open source projects. Our goal is to aggregate community best practices, *not* what GitHub (or any other individual or entity) thinks is best. Therefore, we try to use examples and quotations from others to illustrate our points. -**Open Source Guides are a resource and a discussion forum.** One reason we started this project is because we felt that there weren't enough resources for people creating open source projects. We made these guides open source in hopes that you'll use this space to talk about best practices, then document them when you've found consensus. We'd like this to be a safe space to talk about what's hard, what's scary, and what's simply confusing about running open source projects. - -## Roadmap - -We've shared our vision and priorities for this project in our [roadmap](docs/roadmap.md). - ## Contributing -This site is powered by [Jekyll](https://jekyllrb.com/). Our goal is for this project to reflect community best practices, so we'd love your input! Got a question or an idea? Check out our [contributing guidelines](/CONTRIBUTING.md) for ways to offer feedback and contribute. +This site is powered by [Jekyll](https://jekyllrb.com/). Check out our [contributing guidelines](/CONTRIBUTING.md) for ways to offer feedback and contribute. ## Licenses diff --git a/docs/new-guides.md b/docs/new-guides.md deleted file mode 100644 index 1a3b85b6819..00000000000 --- a/docs/new-guides.md +++ /dev/null @@ -1,28 +0,0 @@ -# Proposing a new guide - -Thanks for your interest in suggesting a new Open Source Guide! Your suggestions help us decide what to work on next. - -## If you'd like to propose a new guide: - -1. **[Open an issue](https://github.com/github/opensource.guide/issues)** with your suggestion. Please explain: - * Why the topic is broadly useful to open source contributors - * Why it doesn't fit into an existing guide - * 3-5 bullets of expected sub-topics -2. We (likely @bkeepers or @nayafia) will label the issue ```new-guide``` and share feedback. - -At this point, we may decide the topic doesn't warrant a new guide and close the issue, or we may recommend adding the information to an existing guide. That's okay! All suggestions are welcomed contributions, because they help us understand what our community is thinking. - -## If we decide to move forward on a new guide, we will: - -- [ ] Label your issue ```research``` -- [ ] Collect existing community resources (links, blog posts, projects) on your issue. Everybody is welcome to contribute. - * What else has been written on this topic? - * What projects do this well? - * Who might be people with valuable experience that we should talk to? -- [ ] Open a PR with an outline for the new guide. Anyone is welcome to give feedback until we reach general consensus. -- [ ] Label your issue ```in progress``` - - [ ] Add the guide to our editorial schedule with estimated date for 1st draft completion - - [ ] Request assets from Design for illustrations, Twitter cards, and anything else needed -- [ ] Label your issue ```draft``` and update PR with the 1st draft. Anyone is welcome to give feedback. -- [ ] Make final edits and add estimated date for completion -- [ ] Release the new guide! 🎉 diff --git a/docs/roadmap.md b/docs/roadmap.md deleted file mode 100644 index ce4e808d10d..00000000000 --- a/docs/roadmap.md +++ /dev/null @@ -1,22 +0,0 @@ -# Roadmap - -Our vision for Open Source Guides is to provide a jumping off point for individuals, communities, and companies to sustainably embrace open source. - -### Q1 2017 - -We started by focusing on open source creators, because they play a critical role in growing healthy projects. Creators help set good examples for contributors and consumers of open source. We also noticed there were very few comprehensive resources aimed at helping creators. - -* [x] Create a first set of guides that help creators start and grow their own open source project -* [x] Make the guides public and release it as an open source project -* [x] Expand [Contributing to Open Source on GitHub](https://guides.github.com/activities/contributing-to-open-source/) to include community best practices for contributors, and move it to Open Source Guides -* [ ] Foster healthy community dynamics so the guides become a place to codify community best practices - -### Q2 2017 - -We'll improve upon existing content and start to focus on additional content for open source consumers and contributors. - -* [ ] Continue to improve the content for open source creators -* [ ] Improve guide discoverability for open source creators -* [ ] Expand the Open Source Guides to include content for open source consumers - -This is our current plan. As with everything in the Open Source Guides project, it is open to community feedback. From 3e343720f676e7a9c979a402ffe3727b605cddbb Mon Sep 17 00:00:00 2001 From: minwook-shin Date: Thu, 15 Feb 2018 21:21:20 +0900 Subject: [PATCH 81/87] fix wrong link --- _articles/ko/best-practices.md | 14 +++++++------- _articles/ko/building-community.md | 14 +++++++------- _articles/ko/code-of-conduct.md | 14 +++++++------- _articles/ko/finding-users.md | 14 +++++++------- _articles/ko/getting-paid.md | 13 +++++++------ _articles/ko/how-to-contribute.md | 16 ++++++++-------- _articles/ko/leadership-and-governance.md | 16 ++++++++-------- _articles/ko/legal.md | 20 ++++++++++---------- _articles/ko/metrics.md | 14 +++++++------- _articles/ko/starting-a-project.md | 20 ++++++++++---------- 10 files changed, 78 insertions(+), 77 deletions(-) diff --git a/_articles/ko/best-practices.md b/_articles/ko/best-practices.md index 83e9403f19a..81a4aa5783d 100644 --- a/_articles/ko/best-practices.md +++ b/_articles/ko/best-practices.md @@ -17,7 +17,7 @@ related: - leadership --- -## 메인테이너가 된다는 것은 무엇을 의미하나요? +## What does it mean to be a maintainer? 많은 사람들이 사용하는 오픈소스 프로젝트를 유지한다면, 적은 양으로 코딩하고 더 많은 이슈에 대응할 수 있습니다. @@ -25,7 +25,7 @@ related: 프로젝트를 유지하려면 코드 이상의 것을 요구합니다. 이러한 작업은 예상치 못한 경우가 많지만 성장하는 프로젝트와 마찬가지로 중요합니다. 우리는 진행 문서화에서 시작해서 커뮤니티 활용에 이르기까지 당신의 삶을 편하게 해주는 몇 가지 방법을 모아봤습니다. -## 진행과정을 문서화하기 +## Documenting your processes 글을 작성하는 것은 메인테이너가 할 수있는 가장 중요한 일 중 하나입니다. @@ -80,7 +80,7 @@ related: 그러면, 커뮤니티에 가입한 사람은 수년간 그 곳에 있었던 사람과 동일한 정보에 접근 할 수 있습니다. -## 아니오라고 말하는 것을 배우기 +## Learning to say no 당신이 글을 썼습니다. 이상적으로는 모든 사람이 당신의 문서를 읽을 것이지만, 실제로 이 지식이 존재한다는 것을 모르는 다른 사람들에게도 상기시켜야 할 것입니다. @@ -164,7 +164,7 @@ related: 누군가 당신의 프로젝트에 열성적이지만 약간의 수정이 필요하다면 인내심을 가집시다. 그들의 공헌이 프로젝트의 기대에 부합하지 않는 이유를 각 상황에서 분명하게 설명합니다. 발을 젖게하기 위해 _"좋은 첫 버그,"_라고 표시된 이슈와 같이 더 쉽거나 덜 모호한 작업을 가리키도록 하십시오. 시간이 있다면, 첫번째 기여를 통해 멘토링을 고려하거나 멘토를 기꺼이 도울 수 있는 다른 사람을 커뮤니티에서 찾을 수 있습니다. -## 커뮤니티 활용하기 +## Leverage your community 당신은 모든 것을 스스로 할 필요가 없습니다. 프로젝트 공동체가 존재합니다! 적극적으로 참여한 커뮤니티가 없는 경우에도 많은 사용자가 있는 경우, 일하도록 하십시오. @@ -211,7 +211,7 @@ related: > 프로젝트가 커지면 메인테이너는 새로운 코드를 어떻게 도입할 것인지 훨씬 보수적으로 판단해야합니다. 당신은 "아니오"라고 말하는 것이 좋지만 많은 사람들이 합법적인 필요를 가지고 있습니다. 따라서 도구가 대신 플랫폼으로 변환됩니다. -## 로봇을 가져오기 +## Bring in the robots 다른 사람들이 당신을 도울 수 있는 작업이 있는 것처럼, 인간도 할 일이 없어야합니다. 로봇은 당신의 친구입니다. 그것들을 사용하여 메인테이너로서의 삶을 더 쉽게 만듭니다. @@ -252,7 +252,7 @@ related: 어떤 도구를 사용해야하는지 잘 모르는 경우 다른 인기있는 프로젝트, 특히 같은 생태계에 있는 프로젝트를 살펴보십시오. 예를 들어, 다른 Node 모듈에 대한 기여 진행과정은 어떻게됩니까? 유사한 도구와 접근 방식을 사용하면 진행과정은 대상 기여자에게 더 익숙하게 됩니다. -## 멈추는것도 좋습니다 +## It's okay to hit pause 오픈소스 작업은 한 때 기쁨을 가져다주었습니다만. 어쩌면 이제는 회피하거나 죄책감을 느낄 수 있습니다. @@ -279,6 +279,6 @@ related: 휴식을 취하는 것은 방학기간이상 적용됩니다. 주말이나 근무 시간 중에 오픈소스 작업을 하고싶지 않다면, 그 계획을 다른 사람들에게 알려줌으로써 그들은 당신을 귀찮게하지 않을 것입니다. -## 먼저 자신을 돌보기! +## Take care of yourself first! 인기있는 프로젝트를 유지하려면 성장 초기 단계와는 다른 기술이 필요하지만 그다지 보람이 없습니다. 메인테이너로서, 소수의 사람들이 경험할 수 있는 수준에서 리더십과 개인 기술을 연습하게됩니다. 관리가 항상 쉬운 것은 아니지만, 명확한 경계를 설정하고 자신이 편안하게 느끼는 것을 취하는 것만으로도 행복하고 생기넘치며 생산적으로 머물 수 있습니다. diff --git a/_articles/ko/building-community.md b/_articles/ko/building-community.md index 95d60677793..5319f4ddc55 100644 --- a/_articles/ko/building-community.md +++ b/_articles/ko/building-community.md @@ -14,7 +14,7 @@ related: - coc --- -## 성공을 위한 프로젝트 설정하기 +## Setting your project up for success 프로젝트를 시작하고, 단어를 전파하면, 사람들이 그것을 확인하고 있습니다. 굉장합니다! 자, 어떻게 그들을 주변에 붙이게 할까요? @@ -106,11 +106,11 @@ related: 공공 커뮤니케이션에 대한 주목할만한 예외로는: 1) 보안 문제와 2) 민감한 행동 규범 위반이 있습니다. 사람들이 이러한 문제를 개인적으로 보고할 수 있는 방법을 항상 마련해야합니다. 개인 이메일을 사용하지 않으려면 전용 이메일 주소를 설정하십시오. -## 커뮤니티 성장하기 +## Growing your community 커뮤니티는 매우 강력합니다. 그 힘은 어떻게 사용하는지에 따라 축복이나 저주가 될 수 있습니다. 프로젝트 공동체가 성장함에 따라, 그것이 파괴가 아닌 건설의 힘이 될 수 있도록 돕는 방법이 있습니다. -### 나쁜 배우를 용서하지 말기 +### Don't tolerate bad actors 모든 인기있는 프로젝트는 필연적으로 커뮤니티를 돕기보다는, 해를 입는 사람들도 끌어 들일 것입니다. 그들은 불필요한 논쟁을 시작하거나, 사소한 기능을 말다툼하거나, 다른 사람들을 괴롭힐 수 있습니다. @@ -147,7 +147,7 @@ CONTRIBUTING 파일에서 새 참여자에게 시작 방법을 명시하십시 > Rubinius를 사용해 주셔서 감사드립니다. 이 프로젝트는 사랑의 노동이며, 버그를 포착하고 성능을 개선하며, 문서화에 도움이 되는 모든 사용자에게 감사드립니다. 모든 기여는 의미가 있으므로, 참여해 주셔서 감사합니다. 말하지면, 우리가 귀하의 문제를 성공적으로 해결할 수 있도록 따라야 할 몇 가지 지침이 있습니다. -### 당신의 프로젝트의 소유권 공유하기 +### Share ownership of your project -## 충돌 해결하기 +## Resolving conflicts 프로젝트의 초기 단계에서, 중요한 결정을 내리는 것은 쉽습니다. 당신이 무언가를 하고 싶을 때, 그것을 하도록합니다. @@ -197,7 +197,7 @@ CONTRIBUTING 파일에서 새 참여자에게 시작 방법을 명시하십시 귀하의 커뮤니티가 어려운 이슈로 어려움을 겪을 때, 기분이 좋아질 수 있습니다. 사람들은 화가 나거나 좌절감을 느껴 다른 사람이나 당신이 다른 사람에게 행복을 가져갈 수 있습니다. -메인테이너로서의 당신의 임무는 이러한 상황이 악화되는 것을 막는 것입니다. 주제에 대해 강한 의견을 갖고 있다고해도, 시합에 뛰어 들고 의견을 피하는 대신 메인테이너 또는 진행자의 입장을 취하십시오. 누군가가 불친절하거나 대화를 독점한다면, 토론을 시민적이고 생산적으로 유지하기 위해 [즉시 행동하십시오](../ building-community / # dont-tolerate-bad-actors). +메인테이너로서의 당신의 임무는 이러한 상황이 악화되는 것을 막는 것입니다. 주제에 대해 강한 의견을 갖고 있다고해도, 시합에 뛰어 들고 의견을 피하는 대신 메인테이너 또는 진행자의 입장을 취하십시오. 누군가가 불친절하거나 대화를 독점한다면, 토론을 시민적이고 생산적으로 유지하기 위해 [즉시 행동하십시오](../building-community/#dont-tolerate-bad-actors). -또한 유료 작업을 통해 여러 계층의 사람들이 의미있는 기여를 할 수 있습니다. 어떤 사람들은 현재 재무 상태, 부채, 또는 가족 또는 다른 보살필 의무를 다하지않고 오픈소스 프로젝트에 시간을 보낼 여력이 없습니다. 즉, 세상은 자신의 시간을 자원봉사할 여력이없는 재능있는 사람들에게서 기여를 결코 볼 수 없다는 것을 의미합니다. @ashryden이 [설명한대로](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community) 윤리적 함의가 있습니다. 이미 인생에 여유가 있는 사람들에게 치우친다는 것은, 자원 봉사자들의 기여에 기초하여 추가적인 이점을 얻는 반면, 자원봉사를 할 수 없는 사람들에게는 나중에 기회를 얻지 못하여, 더더욱 오픈소스의 다양성이 부족해집니다. +또한 유료 작업을 통해 여러 계층의 사람들이 의미있는 기여를 할 수 있습니다. 어떤 사람들은 현재 재무 상태, 부채, 또는 가족 또는 다른 보살필 의무를 다하지않고 오픈소스 프로젝트에 시간을 보낼 여력이 없습니다. 즉, 세상은 자신의 시간을 자원봉사할 여력이없는 재능있는 사람들에게서 기여를 결코 볼 수 없다는 것을 의미합니다. @ashedryden이 [설명한대로](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community) 윤리적 함의가 있습니다. 이미 인생에 여유가 있는 사람들에게 치우친다는 것은, 자원 봉사자들의 기여에 기초하여 추가적인 이점을 얻는 반면, 자원봉사를 할 수 없는 사람들에게는 나중에 기회를 얻지 못하여, 더더욱 오픈소스의 다양성이 부족해집니다. -## 실험적이고 포기하지 말기 +## Experiment and don't give up 오픈소스 프로젝트, 비영리 단체, 소프트웨어 스타트업 등 많은 돈을 모으는 것은 쉽지 않습니다. 대부분의 경우 창의력을 발휘해야합니다. 어떻게 돈을 받고, 연구를 하고, 재밌는 사람의 신발에 몸을 두는지를 확인하면 자금 지원에 대한 설득력있는 사례를 구축하는 데 도움이됩니다. > diff --git a/_articles/ko/how-to-contribute.md b/_articles/ko/how-to-contribute.md index 7e3f651f6f5..227190766a6 100644 --- a/_articles/ko/how-to-contribute.md +++ b/_articles/ko/how-to-contribute.md @@ -17,7 +17,7 @@ related: - building --- -## 왜 오픈소스에 기여 하나요? +## Why contribute to open source? -## 이러한 리더십 역할을 어떻게 공식화할 수 있습니까? +## How do I formalize these leadership roles? 리더십 역할을 공식화하면 사람들이 소유권을 느끼게되고 도움이 필요한 다른 커뮤니티 회원에게도 도움이 됩니다. @@ -84,7 +84,7 @@ related: 마지막으로, 프로젝트가 GitHub에 있을 경우, 프로젝트를 개인 계정에서 조직으로 옮기고 적어도 하나의 백업 관리자를 추가하는 것을 고려하십시오. [GitHub Organizations](https://help.github.com/articles/creating-a-new-organization-account/)에서는 권한 및 여러 저장소를 쉽게 관리하고 [공유 소유권](../building-community/#share-ownership-of-your-project)을 통해 프로젝트의 유산을 보호합니다. -## 누군가에게 언제 커밋 권한을 부여해야합니까? +## When should I give someone commit access? 어떤 사람들은 당신이 기여하는 모든 사람에게 헌신적으로 접근해야한다고 생각합니다. 그렇게하면 더 많은 사람들이 프로젝트 소유권을 느낄 수 있습니다. @@ -100,7 +100,7 @@ related:

-## 오픈소스 프로젝트의 공통적인 관리 구조에는 어떤 것들이 있습니까? +## What are some of the common governance structures for open source projects? 오픈소스 프로젝트와 관련된 세 가지 공통 관리 구조가 있습니다. @@ -116,7 +116,7 @@ related: * [실력주의 모델 템플릿](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) * [Node.js의 자유주의 기여 정책](https://medium.com/the-javascript-collection/healthy-open-source-967fa8be7951#.m9ht26e79) -## 프로젝트를 시작할 때 거버넌스 문서가 필요합니까? +## Do I need governance docs when I launch my project? 프로젝트 관리 방식을 작성할 적절한 시기는 없지만, 커뮤니티 역학 관계가 성립했다면 정의하는 것이 훨씬 쉽습니다. 오픈소스 관리에 대한 가장 좋은(그리고 가장 어려운) 부분은 그것이 커뮤니티에 의해 형성된다는 것입니다! @@ -132,7 +132,7 @@ related:

-## 기업 직원이 기여를 제출하기 시작하면 어떻게됩니까? +## What happens if corporate employees start submitting contributions? 성공적인 오픈소스 프로젝트는 많은 사람들과 회사에서 사용되며, 결국 일부 회사는 궁극적으로 프로젝트에 묶인 수익원을 갖게 될 것입니다. 예를 들어, 회사는 상용 서비스에서 프로젝트 코드를 하나의 구성 요소로 사용할 수 있습니다. @@ -144,7 +144,7 @@ related: 다른 사람들과 마찬가지로, 상업적 동기를 부여받은 개발자는 기여도의 질과 양을 통해 프로젝트에 영향력을 행사합니다. 분명히 일정한 시간동안 돈을 지불한 개발자는 돈을 지불하지 않은 사람보다 더 많은 것을 할 수 있지만, 괜찮습니다. 지불은 누군가가 얼마나 많은 영향을 줄 수 있는지에 대한 많은 요인 중 하나일뿐입니다. 사람들이 그 기여를 할 수 있게 해주는 외적 요인이 아닌, 기여에 초점을 맞춘 프로젝트 토론을 유지하십시오. -## 내 프로젝트를 지원하기 위해 법인이 필요합니까? +## Do I need a legal entity to support my project? 돈을 처리할 필요가 없다면, 오픈소스 프로젝트를 지원하는 법인이 필요하지 않습니다. diff --git a/_articles/ko/legal.md b/_articles/ko/legal.md index f7eacc277c2..4dae83fccee 100644 --- a/_articles/ko/legal.md +++ b/_articles/ko/legal.md @@ -18,11 +18,11 @@ related: - leadership --- -## 오픈소스의 법적 영향에 대한 이해 +## Understanding the legal implications of open source -세계와 창의적인 작업을 공유하는 것은 흥미롭고 보람있는 경험이 될 수 있습니다. 그것은 또한 당신이 모른다고 걱정해야한다는 것을 합법적이라는 걸로 의미 할 수 있습니다. 고맙게도 처음부터 다시 시작할 필요는 없습니다. 귀하의 법적 요구 사항이 있습니다. (이 내용을 파기전에, [면책조항](../notices/)을 읽으십시오.) +세계와 창의적인 작업을 공유하는 것은 흥미롭고 보람있는 경험이 될 수 있습니다. 그것은 또한 당신이 모른다고 걱정해야한다는 것을 합법적이라는 걸로 의미 할 수 있습니다. 고맙게도 처음부터 다시 시작할 필요는 없습니다. 귀하의 법적 요구 사항이 있습니다. (이 내용을 파기전에, [면책조항](/notices/)을 읽으십시오.) -## 왜 사람들은 오픈소스의 법적 측면에 많은 관심을 보이고 있습니까? +## Why do people care so much about the legal side of open source? 물어봤다는건 다행입니다! 창의적인 작업(작성, 그래픽 또는 코드)을 할 때, 그 저작물은 기본적으로 독점적인 저작권하에 있습니다. 즉, 법은 귀하의 저작물의 작성자로서 다른 사람들이 할 수 있는 것에 대해 귀하가 말하고있는 것으로 간주합니다. @@ -34,7 +34,7 @@ related: 마지막으로, 프로젝트는 사용자가 알지 못하는 라이선스 요구 사항과의 종속성을 가질 수 있습니다. 프로젝트의 커뮤니티 또는 고용주의 정책에 따라 프로젝트에서 특정 오픈소스 라이선스를 사용해야 할 수도 있습니다. 아래에서 이러한 상황을 다룰 것입니다. -## 공개 GitHub 프로젝트는 오픈소스입니까? +## Are public GitHub projects open source? 깃허브에서 [새로운 프로젝트를 만들려고](https://help.github.com/articles/creating-a-new-repository/) 할 때, **비공개** 또는 **공개** 저장소로 만드는 옵션을 선택할 수 있습니다. @@ -44,7 +44,7 @@ related: 다른 사람들이 프로젝트를 사용, 복사, 수정 또는 다시 사용할 수 있게하려면, 오픈소스 라이선스를 포함해야합니다. 예를 들어, 권한을 부여하지 않는다는 조건에서는 공개적으로 GitHub 프로젝트의 일부를 코드에 명시적으로 사용할 수는 없습니다. -## 내 프로젝트를 보호하기 위해 필요한 DR;TL 제공해주기. +## Just give me the TL;DR on what I need to protect my project. 운이 좋았습니다. 오늘날 오픈소스 라이선스는 표준화되어 있고 사용하기 쉽기 때문입니다. 기존 라이선스를 프로젝트에 직접 복사하여 붙여넣을 수 있습니다. @@ -60,7 +60,7 @@ GitHub에서 새로운 프로젝트를 만들 때, [라이선스를 추가할

-## 내 프로젝트에 적합한 오픈소스 라이선스는 무엇입니까? +## Which open source license is appropriate for my project? 빈 슬레이트에서 시작한다면, [MIT 라이선스](https://choosealicense.com/licenses/mit/)를 잘못 읽는 것은 어렵습니다. 짧고 이해하기 쉽기 때문에 저작권 고지를 포함하여 라이선스 사본을 보관하는 한 누구나 아무 것도 할 수 없습니다. 필요한 경우 다른 라이선스로 프로젝트를 릴리스 할 수 있습니다. @@ -80,7 +80,7 @@ GitHub에서 새로운 프로젝트를 만들 때, [라이선스를 추가할 GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는 옵션이 제공됩니다. 위에서 언급한 라이선스 중 하나를 포함하면 GitHub 프로젝트가 오픈소스로 됩니다. 다른 옵션을 보려면 [choosealicense.com](https://choosealicense.com)에서 [소프트웨어가 아닌 프로젝트](https://choosealicense.com/non-software/)에 적합한 라이선스를 찾으십시오. -## 프로젝트 라이선스를 변경하려면 어떻게해야합니까? +## What if I want to change the license of my project? 대부분의 프로젝트는 라이선스를 변경할 필요가 없습니다. 그러나 때때로 상황이 바뀝니다. @@ -94,7 +94,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)로 지정합니다. @@ -119,7 +119,7 @@ GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는 프로젝트에 기여자 계약을 추가로 사용해야하는 경우 기여자 산만을 최소화하기 위해 [CLA 어시스턴트](https://github.com/cla-assistant/cla-assistant)와 같은 통합 사용을 고려하십시오. -## 우리 회사의 법률 팀은 무엇을 알아야합니까? +## What does my company's legal team need to know? 오픈소스 프로젝트를 회사 직원으로 공개하는 경우, 먼저 법률팀이 오픈소스 프로젝트임을 알고 있어야합니다. @@ -162,4 +162,4 @@ Longer term, your legal team can do more to help the company get more from its i * **특허:** 귀사는 회원사의 주요 오픈소스 프로젝트 사용을 보호하거나 다른 대체 특허 라이센싱을 모색하기 위해, [Open Invention Network](http://www.openinventionnetwork.com/)에 가입 할 수 있습니다. -* **가버넌스:** 특히 프로젝트를 [회사 외부의 법인](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project)으로 옮기는 것이 이치에 맞을 경우에 할 수 있습니다. \ No newline at end of file +* **가버넌스:** 특히 프로젝트를 [회사 외부의 법인](../leadership-and-governance/#do-i-need-a-legal-entity-to-support-my-project)으로 옮기는 것이 이치에 맞을 경우에 할 수 있습니다. diff --git a/_articles/ko/metrics.md b/_articles/ko/metrics.md index 2e258917017..d735ced210b 100644 --- a/_articles/ko/metrics.md +++ b/_articles/ko/metrics.md @@ -16,7 +16,7 @@ related: - best-practices --- -## 왜 무엇이든지 측정합니까? +## Why measure anything? 데이터를 현명하게 사용하면, 오픈소스 메인테이너로서 더 나은 의사 결정을 내릴 수 있습니다. @@ -37,7 +37,7 @@ related: If you _are_ interested in understanding your project on a deeper level, read on for ways to analyze your project's activity. -## 발견 +## Discovery 누구든지 프로젝트를 사용하거나 기여할 수 있게 하기전에, 이것이 존재 하는 지를 알아야합니다. 자신에게 물어보십시오: _이 프로젝트를 찾는 사람들입니까?_ @@ -57,7 +57,7 @@ If you _are_ interested in understanding your project on a deeper level, read on [특정 장소에서 검색 가능성을 추적](https://opensource.com/business/16/6/pirate-metrics) 할 수도 있습니다: 예를 들어, Google 페이지랭크, 프로젝트 웹 사이트의 추천 트래픽 또는 다른 오픈소스 프로젝트 또는 웹 사이트의 추천을 포함 할 수 있습니다. -## 사용 +## Usage 사람들은 우리가 인터넷이라고 부르는 이 거칠고 미친 일로 프로젝트를 찾고 있습니다. 이상적으로는, 프로젝트를 보았을 때 뭔가 할 것을 강요 당할 것입니다. 두 번째 질문은 다음과 같습니다: _이 프로젝트를 사용하는 사람들입니까?_ @@ -80,7 +80,7 @@ npm 또는 RubyGems.org와 같은 패키지 관리자를 사용하여 프로젝 사람들이 프로젝트를 사용하고 있다는 것을 알게되면, 사람들이 프로젝트를 통해 무엇을 하고 있는지 파악하려고 할 수 있습니다. 그들은 당신의 코드를 포크하고 기능을 추가함으로써 그것을 구축하고 있습니까? 그들은 과학이나 비즈니스를 위해 그것을 사용하고 있습니까? -## 보유 +## Retention 사람들이 프로젝트를 찾고 있으며 프로젝트를 사용하고 있습니다. 다음 질문은 스스로에게 물어볼 것입니다: _이 프로젝트에 다시 기여한 사람들입니까?_ @@ -110,7 +110,7 @@ npm 또는 RubyGems.org와 같은 패키지 관리자를 사용하여 프로젝

-## 메인테이너 활동 +## Maintainer activity 마지막으로, 프로젝트 메인테이너가 받은 기여 분량을 처리 할 수 있는지 확인하여 루프를 닫으십시오. 자신에게 묻고 싶은 마지막 질문은 다음과 같습니다: _나는 (또는 우리가) 우리 커뮤니티에 반응하고 있습니까?_ @@ -127,6 +127,6 @@ npm 또는 RubyGems.org와 같은 패키지 관리자를 사용하여 프로젝 * 부실 이슈가 종결 되는지 여부 * pull request을 병합하는 평균 시간 -## 📊 를 사용하여 사람들에 대해 알아보기 +## Use 📊 to learn about people -측정 기준을 이해하면 적극적으로 성장하는 오픈소스 프로젝트를 구축하는 데 도움이됩니다. 대시 보드의 모든 측정치를 추적하지 않더라도, 위의 프레임워크를 사용하여 프로젝트가 성공하는 데 도움이 되는 동작 유형에 주의를 기울이십시오. \ No newline at end of file +측정 기준을 이해하면 적극적으로 성장하는 오픈소스 프로젝트를 구축하는 데 도움이됩니다. 대시 보드의 모든 측정치를 추적하지 않더라도, 위의 프레임워크를 사용하여 프로젝트가 성공하는 데 도움이 되는 동작 유형에 주의를 기울이십시오. diff --git a/_articles/ko/starting-a-project.md b/_articles/ko/starting-a-project.md index 4e62169b220..e88716fdf1a 100644 --- a/_articles/ko/starting-a-project.md +++ b/_articles/ko/starting-a-project.md @@ -16,7 +16,7 @@ related: - building --- -## 오픈소스의 "목적" 및 "이유" +## The "what" and "why" of open source 따라서 오픈소스를 시작하는 것에 대해 생각하고 있습니까? 축하합니다! 세상은 당신의 기여를 높이 평가합니다. 오픈소스란 무엇이며, 왜 사람들이 그렇게하는지 이야기해 봅시다. @@ -63,7 +63,7 @@ related: 결과적으로 대부분의 오픈소스 프로젝트는 무료이지만, "무료"는 오픈소스 정의의 일부가 아닙니다. 오픈소스의 공식적인 정의를 계속 준수하면서 이중 라이선스 또는 제한된 기능을 통해 간접적으로 오픈소스 프로젝트를 청구할 수있는 방법이 있습니다. -## 나 자신의 오픈소스 프로젝트를 시작해야합니까? +## Should I launch my own open source project? 짧은 결과는 예입니다. 결과에 관계없이, 자신의 프로젝트를 시작하는 것이 오픈소스의 작동 방식을 배우기위한 훌륭한 방법이기 때문입니다. @@ -111,7 +111,7 @@ related: 기여자로 시작하는 방법을 모르는 경우에는, [오픈소스에 기여하는 방법 가이드](../how-to-contribute/)를 확인하십시오. -## 나만의 오픈소스 프로젝트 시작하기 +## Launching your own open source project 당신의 일을 오픈 소스화 할 완벽한 시간은 없습니다. 아이디어, 진행중인 작업 또는 독점 소스가 된 이후의 수년이 지난 뒤에도 오픈소스화 할 수 있습니다. @@ -142,7 +142,7 @@ GitHub에서 새 프로젝트를 만들면, 라이선스를 선택할 수 있는 만약 오픈소스 프로젝트를 관리하는 법적 측면에 대해 다른 질문이나 우려 사항이 있으시면, [이 내용은 귀하를 대상으로합니다](../legal/). -### README 쓰기 +### Writing a README README는 프로젝트 사용 방법을 설명하는 것 이상을 수행합니다. 또한 프로젝트가 중요한 이유와 사용자가 수행 할 수 있는 작업에 대해 설명합니다. @@ -169,7 +169,7 @@ README를 사용하여 기여를 처리하는 방법, 프로젝트의 목표가 README 파일을 루트 디렉토리에 포함시키면, GitHub가 자동으로 저장소 홈페이지에 표시합니다. -### 기여 가이드라인 쓰기 +### Writing your contributing guidelines CONTRIBUTING 파일은 잠재 고객에게 프로젝트 참여 방법을 알려줍니다. 예를 들어 다음 정보를 포함 할 수 있습니다: @@ -222,7 +222,7 @@ README에 CONTRIBUTING 파일을 링크하면 더 많은 사람들이 볼 수 텍스트를 저장소의 CODE_OF_CONDUCT 파일에 직접 붙여 넣으십시오. 프로젝트의 루트 디렉토리에 파일을 보관하여 찾기 쉽도록 하고, README에서 링크를 연결하십시오. -## 프로젝트 네이밍 및 브랜딩 +## Naming and branding your project 브랜딩은 화려한 로고 또는 재미있는 프로젝트 이름 이상입니다. 그것은 당신의 프로젝트에 대해 어떻게 이야기하고, 당신의 메시지를 가지고 도달했는지에 관한 것입니다. @@ -237,7 +237,7 @@ README에 CONTRIBUTING 파일을 링크하면 더 많은 사람들이 볼 수 무엇보다 명확성을 고려하십시오. 농담은 재미 있지만, 일부 농담은 다른 문화나 다른 경험을 가진 사람들로 번역되지 않을 수도 있음을 기억하십시오. 잠재적인 사용자 중 일부는 회사 직원일 수 있습니다: 그들이 직장에서 당신의 프로젝트를 설명해야 할 때 불편하게 하고 싶지는 않습니다! -### 이름 충돌 방지하기 +### Avoiding name conflicts [비슷한 이름의 오픈소스 프로젝트가 있는지 확인하십시오](http://ivantomic.com/projects/ospnc/), 특히 동일한 언어 또는 같은 생태계를 공유하는 경우, 이름이 기존의 인기있는 프로젝트와 겹치면 잠재적인 고객을 혼동시킬 수 있습니다. @@ -269,7 +269,7 @@ You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) 프로젝트를 시작할 때 스타일 가이드를 작성할 필요가 없으며, 어쨌든 다른 코딩 스타일을 프로젝트에 통합하는 것을 즐긴다는 것을 알 수 있습니다. 그러나 글쓰기와 코딩 스타일이 다른 유형의 사람들을 끌어 모으거나 방해 할 수있는 방법을 예상해야합니다. 프로젝트의 가장 초기 단계는 보고자하는 선례를 설정할 기회입니다. -## 출시 전 체크리스트 +## Your pre-launch checklist 프로젝트를 오픈소스로 할 준비가 되셨습니까? 다음은 도움이 되는 체크리스트입니다. 모든 체크박스를 확인하시겠습니까? 이제 갈 준비가 되었습니다! ["공개"를 클릭](https://help.github.com/articles/making-a-private-repository-public/)하고 등 뒤에서 몸을 담그십시오. @@ -367,6 +367,6 @@ You can check the [WIPO Global Brand Database](http://www.wipo.int/branddb/en/)
-## 훌륭합니다! +## You did it! -첫번째 프로젝트를 오픈소스화한 것을 축하합니다. 결과에 관계없이 공개적으로 일하는 것은 공동체에 대한 선물입니다. 모든 커밋, 설명 및 pull request을 풀어 쓰면, 자신과 다른 사람들이 배우고 성장할 수 있는 기회가 만들어집니다. \ No newline at end of file +첫번째 프로젝트를 오픈소스화한 것을 축하합니다. 결과에 관계없이 공개적으로 일하는 것은 공동체에 대한 선물입니다. 모든 커밋, 설명 및 pull request을 풀어 쓰면, 자신과 다른 사람들이 배우고 성장할 수 있는 기회가 만들어집니다. From 9a13670b5bc68cccb3c900d5d5b1911560da39d0 Mon Sep 17 00:00:00 2001 From: minwook-shin Date: Thu, 15 Feb 2018 21:30:57 +0900 Subject: [PATCH 82/87] fix warning text --- _articles/ko/best-practices.md | 4 ---- _articles/ko/building-community.md | 2 +- _articles/ko/getting-paid.md | 1 + _articles/ko/metrics.md | 2 +- 4 files changed, 3 insertions(+), 6 deletions(-) diff --git a/_articles/ko/best-practices.md b/_articles/ko/best-practices.md index 81a4aa5783d..a345cdb7451 100644 --- a/_articles/ko/best-practices.md +++ b/_articles/ko/best-practices.md @@ -90,7 +90,6 @@ related: 당신이 메인테이너로서 만날 수 있는 많은 상황에 적용됩니다: 범위에 맞지 않는 기능 요청, 토론을 이탈한 사람, 불필요한 다른 일을 하는 사람들. - ### 친근한 대화를 유지하기 가장 중요한 장소 중 하나인 No라고 말하면서 이슈와 pull request 대기열을 가져옵니다. 프로젝트 메인테이너로서, 여러분은 받아들이기를 원치않는 제안을 필연적으로 받게됩니다. @@ -157,7 +156,6 @@ related: 때로는 아니오라고 말하면 잠재적 기여자가 결정을 뒤집거나 비판할 수 있습니다. 그들의 행동이 적대적으로 된다면, [상황을 완화시키기 위한 조치를 취하십시오.](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) 또는 건설적으로 협업하지 않으려는 경우 커뮤니티 자체에서 제거할 수도 있습니다. - ### 멘토십을 포옹하기 커뮤니티의 누군가가 프로젝트 표준에 맞지 않는 기여를 정기적으로 제출할 수도 있습니다. 각자 당사자가 거절을 반복해서 거치는 것은 좌절할 수 있습니다. @@ -176,7 +174,6 @@ related: @lmccart가 프로젝트 [p5.js](https://github.com/processing/p5.js?files=1)에서 발견한대로 [프로젝트 소유권 공유](../building-community/#share-ownership-of-your-project)를 권장하면 자신의 작업량을 크게 줄일 수 있습니다. -