From c9d4d88004a3759e9120db97e57725e2066a9d41 Mon Sep 17 00:00:00 2001 From: Yuichi Tanaka Date: Mon, 27 Aug 2018 20:57:21 +0900 Subject: [PATCH 0001/1478] Add ja.yml --- _data/locales/ja.yml | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 _data/locales/ja.yml diff --git a/_data/locales/ja.yml b/_data/locales/ja.yml new file mode 100644 index 0000000000..370ad0db63 --- /dev/null +++ b/_data/locales/ja.yml @@ -0,0 +1,31 @@ +en: + locale_name: 日本語 + nav: + about: このサイトについて + contribute: 貢献する + index: + lead: オープンソーススフとウェアはあなたのような人々によって作られています。プロジェクトを立ち上げて大きくしていく方法を学びましょう。 + opensourcefriday: 今日は金曜日です！少しの時間を、あなたが使っていて愛着を持っているソフトウェアへの貢献に使いましょう。 + article: + table_of_contents: 目次 + back_to_all_guides: すべてのガイドに戻る + related_guides: 関連するガイド + footer: + contribute: + heading: 貢献する + description: 提案を行いたいですか？このコンテンツはオープンソースです。改善の手助けをして下さい。 + button: 貢献する + subscribe: + heading: 情報を受け取る + description: GitHubの最新のオープンソースのコツや資料を受け取りましょう。 + label: Emailアドレス + button: 購読する + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[github] と [friends] による [love] のこもった [code]" + # Label for code octicon + code_label: コード + # Label for love octicon + love_label: 愛 + # Label for the contributors link + friends_label: 友達 From afb5346e71f8615e63721d098be8a86d51683c11 Mon Sep 17 00:00:00 2001 From: Yuichi Tanaka Date: Mon, 27 Aug 2018 20:59:37 +0900 Subject: [PATCH 0002/1478] Add ja.html --- ja.html | 4 ++++ 1 file changed, 4 insertions(+) create mode 100644 ja.html diff --git a/ja.html b/ja.html new file mode 100644 index 0000000000..4f17d28583 --- /dev/null +++ b/ja.html @@ -0,0 +1,4 @@ +--- +layout: index +lang: ja +--- From 6b630b67fa96c256bde4c56952c886beb4f4ff28 Mon Sep 17 00:00:00 2001 From: Yuichi Tanaka Date: Mon, 27 Aug 2018 21:04:22 +0900 Subject: [PATCH 0003/1478] Add ja directory for articles. But have not translated yet. --- _articles/ja/best-practices.md | 283 ++++++++++++ _articles/ja/building-community.md | 279 ++++++++++++ _articles/ja/code-of-conduct.md | 120 +++++ _articles/ja/finding-users.md | 163 +++++++ _articles/ja/getting-paid.md | 193 ++++++++ _articles/ja/how-to-contribute.md | 528 ++++++++++++++++++++++ _articles/ja/leadership-and-governance.md | 164 +++++++ _articles/ja/legal.md | 165 +++++++ _articles/ja/metrics.md | 132 ++++++ _articles/ja/starting-a-project.md | 369 +++++++++++++++ 10 files changed, 2396 insertions(+) create mode 100644 _articles/ja/best-practices.md create mode 100644 _articles/ja/building-community.md create mode 100644 _articles/ja/code-of-conduct.md create mode 100644 _articles/ja/finding-users.md create mode 100644 _articles/ja/getting-paid.md create mode 100644 _articles/ja/how-to-contribute.md create mode 100644 _articles/ja/leadership-and-governance.md create mode 100644 _articles/ja/legal.md create mode 100644 _articles/ja/metrics.md create mode 100644 _articles/ja/starting-a-project.md diff --git a/_articles/ja/best-practices.md b/_articles/ja/best-practices.md new file mode 100644 index 0000000000..06ae4c5a0f --- /dev/null +++ b/_articles/ja/best-practices.md @@ -0,0 +1,283 @@ +--- +lang: en +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. + +Remember to keep your documentation up-to-date. If you're not able to always do this, delete your outdated documentation or indicate it is outdated so contributors know updates are welcome. + +### 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 (_for example, "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 (_for example, "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 issue,"_ 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). + + + +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](https://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. @TalAter made a [Choose Your Own Adventure guide](https://www.talater.com/open-source-templates/#/) to help you write your issue and PR templates. + +To manage your email notifications, you can set up [email filters](https://github.com/blog/2203-email-updates-about-your-own-activity) to organize by priority. + +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](https://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/ja/building-community.md b/_articles/ja/building-community.md new file mode 100644 index 0000000000..6c1806cf7d --- /dev/null +++ b/_articles/ja/building-community.md @@ -0,0 +1,279 @@ +--- +lang: en +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://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/): + +![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 issue"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) make it easy for someone new to your project to quickly scan your issues and get started. + +Finally, use your documentation to make people feel welcome at every step of the way. + +You will never interact with most people who land on your project. There may be contributions you didn't receive because somebody felt intimidated or didn't know where to get started. Even a few kind words can keep someone from leaving your project in frustration. + +For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts [its contributing guide](https://github.com/rubinius/rubinius/blob/master/.github/contributing.md): + +> 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](https://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](https://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/ja/code-of-conduct.md b/_articles/ja/code-of-conduct.md new file mode 100644 index 0000000000..a92e75e781 --- /dev/null +++ b/_articles/ja/code-of-conduct.md @@ -0,0 +1,120 @@ +--- +lang: en +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" + your-responsibilities-as-a-maintainer: "Your responsibilities as a maintainer" +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](https://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/ja/finding-users.md b/_articles/ja/finding-users.md new file mode 100644 index 0000000000..01257b120f --- /dev/null +++ b/_articles/ja/finding-users.md @@ -0,0 +1,163 @@ +--- +lang: en +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. Instead of hoping others will find and use your open source project, you have to spread the word 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 help you communicate your project's significance. + +Remember that people get involved as users, and eventually become contributors, because your project solves a problem for them. As you think about your project's message and value, try to view them through the lens of what _users and contributors_ 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"](https://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. These outlets also give your project's growing community a place to convene. + +If you don't wish to set up outlets for your project yet, promote your own Twitter or GitHub handle in everything you do. Promoting your Twitter or GitHub handle will let people know how to contact you or follow your work. If you speak at a meetup or event, make sure that your contact information is included in your bio or slides. + + + +**Consider creating a website for your project.** A website makes your project friendlier and easier to navigate, especially when it's paired with clear documentation and tutorials. Having a website also suggests that your project is active which will make your audience feel more comfortable using it. Provide 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](https://stackoverflow.com/), [Reddit](https://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 anyone can easily promote a project online, there will be a lot of noise. To stand out from the crowd, give people context for who you are and not just what you want. + +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. Promoting and launching your project takes 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 to audiences. They're a great way to reach an engaged audience and build deeper human connections, especially if you are interested in reaching developers. + +If you're [new to public speaking](http://speaking.io/), start by finding a local meetup that's related to the language or ecosystem of your project. + + + +If you'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 to tailor your talk for attendees and increase your chances of being accepted to speak at the conference. You can often get a sense of your audience by looking at a conference's 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' projects will help you build a positive reputation. Being an active member in the open source community will help people have context for your work and be more likely to pay attention to and share your project. Developing relationships with other open source projects can even lead to official partnerships. + + + +It's never too early, or too late, to start building your reputation. Even if you've launched your own project already, continue to look for ways to help others. + +There is no overnight solution to building an audience. Gaining the trust and respect of others takes time, and building your reputation never ends. + + + +## Keep at it! + +It may take 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 hoping that your project will spontaneously gain popularity. Be patient, and keep sharing your work with those who appreciate it. diff --git a/_articles/ja/getting-paid.md b/_articles/ja/getting-paid.md new file mode 100644 index 0000000000..8976f26f1e --- /dev/null +++ b/_articles/ja/getting-paid.md @@ -0,0 +1,193 @@ +--- +lang: en +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](https://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](https://paypal.github.io/), have websites that highlight their involvement in open source +* [Rackspace](https://www.rackspace.com/en-us) published its [open source contribution policy](https://blog.rackspace.com/rackspaces-policy-on-contributing-to-open-source/) for employees + +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. + +Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example: + +* @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/) +* @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) + +Finally, sometimes open source projects put bounties on issues that you might consider helping with. + +* @ConnorChristie was able to get paid for [helping](https://github.com/MARKETProtocol/MARKET.js/issues/14) @MARKETProtocol work on their javascript library [through a bounty on gitcoin](https://gitcoin.co/). +* @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://beta.bounties.network/bounty/v1/134). + +## 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/ja/how-to-contribute.md b/_articles/ja/how-to-contribute.md new file mode 100644 index 0000000000..35ad736ae6 --- /dev/null +++ b/_articles/ja/how-to-contribute.md @@ -0,0 +1,528 @@ +--- +lang: en +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](https://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 (for example, _"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](https://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 (for example, community, vision or 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 (for example, a typo, a broken link or an 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 (for example, "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 walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey. + +## 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/ja/leadership-and-governance.md b/_articles/ja/leadership-and-governance.md new file mode 100644 index 0000000000..e278526cc0 --- /dev/null +++ b/_articles/ja/leadership-and-governance.md @@ -0,0 +1,164 @@ +--- +lang: en +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 (for example, 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](https://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.org/), the Python package manager, and the [Node.js Foundation](https://nodejs.org/en/foundation/) helps support [Express.js](https://expressjs.com/), a Node-based framework. diff --git a/_articles/ja/legal.md b/_articles/ja/legal.md new file mode 100644 index 0000000000..2844339916 --- /dev/null +++ b/_articles/ja/legal.md @@ -0,0 +1,165 @@ +--- +lang: en +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, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so. + +## 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/search?platforms=NPM). +* **Do you want your project to appeal to large businesses?** A large business will likely want an express patent license from all contributors. In this case, [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) has you (and them) covered. +* **Do you want your project to appeal to contributors who do not want their contributions to be used in closed source software?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) or (if they also do not wish to contribute to closed source services) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) will go over well. + +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.linuxfoundation.org/blog/2015/06/why-companies-that-use-open-source-need-a-compliance-program/) can prevent headaches, product delays, and lawsuits. + + + +* **Patents:** Your company may wish to join the [Open Invention Network](https://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/ja/metrics.md b/_articles/ja/metrics.md new file mode 100644 index 0000000000..080b3eea9d --- /dev/null +++ b/_articles/ja/metrics.md @@ -0,0 +1,132 @@ +--- +lang: en +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 "Insights", 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 "Insights" -> "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/ja/starting-a-project.md b/_articles/ja/starting-a-project.md new file mode 100644 index 0000000000..c651cc40bc --- /dev/null +++ b/_articles/ja/starting-a-project.md @@ -0,0 +1,369 @@ +--- +lang: en +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](https://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"](https://mozillascience.github.io/working-open-workshop/contributing/). + +Link to your CONTRIBUTING file from your README, so more people see it. If you [place the CONTRIBUTING file in your project's repository](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub will automatically link to your file when a contributor creates an issue or opens a pull request. + +![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](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters), including Kubernetes, Rails, and Swift. No matter which text you use, you should be prepared to enforce your code of conduct when necessary. + +Paste the text directly into a CODE_OF_CONDUCT file in your repository. Keep the file in your project's root directory so it's easy to find, and link to it from your README. + +## 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 (for example, [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](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines. + +It isn't necessary to write a style guide for your project when you're just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see. + +## 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 76588201dbd72e1b418f0beef951848aed25f019 Mon Sep 17 00:00:00 2001 From: Yuichi Tanaka Date: Tue, 28 Aug 2018 10:03:46 +0900 Subject: [PATCH 0004/1478] Translate the first section --- _articles/ja/how-to-contribute.md | 50 +++++++++++++++---------------- 1 file changed, 25 insertions(+), 25 deletions(-) diff --git a/_articles/ja/how-to-contribute.md b/_articles/ja/how-to-contribute.md index 35ad736ae6..79ba829ff5 100644 --- a/_articles/ja/how-to-contribute.md +++ b/_articles/ja/how-to-contribute.md @@ -1,15 +1,15 @@ --- -lang: en -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. +lang: ja +title: オープンソースに貢献する方法 +description: オープンソースに貢献したいですか？オープンソースへの貢献のためのガイドです。初めての人だけでなくベテランも対象です。 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" + why-contribute-to-open-source: "オープンソースに貢献する理由は？" + what-it-means-to-contribute: "貢献するということが意味するもの" + orienting-yourself-to-a-new-project: "新しいプロジェクトに順応しよう" + finding-a-project-to-contribute-to: "貢献するプロジェクトを見つけよう" + how-to-submit-a-contribution: "貢献を提出する方法" + what-happens-after-you-submit-a-contribution: "貢献を提出した後に起こること" order: 1 image: /assets/images/cards/contribute.png related: @@ -17,43 +17,43 @@ related: - 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. +あなたが練習したいと思っていることが、コーディングであれ、UIデザインやグラフィックデザイン、文章を書くこと、組織を作ることであれ、オープンソースプロジェクトにはあなたのためのタスクがあります。 -### 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 From 9e205795bd4487485b753ac41d06b1a28a2305f0 Mon Sep 17 00:00:00 2001 From: Yuichi Tanaka Date: Tue, 28 Aug 2018 13:52:04 +0900 Subject: [PATCH 0005/1478] Fix Japanese local name in the setting file --- _data/locales/ja.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_data/locales/ja.yml b/_data/locales/ja.yml index 370ad0db63..fb3a5720bf 100644 --- a/_data/locales/ja.yml +++ b/_data/locales/ja.yml @@ -1,4 +1,4 @@ -en: +ja: locale_name: 日本語 nav: about: このサイトについて From b37318d9f2e83b0f3cab9dcc82d801b40189c0f6 Mon Sep 17 00:00:00 2001 From: Yuichi Tanaka Date: Tue, 28 Aug 2018 15:55:01 +0900 Subject: [PATCH 0006/1478] Start to translate section 2 --- _articles/ja/how-to-contribute.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/_articles/ja/how-to-contribute.md b/_articles/ja/how-to-contribute.md index 79ba829ff5..259ec217c2 100644 --- a/_articles/ja/how-to-contribute.md +++ b/_articles/ja/how-to-contribute.md @@ -55,25 +55,25 @@ related: あなたは何もオープンソースに生涯に渡って常に参加し続ける必要があるわけではありません。ウェブサイトでタイポを見つけて、直してほしいと思ったことはありませんか？オープンソースプロジェクトでは、あなたがそれをできるのです。オープンソースによって、人々は人生や世界をどう経験するかが自分自身のものだと感じられることを助けてくれます。そしてその事自体が大きな喜びとなるのです。 -## 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! +オープンソースへの貢献についてのよくある勘違いとしては、あなたはコードを書く必要があるというものです。実際、それはしばしばプロジェクトの中で最も[無視されるか見落とされている部分](https://github.com/blog/2195-the-shape-of-open-source)です。この種の貢献を行うことによってプロジェクトに対して _非常に大きな_ 助けとなります。 -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. +たとえコードを書くことが好きであったとしても、他の種類の貢献はプロジェクトに関わり、他のコミュニティメンバーに会う良いやり方です。このような関係を作ることはそのプロジェクトの他の部分に関わる人と仕事をする機会を与えてくれます。 @@ -256,7 +256,7 @@ README에 CONTRIBUTING 파일을 링크하면 더 많은 사람들이 읽게 할 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), ["지속 가능한 오픈소스"](http://writing.jan.io/2015/11/20/sustainable-open-source.html) +— @janl on [CouchDB](https://github.com/apache/couchdb), ["Sustainable Open Source”](http://writing.jan.io/2015/11/20/sustainable-open-source.html)

From a8742fae76912b1db415dc0764c05677c853f224 Mon Sep 17 00:00:00 2001 From: YJ Cho Date: Fri, 7 Dec 2018 23:26:46 +0000 Subject: [PATCH 0070/1478] Improve translation on the article 5, section 1~2 --- _articles/ko/best-practices.md | 88 +++++++++++++++++----------------- 1 file changed, 45 insertions(+), 43 deletions(-) diff --git a/_articles/ko/best-practices.md b/_articles/ko/best-practices.md index 92b479e5fb..8d44cdd7fe 100644 --- a/_articles/ko/best-practices.md +++ b/_articles/ko/best-practices.md @@ -1,15 +1,15 @@ --- lang: ko -title: 메인테이너를 위한 모범 사례 -description: 문서화 과정에서 커뮤니티 활용에 이르기까지 오픈소스 메인테이너로서 여러분의 삶을 편하게 만들어줍니다. +title: 관리자의 모범 +description: 문서화 과정에서 커뮤니티 활용에 이르기까지 오픈소스 관리자로서 여러분의 삶을 더 편하게 만들어 줍니다. class: best-practices toc: what-does-it-mean-to-be-a-maintainer: "메인테이너가 된다는 것은 무엇을 의미하나요?" - documenting-your-processes: "진행과정을 문서화하기" - learning-to-say-no: "아니오라고 말하는 것을 배우기" + documenting-your-processes: "프로세스 문서화하기" + 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: @@ -17,80 +17,82 @@ related: - leadership --- -## What does it mean to be a maintainer? +## 관리자라는 직책이란 -많은 사람들이 사용하는 오픈소스 프로젝트를 유지한다면, 적은 양으로 코딩하고 더 많은 이슈에 대응할 수 있습니다. +여러분이 많은 사람들이 사용하는 오픈소스 프로젝트를 관리하고 있다면, 점점 코딩은 덜 하고 이슈에 더 많이 반응하고 있다는 것을 알아차렸을 것입니다. -프로젝트 초기 단계에서 새로운 아이디어를 실험하고 원하는 것을 기반으로 의사 결정을 내리고 있습니다. 프로젝트의 인기가 높아짐에 따라 사용자와 기여자들과 더 잘 일할 수 있습니다. +프로젝트의 초기 단계에서, 여러분은 새로운 아이디어를 실험하고 여러분이 원하는 것을 바탕으로 결정을 내리고 있습니다. 프로젝트가 인기를 끌면서 여러분은 사용자 및 기여자들과 더 많은 일을 하게 될 것입니다. -프로젝트를 유지하려면 코드 이상의 것을 요구합니다. 이러한 작업은 예상치 못한 경우가 많지만 성장하는 프로젝트와 마찬가지로 중요합니다. 우리는 진행 문서화에서 시작해서 커뮤니티 활용에 이르기까지 당신의 삶을 편하게 해주는 몇 가지 방법을 모아봤습니다. +프로젝트 유지에는 코드 이상의 것이 필요합니다. 종종 예상치 못한 과제가 주어지기도 하지만 성장하는 프로젝트에게 이는 중요한 일입니다. 프로세스를 문서화하는 것에서부터 커뮤니티를 활용하는 것까지 여러분의 삶을 더 쉽게 만들 수 있는 몇 가지 방법을 모아 보았습니다. -## Documenting your processes +## 프로세스 문서화하기 -글을 작성하는 것은 메인테이너가 할 수있는 가장 중요한 일 중 하나입니다. +기록해두는 것은 여러분이 관리자로서 할 수 있는 가장 중요한 일 중 하나입니다. -문서는 자신의 생각을 분명히 할 뿐만 아니라, 다른 사람들이 물어보기도 전에 필요하거나 기대하는 것을 이해하도록 도와줍니다. +문서화는 여러분의 생각을 분명히 할 뿐만 아니라 여러분이 필요로 하거나 기대하는 것을 사람들이 직접 물어보지 않고도 알 수 있게 합니다. -글을 쓰게되면 무언가 범위에 맞지 않을 때 아무 말도 달지 않게됩니다. 또한 사람들이 쉽게 참여하게 도움을 줍니다. 다만 누가 프로젝트를 읽고 사용하는지 알 수는 없습니다. +문서화를 해 두면 여러분의 의도에 맞지 않는 의견을 기각하기 더 쉬워집니다. 또한 사람들이 프로젝트에 참여하기 더 쉽게 만듭니다. 어떤 사람들이 여러분의 프로젝트를 보거나 사용하고 있는지 모르니까요. -전체 단락을 사용하지 않더라도, 글 머리 기호라도 적어둔다면 아에 작성하지 않는 것보다는 좋습니다. +모든 항목에 대해 작성하지 않아도 괜찮습니다. 주요 항목에 대해 적어두는 것이 아무 것도 적어놓지 않는 것보다는 낫습니다. -### 프로젝트의 비전을 써내려가기 +여려분의 문서를 항상 최신으로 유지할 수 있도록 노력하세요. 항상 업데이트하기 어렵다면 오래된 문서를 지우거나 'outdated'로 표시해서 기여자들의 업데이트를 환영한다고 알리세요. -먼저 프로젝트의 목표를 써내려갑니다. README에 추가하거나, VISION이라 불리는 별도의 파일을 작성하십시오. 프로젝트 로드맵과 같이 도움이 될 수 있는 다른 인위적인 결과물이 있는 경우, 이를 공개 할 수도 있습니다. +### 프로젝트의 비전을 서술하세요 -명확하고, 문서화된 비전을 가지고 있으면 집중력을 유지하고 다른 기여자로부터 "scope creep"를 피할 수 있습니다. +프로젝트의 목표를 이야기하는 것부터 시작하세요. 이를 README 파일 또는 새로운 VISION 파일에 추가하세요. 프로젝트 로드맵 등 도움이 될만한 자료가 더 있다면 그것도 게시하세요. -예를 들어, @lord는 프로젝트 비전을 가짐으로써 시간을 보낼 요청을 파악하는 데 도움이 된다는 것을 발견했습니다. 새로운 메인테이너인 그는 [Slate](https://github.com/lord/slate)에 대한 첫번째 기능 요청을 받았을 때 프로젝트의 범위를 고수하지 않은 것을 후회했습니다. +명료하고 문서화된 비전은 여러분을 집중할 수 있게 하고, 사람들의 기여로부터 생길 수 있는 'scope creep'을 피할 수 있도록 해줍니다. + +예를 들어 @lord는 프로젝트 비전을 가지면 어떤 요구에 시간을 투자해야 하는지 파악하는 데 도움이 된다는 사실을 깨달았습니다. 새로운 관리자로서의 그는 [Slate](https://github.com/lord/slate)의 첫 기능 요청을 받았을 때 프로젝트의 본 목적에 집중하지 않았던 것을 아쉽게 생각했습니다. -### 생각을 소통하기 +### 기대하는 바를 전달하세요 -규칙은 신경을 쓸 수록 더 쓰일 수 있습니다. 때로는 다른 사람들의 행동을 감시하거나 모든 재미를 없애는 것처럼 느껴질 수도 있습니다. +규칙을 나열하는 것은 머리 아픈 일입니다. 가끔 여러분이 사람들의 행동에 간섭하거나 재미를 없애는 것이 아닌가 하는 생각이 들 수도 있습니다. -그러나 공정하게 작성되고 시행되면, 좋은 규칙은 메인테이너에게 힘을 줍니다. 그것들은 하고 싶지 않은 일을 하도록 끌리지 못하게 합니다. +그러나 공정하게 제정되고 시행되는 좋은 규칙은 관리자에게 제어력을 부여합니다. 하고 싶지 않은 일에 억지로 끌려들어가지 않게 해줍니다. -프로젝트를 직접 경험하는 대부분의 사람들은 메인테이너가 겪는 상황에 대해 알지 못합니다. 그들은 그것에 대해 일하기 위해 돈을 받는다고 가정할 지도 모릅니다, 특히 그들이 정기적으로 사용하고 의존하는 것들이 대부분입니다. 하지만 메인테이너는 어쩌다 한번에 프로젝트에다가 많은 시간을 할애하지만, 이제는 새로운 직업이나 가족 구성원으로인해 바빠졌습니다. +여러분의 프로젝트를 찾아오는 대부분의 사람들은 여러분이나 여러분의 환경에 대해 아무것도 알지 못합니다. 프로젝트에 의지하며 꾸준히 사용하는 사람들은 여러분이 그 프로젝트에서 작업하면서 보수를 받는다고 추측할지도 모릅니다. 언젠가는 프로젝트에 많은 시간을 쏟아부을 수 있었어도 이제는 새 직장이나 가족 구성원으로 정신없을 수도 있습니다. -이 모든 것은 완벽하게 괜찮습니다! 다른 사람들이 그것에 대해 알고 있는지 확인하시기 바랍니다. +전부 괜찮습니다! 대신 사람들에게 그렇다는 사실을 알리세요. -당신의 프로젝트를 아르바이트로 유지하거나 순수하게 자원 봉사로 진행하는 경우, 당신이 가진 시간에 대해 솔직하게 말하십시오. 이것은 프로젝트가 요구하는 시간, 또는 다른 사람들이 당신의 개발에 소비하기를 원하는 시간과 같지 않습니다. +프로젝트 관리를 아르바이트식 혹은 자발적으로 하고 있다면 여러분이 가진 시간에 대해 솔직해지세요. 프로젝트에 투자해야 한다고 여러분이 생각하는 시간과, 사람들이 여러분이 프로젝트에 투자하기를 원하는 시간과는 다릅니다. -다음과 같은 몇 가지 규칙을 적어 두는 것이 좋습니다: +아래와 같은 규칙은 정해 두는 편이 좋습니다. -* 기여를 검토하고 수락하는 방법 (_검사가 필요한가요? 이슈 템플릿?_) -* 당신이 수락할 기여 유형 (_코드의 특정 부분에 대해서만 도움을 원하십니까?_) -* 후속 조치가 필요한 순간 (_ex. "7일 이내에 관리자로부터 응답을 받을 수 있습니다. 그때까지 아무 것도 듣지 못했다면 쓰레드에 핑을 보내세요."_) -* 프로젝트에 할애하는 시간 (_ex. "이 프로젝트에 일주일 중 약 5시간만 할애하고 있습니다."_) +* 기여를 검토하고 받아들이는 방식 (_테스트를 수행해야 하나요? 정해진 이슈 템플릿이 있나요?_) +* 여러분이 받아들이고자 하는 기여 유형 (_코드의 일부분에만 기여를 받고 싶은가요?_) +* 피드백까지 예상되는 시간 (_ex. "일주일 안에는 관리자의 답변을 받으실 수 있을 것입니다. 그때까지 소식이 없다면 주저 말고 스레드에서 관리자를 호출해주세요" 등._) +* 여러분이 프로젝트에 투자하는 시간 (_ex. "저희는 이 프로젝트에 일주일에 약 5시간만을 할애하고 있습니다" 등._) -[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)는 메인테이너와 기여자를 위한 기본 원칙이 있는 프로젝트의 몇 가지 예시입니다. +[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)는 관리자와 기여자를 위한 행동 원칙을 가진 프로젝트의 예시입니다. -### 열린 소통을 유지하기 +### 열린 소통을 유지하세요 -상호 작용을 문서화하는 걸 잊지 마십시오. 가능한 모든 곳에서 프로젝트 공개에 대한 의사 소통을 유지하십시오. 누군가가 개인적으로 연락하여 기능 요청 또는 지원 필요성에 대해 토론하려고하면, 정중하게 메일링 리스트 또는 이슈 트래커와 같은 공개 의사 소통 채널로 안내합니다. +다양한 토의나 질답을 문서화하는 것을 잊지 마세요. 가능하면 어디에서든 여러분의 프로젝트에 대한 이야기는 공개적으로 하는 것이 좋습니다. 누군가 기능이나 지원 요청을 하기 위해 사적으로 연락한다면, 정중하게 메일링 리스트 혹은 이슈 트래커 등의 공개된 채널로 안내하세요. -다른 메인테이너와 만나거나, 비공개로 중요한 결정을 내릴 경우, 또는 메모를 게시하는 경우에도 마찬가지로, 공개적으로 문서에 기록하십시오. +다른 관리자와 만나거나, 공개하기 어려운 중요한 결정을 내린다면 여러분의 메모 정도라고 해도 내용은 공개적으로 게시하세요. -그러면, 커뮤니티에 가입한 사람은 수년간 그 곳에 있었던 사람과 동일한 정보에 접근 할 수 있습니다. +그러면 여러분의 프로젝트에 막 찾아온 사람도 몇 년간 있었던 사람과 같은 양의 정보를 획득할 수 있습니다. -## Learning to say no +## 거절하는 법 배우기 -당신이 글을 썼습니다. 이상적으로는 모든 사람이 당신의 문서를 읽을 것이지만, 실제로 이 지식이 존재한다는 것을 모르는 다른 사람들에게도 상기시켜야 할 것입니다. +필요한 것들을 문서화했나요? 모두가 문서를 읽는다면 이상적이겠지만 현실은 그렇지 않습니다. 사람들에게 그런 문서가 있다는 사실을 알려주어야 합니다. -그러나 모든 것을 적어둔다면, 규칙을 집행해야 할 상황일때 평범한 상황으로 복귀하는 것에 도움이 됩니다. +그러나 모든 것을 기록하면 규칙을 적용해야 할 때 객관적으로 상황을 해결할 수 있습니다. -아니오라고 말하는 것은 재미없지만, _"기여가 이 프로젝트의 기준과 일치하지 않습니다."_ 는 _"전 당신의 기여가 싫어요"_ 보다 개인적인 느낌이 들었습니다. +거절하는 것은 썩 유쾌한 일이 아닙니다. 하지만 _"당신의 기여는 프로젝트 기준에 맞지 않아요."_가 _"당신의 기여가 마음에 들지 않네요."_보다는 덜 감정적으로 느껴집니다. -당신이 메인테이너로서 만날 수 있는 많은 상황에 적용됩니다: 범위에 맞지 않는 기능 요청, 토론을 이탈한 사람, 불필요한 다른 일을 하는 사람들. +관리자로서, 본 목적에 맞지 않는 기능 요청, 토론과 관련 없는 발언, 불필요한 작업 등 거절이나 제지가 필요한 많은 상황을 맞닥뜨릴 것입니다. -### 친근한 대화를 유지하기 +### 친절한 태도를 유지하세요 가장 중요한 장소 중 하나인 No라고 말하면서 이슈와 pull request 대기열을 가져옵니다. 프로젝트 메인테이너로서, 여러분은 받아들이기를 원치않는 제안을 필연적으로 받게됩니다. @@ -162,7 +164,7 @@ related: 누군가 당신의 프로젝트에 열성적이지만 약간의 수정이 필요하다면 인내심을 가집시다. 그들의 공헌이 프로젝트의 기대에 부합하지 않는 이유를 각 상황에서 분명하게 설명합니다. 발을 젖게하기 위해 _"좋은 첫 버그,"_라고 표시된 이슈와 같이 더 쉽거나 덜 모호한 작업을 가리키도록 하십시오. 시간이 있다면, 첫번째 기여를 통해 멘토링을 고려하거나 멘토를 기꺼이 도울 수 있는 다른 사람을 커뮤니티에서 찾을 수 있습니다. -## Leverage your community +## 커뮤니티 활용하기 당신은 모든 것을 스스로 할 필요가 없습니다. 프로젝트 공동체가 존재합니다! 적극적으로 참여한 커뮤니티가 없는 경우에도 많은 사용자가 있는 경우, 일하도록 하십시오. @@ -248,7 +250,7 @@ related: 어떤 도구를 사용해야하는지 잘 모르는 경우 다른 인기있는 프로젝트, 특히 같은 생태계에 있는 프로젝트를 살펴보십시오. 예를 들어, 다른 Node 모듈에 대한 기여 진행과정은 어떻게됩니까? 유사한 도구와 접근 방식을 사용하면 진행과정은 대상 기여자에게 더 익숙하게 됩니다. -## It's okay to hit pause +## 잠시 멈춰도 괜찮습니다 오픈소스 작업은 한 때 기쁨을 가져다주었습니다만. 어쩌면 이제는 회피하거나 죄책감을 느낄 수 있습니다. From 032088ef40c456725bd45b51772777adaa9364d2 Mon Sep 17 00:00:00 2001 From: Yuichi Tanaka Date: Thu, 20 Dec 2018 15:55:05 +0900 Subject: [PATCH 0071/1478] Keep translating Chapter 3 at building community article --- _articles/ja/building-community.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/_articles/ja/building-community.md b/_articles/ja/building-community.md index b0d63b18cf..020338d833 100644 --- a/_articles/ja/building-community.md +++ b/_articles/ja/building-community.md @@ -215,7 +215,7 @@ CONTRIBUTINGファイルに、新しいコントリビュータにどのよう READMEは[単なる手順書以上のものです](../starting-a-project/#READMEを書く)。そこにはあなたのゴールやロードマップについて書く場所でもあるのです。もし人々がある特定の機能のメリットについて議論しすぎているのであれば、READMEを見返してプロジェクトのより高レベルのビジョンについて話すことが助けとなるかもしれません。READMEに注力することは、会話を個人から切り離し、生産的な議論を行うことに繋がります。 -### Focus on the journey, not the destination +### 向かう先ではなく、その過程に集中しよう 大きな決定を行う際に投票を用いるプロジェクトもあります。一見して賢明に見えますが、投票はお互いの声を聞き、心配事を解決することよりも、答えを出す事に重きをおいてしまいます。 @@ -227,15 +227,15 @@ READMEは[単なる手順書以上のものです](../starting-a-project/#README -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 From e732059db64eae907393599ffd283cf722ea83bf Mon Sep 17 00:00:00 2001 From: Yuichi Tanaka Date: Thu, 20 Dec 2018 16:41:59 +0900 Subject: [PATCH 0072/1478] Make tests pass --- _articles/ja/building-community.md | 9 ++++----- _articles/ja/finding-users.md | 2 +- _articles/ja/getting-paid.md | 2 +- _articles/ja/leadership-and-governance.md | 2 +- 4 files changed, 7 insertions(+), 8 deletions(-) diff --git a/_articles/ja/building-community.md b/_articles/ja/building-community.md index 020338d833..bcbfbd88dd 100644 --- a/_articles/ja/building-community.md +++ b/_articles/ja/building-community.md @@ -30,7 +30,7 @@ related: まずはドキュメントから始めましょう： -* **あなたのプロジェクトを使いやすくしましょう** [親切なREADME](../starting-a-project/#READMEを書く) とわかりやすいコードの例によって、あなたのプロジェクトを初めて見る人が使い始めやすくなります。 +* **あなたのプロジェクトを使いやすくしましょう** [親切なREADME](../starting-a-project/#readmeを書く) とわかりやすいコードの例によって、あなたのプロジェクトを初めて見る人が使い始めやすくなります。 * **貢献の仕方をわかりやすく説明しましょう**。その際、[CONTRIBUTINGファイルを使い](../starting-a-project/#貢献のガイドラインを書く)、イシューの状態を最新に保ちましょう。 [GitHubの2017 Open Source Survey](http://opensourcesurvey.org/2017/)では、未完成であったり混乱するドキュメントはオープンソースプロジェクトのユーザーにとって最大の問題である事が示されています。良いドキュメントによって人々をあなたのプロジェクトに招き入れるのです。結果として、イシューやプルリクエストを登録する人が出てきます。こういったやり取りを、ファネルを下がってもらう機会として利用しましょう。 @@ -120,14 +120,13 @@ related: avatar 実のところ、協力的なコミュニティを持つことが鍵となります。私は、同僚や、親切なインターネット上の見知らぬ人、気さくなIRCチャンネルの助けが無ければ、この仕事を達成することはできなかったでしょう。そうでない状況に甘んじてはいけません。バカを甘んじて受け入れてはいけません。

-— @karissa, ["How to Run a FOSS Project"](https://karissa.github.io/post/okf-de) +— @karissa, ["How to Run a FOSS Project"](https://okdistribute.xyz/post/okf-de)

プロジェクトの些末な点について議論することが日常的になってしまうと、あなたを含む人々が重要なタスクに集中することから気が逸れてしまいます。あなたのプロジェクトを初めてみた人もこういった議論を見て、参加したくないと思うかもしれません。 -もしあなたのプロジェクトで有害な行動を見つけたら、公の場で指摘しましょう。温和ながらも断固たるトーンで、なぜその行動が受け入れられないのか説明しましょう。もし問題が続くようであれば、[彼らに立ち去るように言う](../code-of-conduct/#enforcing-your-code-of-conduct)必要があるかもしれません。[行動規範](../code-of-conduct/)は、こういった会話を -生産的にする助けになりえます。 +もしあなたのプロジェクトで有害な行動を見つけたら、公の場で指摘しましょう。温和ながらも断固たるトーンで、なぜその行動が受け入れられないのか説明しましょう。もし問題が続くようであれば、[彼らに立ち去るように言う](../code-of-conduct/#enforcing-your-code-of-conduct)必要があるかもしれません。[行動規範](../code-of-conduct/)は、こういった会話を生産的にする助けになりえます。 ### コントリビュータを出迎えよう @@ -213,7 +212,7 @@ CONTRIBUTINGファイルに、新しいコントリビュータにどのよう ### READMEを憲法のように扱おう -READMEは[単なる手順書以上のものです](../starting-a-project/#READMEを書く)。そこにはあなたのゴールやロードマップについて書く場所でもあるのです。もし人々がある特定の機能のメリットについて議論しすぎているのであれば、READMEを見返してプロジェクトのより高レベルのビジョンについて話すことが助けとなるかもしれません。READMEに注力することは、会話を個人から切り離し、生産的な議論を行うことに繋がります。 +READMEは[単なる手順書以上のものです](../starting-a-project/#readmeを書く)。そこにはあなたのゴールやロードマップについて書く場所でもあるのです。もし人々がある特定の機能のメリットについて議論しすぎているのであれば、READMEを見返してプロジェクトのより高レベルのビジョンについて話すことが助けとなるかもしれません。READMEに注力することは、会話を個人から切り離し、生産的な議論を行うことに繋がります。 ### 向かう先ではなく、その過程に集中しよう diff --git a/_articles/ja/finding-users.md b/_articles/ja/finding-users.md index 9a79ca052e..20a4319544 100644 --- a/_articles/ja/finding-users.md +++ b/_articles/ja/finding-users.md @@ -142,7 +142,7 @@ Djangoの共同作者の[@adrianholovaty](https://news.ycombinator.com/item?id=7 avatar 今日urllib3がPythonの最も有名なサードパーティライブラリになった唯一の理由は、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) +— @shazow, ["How to make your open source project thrive"](https://about.sourcegraph.com/blog/how-to-make-your-open-source-project-thrive-with-andrey-petrov)

diff --git a/_articles/ja/getting-paid.md b/_articles/ja/getting-paid.md index 04affc3bc8..60620ae439 100644 --- a/_articles/ja/getting-paid.md +++ b/_articles/ja/getting-paid.md @@ -111,7 +111,7 @@ Depending on your personal circumstances, you can try raising money independentl Finally, sometimes open source projects put bounties on issues that you might consider helping with. -* @ConnorChristie was able to get paid for [helping](https://github.com/MARKETProtocol/MARKET.js/issues/14) @MARKETProtocol work on their javascript library [through a bounty on gitcoin](https://gitcoin.co/). +* @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their javascript library [through a bounty on gitcoin](https://gitcoin.co/). * @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://beta.bounties.network/bounty/v1/134). ## Finding funding for your project diff --git a/_articles/ja/leadership-and-governance.md b/_articles/ja/leadership-and-governance.md index 3fd218a155..c7007960fb 100644 --- a/_articles/ja/leadership-and-governance.md +++ b/_articles/ja/leadership-and-governance.md @@ -107,7 +107,7 @@ There are three common governance structures associated with open source project * **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](https://www.apache.org/); [all Apache projects](https://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://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/en-US/). +* **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://foundation.nodejs.org/) and [Rust](https://www.rust-lang.org/). 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: From 28c0d344b4a74ddc066173c6991e51ae6a08bd6a Mon Sep 17 00:00:00 2001 From: Yuichi Tanaka Date: Thu, 20 Dec 2018 16:46:36 +0900 Subject: [PATCH 0073/1478] Remove toc --- _articles/ja/best-practices.md | 7 ------- _articles/ja/building-community.md | 4 ---- _articles/ja/code-of-conduct.md | 6 ------ _articles/ja/finding-users.md | 7 ------- _articles/ja/getting-paid.md | 5 ----- _articles/ja/how-to-contribute.md | 7 ------- _articles/ja/leadership-and-governance.md | 8 -------- _articles/ja/legal.md | 8 -------- _articles/ja/metrics.md | 6 ------ _articles/ja/starting-a-project.md | 6 ------ 10 files changed, 64 deletions(-) diff --git a/_articles/ja/best-practices.md b/_articles/ja/best-practices.md index cd176b2d23..9bf27c2011 100644 --- a/_articles/ja/best-practices.md +++ b/_articles/ja/best-practices.md @@ -3,13 +3,6 @@ lang: ja 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: diff --git a/_articles/ja/building-community.md b/_articles/ja/building-community.md index bcbfbd88dd..145c0815f5 100644 --- a/_articles/ja/building-community.md +++ b/_articles/ja/building-community.md @@ -3,10 +3,6 @@ lang: ja title: 居心地の良いコミュニティを築こう description: 人々があなたのプロジェクトを使ったり、貢献したり、人に伝えたくなるようなコミュニティを築きましょう class: building -toc: - あなたのプロジェクトの成功のためのお膳立てをしましょう: "あなたのプロジェクトの成功のためのお膳立てをしましょう" - コミュニティを発展させよう: "コミュニティを発展させよう" - 衝突を解消しよう: "衝突を解消しよう" order: 4 image: /assets/images/cards/building.png related: diff --git a/_articles/ja/code-of-conduct.md b/_articles/ja/code-of-conduct.md index 0a97307dec..f4e8c6e6d5 100644 --- a/_articles/ja/code-of-conduct.md +++ b/_articles/ja/code-of-conduct.md @@ -3,12 +3,6 @@ lang: ja title: 行動規範ガイド 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" - your-responsibilities-as-a-maintainer: "Your responsibilities as a maintainer" order: 8 image: /assets/images/cards/coc.png related: diff --git a/_articles/ja/finding-users.md b/_articles/ja/finding-users.md index 20a4319544..cf345ada06 100644 --- a/_articles/ja/finding-users.md +++ b/_articles/ja/finding-users.md @@ -3,13 +3,6 @@ lang: ja title: あなたのプロジェクトのユーザーを見つけよう description: あなたのプロジェクトを喜んで使ってくれるユーザーを獲得してプロジェクトを拡大しよう class: finding -toc: - あなたの言葉を伝えよう: "あなたの言葉を伝えよう" - メッセージを見つけ出そう: "メッセージを見つけ出そう" - 人々があなたのプロジェクトを見つけたりフォローしやすくしよう: "人々があなたのプロジェクトを見つけたりフォローしやすくしよう" - ユーザーがいる場所に行こうオンライン: "ユーザーがいる場所に行こう（オンライン）" - ユーザーがいる場所に行こうオフライン: "ユーザーがいる場所に行こう（オフライン）" - 評判を築こう: "評判を築こう" order: 3 image: /assets/images/cards/finding.png related: diff --git a/_articles/ja/getting-paid.md b/_articles/ja/getting-paid.md index 60620ae439..518ec8fcc5 100644 --- a/_articles/ja/getting-paid.md +++ b/_articles/ja/getting-paid.md @@ -3,11 +3,6 @@ lang: ja 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: diff --git a/_articles/ja/how-to-contribute.md b/_articles/ja/how-to-contribute.md index 05fab2f44c..1b83d9e95e 100644 --- a/_articles/ja/how-to-contribute.md +++ b/_articles/ja/how-to-contribute.md @@ -3,13 +3,6 @@ lang: ja title: オープンソースに貢献する方法 description: オープンソースに貢献したいですか？このガイドではオープンソースへの貢献の方法を、初めての人だけでなく熟練の方にも紹介します。 class: contribute -toc: - オープンソースに貢献する理由は: "オープンソースに貢献する理由は？" - 貢献するということが意味するもの: "貢献するということが意味するもの" - 新しいプロジェクトに順応しよう: "新しいプロジェクトに順応しよう" - 貢献するプロジェクトを見つけよう: "貢献するプロジェクトを見つけよう" - 貢献を提出する方法: "貢献を提出する方法" - 貢献を提出した後に起こること: "貢献を提出した後に起こること" order: 1 image: /assets/images/cards/contribute.png related: diff --git a/_articles/ja/leadership-and-governance.md b/_articles/ja/leadership-and-governance.md index c7007960fb..57e4759566 100644 --- a/_articles/ja/leadership-and-governance.md +++ b/_articles/ja/leadership-and-governance.md @@ -3,14 +3,6 @@ lang: ja 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: diff --git a/_articles/ja/legal.md b/_articles/ja/legal.md index a149c1b572..4593becde6 100644 --- a/_articles/ja/legal.md +++ b/_articles/ja/legal.md @@ -3,14 +3,6 @@ lang: ja 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: diff --git a/_articles/ja/metrics.md b/_articles/ja/metrics.md index 68d3704118..b016e940ca 100644 --- a/_articles/ja/metrics.md +++ b/_articles/ja/metrics.md @@ -3,12 +3,6 @@ lang: ja 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: diff --git a/_articles/ja/starting-a-project.md b/_articles/ja/starting-a-project.md index be90aa5121..187e3dc1c2 100644 --- a/_articles/ja/starting-a-project.md +++ b/_articles/ja/starting-a-project.md @@ -3,12 +3,6 @@ lang: ja title: オープンソースプロジェクトを始めよう description: オープンソースの世界のことをもっと学び、あなた自身のプロジェクトを立ち上げる準備をしましょう class: beginners -toc: - オープンソースとは何でなぜそれを行うのか: "オープンソースとは何でなぜそれを行うのか" - 自分自身のオープンソースプロジェクトを立ち上げるべき: "自分自身のオープンソースプロジェクトを立ち上げるべき？" - あなた自身のオープンソースプロジェクトを立ち上げる: "あなた自身のオープンソースプロジェクトを立ち上げる" - あなたのプロジェクトに名前とブランドを付けよう: "あなたのプロジェクトに名前とブランドを付けよう" - 立ち上げ前のチェックリスト: "立ち上げ前のチェックリスト" order: 2 image: /assets/images/cards/beginner.png related: From ffcfcc4ebe751cf71f6a10714a5e2ce0c308912a Mon Sep 17 00:00:00 2001 From: Yuichi Tanaka Date: Sat, 22 Dec 2018 09:15:31 +0900 Subject: [PATCH 0074/1478] Keep translating Chapter 3 at building community article --- _articles/ja/building-community.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/_articles/ja/building-community.md b/_articles/ja/building-community.md index 145c0815f5..e7738c09de 100644 --- a/_articles/ja/building-community.md +++ b/_articles/ja/building-community.md @@ -232,19 +232,19 @@ READMEは[単なる手順書以上のものです](../starting-a-project/#readme 問題解決のために意思決定を急いではいけません。解決に至る前に、皆の意見が聞き入れられ、全ての情報が公開されているようにしましょう。 -### 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. +もし会話が明らかにどこにも向かっていなく、取るべきアクションもないか、適切なアクションはすでに起こしたのであれば、理由とともにイシューを閉じましょう。