diff --git a/_articles/best-practices.md b/_articles/best-practices.md index 428b6f803b3..cbfc5c7ff56 100644 --- a/_articles/best-practices.md +++ b/_articles/best-practices.md @@ -119,7 +119,7 @@ If you don't want to accept a contribution: 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) +![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/): diff --git a/_articles/building-community.md b/_articles/building-community.md index edb4790a106..307a1cc6fb1 100644 --- a/_articles/building-community.md +++ b/_articles/building-community.md @@ -20,7 +20,7 @@ A welcoming community is an investment into your project's future and reputation One way to think about your project's community is through what @MikeMcQuaid calls the [contributor funnel](https://speakerdeck.com/mikemcquaid/the-open-source-contributor-funnel): -![contributor funnel](/assets/images/building-community/contributor_funnel_mikemcquaid.png) +![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. @@ -80,7 +80,7 @@ Try to be responsive when someone files an issue, submits a pull request, or ask 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) +![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. @@ -130,7 +130,7 @@ Good documentation only becomes more important as your community grows. Casual c 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) +![Django new contributors page](/assets/images/building-community/django_new_contributors.png) In your issue queue, label bugs that are suitable for different types of contributors: for example, [_"first timers only"_](https://medium.com/@kentcdodds/first-timers-only-78281ea47455#.g1k01jy05), _"good first bug"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) make it easy for someone new to your project to quickly scan your issues and get started. @@ -158,11 +158,11 @@ See if you can find ways to share ownership with your community as much as possi * **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) +![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 sizeable 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. +* If you've got a sizable community, **send out a newsletter or write a blog post** thanking contributors. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) are two good examples. * **Give every contributor commit access.** @felixge found that this made people [more excited to polish their patches](http://felixge.de/2013/03/11/the-pull-request-hack.html), and he even found new maintainers for projects that he hadn't worked on in awhile. diff --git a/_articles/finding-users.md b/_articles/finding-users.md index 63f51f986b5..200db3e1b55 100644 --- a/_articles/finding-users.md +++ b/_articles/finding-users.md @@ -27,7 +27,7 @@ Remember that people get involved as users, and eventually contributors, because 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) +![Cartography README](/assets/images/finding-users/cartography.jpg) For a deeper dive into messaging, check out Mozilla's ["Personas and Pathways"](http://mozillascience.github.io/working-open-workshop/personas_pathways/) exercise for developing user personas. @@ -60,7 +60,7 @@ If you don't wish to set up these channels for your project yet, promote your ow 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) +![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! @@ -68,7 +68,7 @@ Now that you have a message for your project, and an easy way for people to find Online outreach is a great way to share and spread the word quickly. Using online channels, you have the potential to reach a very wide audience. -Take advantage of existing online communities and platforms to reach your audience. If your open source project is a software project, you can probably find your audience on [Stack Overflow](http://stackoverflow.com/), [reddit](http://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/). Find the channels where you think people will most benefit from or be excited about your work. +Take advantage of existing online communities and platforms to reach your audience. If your open source project is a software project, you can probably find your audience on [Stack Overflow](http://stackoverflow.com/), [Reddit](http://www.reddit.com), [Hacker News](https://news.ycombinator.com/), or [Quora](https://www.quora.com/). Find the channels where you think people will most benefit from or be excited about your work.