From 061ca9602e7c47206c6c06000dc9f6d1c00df440 Mon Sep 17 00:00:00 2001 From: LizzyOrji123 Date: Sun, 22 Oct 2023 19:06:17 +0100 Subject: [PATCH 1/8] created a new language called pidgin and created best-practice.md and added all best practices in pidgin language --- _articles/pidgin/best-practice.md | 260 ++++++++++++++++++++++++++++++ 1 file changed, 260 insertions(+) create mode 100644 _articles/pidgin/best-practice.md diff --git a/_articles/pidgin/best-practice.md b/_articles/pidgin/best-practice.md new file mode 100644 index 00000000000..cf706933210 --- /dev/null +++ b/_articles/pidgin/best-practice.md @@ -0,0 +1,260 @@ +--- +lang: pidgin +title: Best Practices for Maintainers +description: Learn how to make your life easy as an open source maintainer, from documentation to community collaboration. Make sense of maintaining open source projects with these top-notch tips. +class: best-practices +order: 5 +image: /assets/images/cards/best-practices.png +related: + - metrics + - leadership +--- + +## Wetin e mean to be maintainer? + +If you dey maintain one open source project wey plenty people dey use, you fit don notice say you dey write code sote you no dey rest. For the early days of your project, you dey try new tins and you dey make decisions based on wetin you wan. But as your project dey popular, you go dey work with users and contributors. + +To maintain project no be only about code. Plenty tins dey wey fit happen wey you no plan, but dem still dey important for your growing project. We don gather some ways wey go make your life easy, from writing down your process to involving your community. + +## Write the way waeh you use + +To write tins down, no be small work. E go make sense if you dey maintain your open source project. + +Documentation no be only for you to clear your mind, e go help other people understand wetin you need or wetin you dey expect before dem even ask. To write tins down go make am easy for you to yarn no when something no follow your project plan. E go also make am easy for people to fit join put hand for your project. You no go sabi who go fit read your project or use am. + +If you no get strength to dey update your documentation all the time, you fit delete the one wey don old or you fit talk say e don old so that people go sabi say dem fit update am. + +### Yarn Wetin Your Project Fit Be (Write Your Project's Vision) + +Start to write wetin you want make your project be. Put am for your README or create file wey you go call VISION. If you get other things wey fit help like project roadmap, e go make sense make you put dem for public make everybody sabi. + +As @lord don talk, project vision fit help you know wetin you go fit work on. As new maintainer, e talk say e no follow him project scope when e see first feature request for [Slate](https://github.com/lord/slate). + + + +### Talk Wetin You Expect + +E fit hard you to write down rules. Sometimes you fit think say you dey police people or say you dey dull dem vibe. + +But if you write rules fairly and you dey follow am, e go empower you. E go prevent you from doing tins wey you no like. People wey see your project fit no sabi your condition or circumstances. Dem fit think say dem dey pay you for the work wey you dey do, especially if na wetin dem dey use well well. Dem fit even think say you dey busy with new work or family matter. + +E good make people sabi dis tins. + +If to maintain your project na part-time or you dey do am because you volunteer, make you talk the time wey you get. E no be say na the time wey your project need or wetin people dey ask you for, na the time wey you get na e you go talk. E fit good if you write down some rules like: + +- How dem go review contribution (dem need test? Issue template?) +- The kind of contribution wey dem go accept (you wan make dem help you with specific part of your code?) +- When e go make sense for dem to follow up (e.g., "you fit expect response from maintainer within 7 days, if you no see any response by then, you fit ping the thread") +- How much time you dey spend for the project (e.g., "we dey spend like 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) na some examples of projects wey get rules for maintainers and contributors. + +### Make Your Communication Public + +No forget to write down your talks. Where you fit, make all your communication for your project public. If person try contact you for private to discuss feature request or support matter, tell am politely make e follow public channel yarn you like mailing list or issue tracker. + +If you meet other maintainers or you take big decision for private, write the conversation for public so that person wey follow your community go see the same information wey dem wey dey for years see. + +## Sabi To Say No + +You don write down wetin you want, but people never read your documentation well. Sometimes you go still remind them say knowledge dey your documentation. + +Saying no no dey fun, but make you try yarn "Your contribution no dey follow this project criteria" e no too personal like "I no like your contribution." + +You go fit yarn no for plenty situations wey you go see as maintainer like feature requests wey no follow your project plan or person wey dey disturb discussion. + +### Make the chitchat dey friendly + +One important place wey you go practice how to talk no be yes na for your issue and pull request queue. As person wey dey maintain project, e dey natural say you go dey see suggestions wey you no go want accept. + +Maybe the contribution wan change how your project dey work or e no dey follow your own idea. Maybe the idea make sense, but the way dem take do am no too correct. + +No matter how e be, e fit possible to waka diplomatically for contributions wey no too follow your project standards. + +If you come across one contribution wey you no wan accept, your first reaction fit be to dey do like say you no see am or to dey form say you no see am. If you do am like that, e fit wound the person way submit am and e fit even discourage other people wey wan contribute for your community. + + + +No just allow one contribution wey you no want dey open because you dey feel bad or you dey try to dey nice. As time dey go, the issues and PRs wey you never answer go make your project come dey feel like say e too stress you and dey intimidate you. + +E better make you quick-close contributions wey you sabi say you no wan accept am. If your project don already gather plenti matter wey never resolve, @steveklabnik get some advice on [how to quickly arrange the issues] so e go dey efficient. (https://words.steveklabnik.com/how-to-be-an-open-source-gardener). + +If you no wan accept one contribution: + +* **Thank them** for their contribution +* **Explain why e no follow** within the project's scope, and offer clear suggestions for how e fit improve, if you sabi. Make sure say you dey friendly but firm. +* **Attach link to relevant documentation**, if you get am. If you dey see people dey request the same thing wey you no dey ready to accept, put am for your documentation so that you no go dey repeat yourself. +* **Close the request** + +You no need talk pass 1-2 sentences for response. For example, when person wey dey use [celery](https://github.com/celery/celery/) report say e get one Windows-related error, @berkerpeksag [reply like this](https://github.com/celery/celery/issues/3383): + +![Celery screenshot](/assets/images/best-practices/celery.png) + +If the fear of saying "no" dey worry you, my brother, you no dey alone for this matter. As @jessfraz [talk am for here](https://blog.jessfraz.com/post/the-art-of-closing/): + +> I don chook mouth with maintainers wey dey run different open source projects like Mesos, Kubernetes, Chromium, and all of them gree say one of the hardest part for person wey dey maintain na to talk "No" to patches wey e no wan. + +No go dey feel bad say you no wan accept person contribution. The first law for open source, [as](https://twitter.com/solomonstre/status/715277134978113536) @shykes talk am: _"No na for time, yes na forever."_ While you dey reason the person wey get ginger, e no mean say you dey reject the person way submit contribution. + +At the end of the day, if contribution no follow standard, you no dey owe anybody obligation to accept am. Just dey friendly and ready to answer when people wan contribute to your project, but make you dey accept only the changes wey you believe say e go make your project better. As you dey practice to talk "no" often, e go dey easier. I promise you. + +### Dey Ahead of Time + +To reduce the plenty unwanted contributions from the start, explain your project process for submitting and accepting contributions for your contributing guide. + +If you dey receive plenty low-quality contributions, you fit tell contributors make them do small work before: + +* Fill out one kind issue or PR template/checklist +* Open one issue before them submit PR + +If them no follow your rules, close the issue sharp-sharp and show them your documentation. + +Although e fit seem like say this approach no dey friendly at first, but e dey better for everybody. E dey reduce the chance say person go waste time dey work on top PR wey you no go accept. E also dey reduce your own work burden. + + + +Sometimes, when you talk no, person fit vex or criticize your decision. If their behavior come bad, [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 them no dey ready to work together positively. + +### Show Love for Mentorship + +E fit happen say one person for your community dey always submit contributions wey no meet your project standards. E fit dey vex both parties as them dey reject their work every time. + +If you see say person dey show interest for your project but e just need small touch, be patient. Make you clear for every situation why their contributions no dey up to the project standards. Try to show them where them fit do better, maybe by working on one small or less complex task, like issue wey dem mark "good first issue," to give them confidence. If you get time, you fit mentor them as them dey do their first contribution, or you find person for your community wey go fit mentor them. + +## Tap into your community + +You no need to do everything alone. Your project community dey exist for one reason! Even if you no get active community of contributors yet, if plenty people dey use your project, make them help you. + +### Share the workload + +If you dey find people wey go fit help, start to ask around. + +One way to get new contributors be to [label issues wey dey simple for beginners to work on](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub go show these issues for different places for the platform, e go make them dey easier to see. + +When you see new contributors wey dey make repeated contributions, make you acknowledge their work and give them more responsibility. Write down how other people fit grow into leadership roles if them wan. Make you encourage others to [share ownership of the project](../building-community/#share-ownership-of-your-project) because e fit reduce your own workload, just like @lmccart find out for her project, [p5.js](https://github.com/processing/p5.js). + + + +If you need to step away from your project, whether on leave or permanently, no shame dey ask another person to take over for you. + +If other people dey happy about the project direction, give them access to make changes or formally hand over control to another person. If person don fork your project and dey actively maintain am for another place, consider put link to the fork from your original project. E good as plenty people dey show interest for your project! + +@progrium [talk say](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) as him documenting the vision for his project, [Dokku](https://github.com/dokku/dokku), help others to carry on the goals even after he comot from the project: + +> I write one wiki page wey describe wetin I want and why I want am. For some reason, e shock me as the maintainers begin move the project in that direction! E no always dey exactly how I go do am? Not every time. But e still bring the project close to wetin I write down. + +### Make others build their own solutions + +If potential contributor get another idea for your project and e no follow your own idea, you fit encourage am gently to work on their own fork. + +Creating one fork of the project no dey bad at all. Make people sabi say them fit copy and modify projects, and e dey good thing about open source. Encourage your community members to work on their own fork because e fit give them creative freedom wey no go dey against your project vision. + + + +The same thing fit apply to one user wey need solution wey you no get time to build. Offer APIs and customization options wey fit help other people meet their needs, without them needing to modify the source directly. @orta [see](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) say as them dey encourage plugins for CocoaPods, e lead to "some of the most interesting ideas": + +> Almost like magic, when project big well well, maintainers must dey more conservative about how them dey add new code. You go sabi how to talk "no," but plenty people get valid needs. Instead, you fit change your tool into one platform. + +## Bring them robots + +Just like how other people fit help you with some tasks, some tasks no go make sense for person to dey do. Robots go be your friends for this matter. Use them to make your life as one maintainer dey easier. + +### Make you dey run tests and checks to upgrade your code quality + +One important way wey you fit automate your project be to add tests. + +Tests fit make contributors dey confident say them no go spoil anything. Them still dey make am easy for you to review and accept contributions quickly. The more responsive you dey, the more engaged your community fit dey. + +Set up automatic tests wey go run on all incoming contributions, and make sure say your tests dey easy to run locally by contributors. You must require say all code contributions must pass your tests before them fit submit am. You go help set one minimum standard of quality for all submissions. [Required status checks](https://help.github.com/articles/about-required-status-checks/) for GitHub fit help ensure say no change go enter if your tests no pass. + +If you add tests, make sure say you explain how them dey work for your CONTRIBUTING file. + + + +### Use tools to automate basic maintenance tasks + +The good news about maintaining a popular project be say other maintainers fit don face similar challenges and build solutions for them. + +Plenty [tools dey available](https://github.com/showcases/tools-for-open-source) wey fit help automate some parts of maintenance work. Some examples include: + +* [semantic-release](https://github.com/semantic-release/semantic-release) wey dey automate your releases +* [mention-bot](https://github.com/facebook/mention-bot) wey dey mention potential reviewers for pull requests +* [Danger](https://github.com/danger/danger) wey help automate code review +* [no-response](https://github.com/probot/no-response) wey close issues wey the author no respond to requests for more information +* [dependabot](https://github.com/dependabot) wey dey check your dependency files every day for outdated requirements and dey open individual pull requests for any wey e see. + +For bug reports and other common contributions, GitHub get [Issue Templates and Pull Request Templates](https://github.com/blog/2111-issue-and-pull-request-templates), wey you fit create to streamline the communication wey you dey receive. @TalAter create [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 fit set up [email filters](https://github.com/blog/2203-email-updates-about-your-own-activity) to organize them by priority. + +If you want to get more advanced, style guides and linters fit standardize project contributions and make them easy to review and accept. + +However, if your standards too complex, them fit dey increase the obstacles to contribution. Make sure say you just add enough rules wey go make everyone's life easier. + +If you no sure which tools to use, look at what other popular projects dey do, especially those for your ecosystem. For example, wetin the contribution process be like for other Node modules? Using similar tools and approaches go make your process more familiar to your target contributors. + +## E dey okay to pause + +Open source work wey once dey give you joy fit dey make you avoid or dey guilty now. + +Maybe you dey feel overwhelmed or one growing sense of dread when you think about your projects. Meanwhile, issues and pull requests just dey pile up. + +Burnout na real issue wey plenty maintainers dey face for open source work. As one maintainer, your happiness na one non-negotiable requirement for the survival of any open source project. + +Though e suppose dey obvious, make you take break! You no need wait until you feel burnt out before you take vacation. @brettcannon, one Python core developer, decide to take [one 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 work, make you dey take regular breaks so you go dey refreshed, happy, and excited about your work. + + + +Sometimes, e fit hard to take break from open source work when e look like everybody need you. People fit even try to make you feel guilty as you dey step away. + +Try find support for your users and community if you dey away from one project. If you no fit find the support wey you need, just take break. Make you sure to communicate when you no dey available, so people no go dey confused when you no dey respond. + +Taking breaks no only apply to vacations, e fit include say you no wan do open source work during weekends or work hours. Communicate those expectations to others, so them go know say dem no suppose disturb you. + +## Make you dey take care of yourself first! + +To maintaining one popular project require different skills from the first first time of growth, but e no dey less rewarding. As one maintainer, you go dey practice leadership and personal skills for one level wey few people fit experience. Though e no dey easy to manage, setting clear boundaries and only taking on wetin you dey comfortable with go help you dey happy, refreshed, and productive. From 5adac1996777353f2377b6b4ba9e80a73b4da127 Mon Sep 17 00:00:00 2001 From: LizzyOrji123 Date: Tue, 24 Oct 2023 13:05:28 +0100 Subject: [PATCH 2/8] created building-communities.md and code-of-conduct.md, I also created the pidgin.yml --- _articles/pidgin/best-practice.md | 18 +- _articles/pidgin/building-community.md | 258 +++++++++++++++++++++++++ _articles/pidgin/code-of-conduct.md | 58 ++++++ _data/locales/pidgin.yml | 31 +++ assets/css/translate.scss | 1 + 5 files changed, 357 insertions(+), 9 deletions(-) create mode 100644 _articles/pidgin/building-community.md create mode 100644 _articles/pidgin/code-of-conduct.md create mode 100644 _data/locales/pidgin.yml diff --git a/_articles/pidgin/best-practice.md b/_articles/pidgin/best-practice.md index cf706933210..195f3d1d556 100644 --- a/_articles/pidgin/best-practice.md +++ b/_articles/pidgin/best-practice.md @@ -55,7 +55,7 @@ If to maintain your project na part-time or you dey do am because you volunteer, [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) na some examples of projects wey get rules for maintainers and contributors. -### Make Your Communication Public +### Make Sure Your Communication Commot For Outside No forget to write down your talks. Where you fit, make all your communication for your project public. If person try contact you for private to discuss feature request or support matter, tell am politely make e follow public channel yarn you like mailing list or issue tracker. @@ -69,7 +69,7 @@ Saying no no dey fun, but make you try yarn "Your contribution no dey follow thi You go fit yarn no for plenty situations wey you go see as maintainer like feature requests wey no follow your project plan or person wey dey disturb discussion. -### Make the chitchat dey friendly +### Make the talk-talk dey friendly One important place wey you go practice how to talk no be yes na for your issue and pull request queue. As person wey dey maintain project, e dey natural say you go dey see suggestions wey you no go want accept. @@ -93,9 +93,9 @@ E better make you quick-close contributions wey you sabi say you no wan accept a If you no wan accept one contribution: -* **Thank them** for their contribution +* **Tell them thank you** for their contribution * **Explain why e no follow** within the project's scope, and offer clear suggestions for how e fit improve, if you sabi. Make sure say you dey friendly but firm. -* **Attach link to relevant documentation**, if you get am. If you dey see people dey request the same thing wey you no dey ready to accept, put am for your documentation so that you no go dey repeat yourself. +* **Link waeh get Relevant documentation na him you go add**, if you get am. If you dey see people dey request the same thing wey you no dey ready to accept, put am for your documentation so that you no go dey repeat yourself. * **Close the request** You no need talk pass 1-2 sentences for response. For example, when person wey dey use [celery](https://github.com/celery/celery/) report say e get one Windows-related error, @berkerpeksag [reply like this](https://github.com/celery/celery/issues/3383): @@ -133,17 +133,17 @@ Although e fit seem like say this approach no dey friendly at first, but e dey b Sometimes, when you talk no, person fit vex or criticize your decision. If their behavior come bad, [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 them no dey ready to work together positively. -### Show Love for Mentorship +### Dey Show Love for Mentorship E fit happen say one person for your community dey always submit contributions wey no meet your project standards. E fit dey vex both parties as them dey reject their work every time. If you see say person dey show interest for your project but e just need small touch, be patient. Make you clear for every situation why their contributions no dey up to the project standards. Try to show them where them fit do better, maybe by working on one small or less complex task, like issue wey dem mark "good first issue," to give them confidence. If you get time, you fit mentor them as them dey do their first contribution, or you find person for your community wey go fit mentor them. -## Tap into your community +## Put hand inside your community You no need to do everything alone. Your project community dey exist for one reason! Even if you no get active community of contributors yet, if plenty people dey use your project, make them help you. -### Share the workload +### Make you share the work If you dey find people wey go fit help, start to ask around. @@ -167,7 +167,7 @@ If other people dey happy about the project direction, give them access to make > I write one wiki page wey describe wetin I want and why I want am. For some reason, e shock me as the maintainers begin move the project in that direction! E no always dey exactly how I go do am? Not every time. But e still bring the project close to wetin I write down. -### Make others build their own solutions +### Make other pesin build them own solutions If potential contributor get another idea for your project and e no follow your own idea, you fit encourage am gently to work on their own fork. @@ -207,7 +207,7 @@ If you add tests, make sure say you explain how them dey work for your CONTRIBUT

-### Use tools to automate basic maintenance tasks +### Carry tools use am to automate basic maintenance tasks The good news about maintaining a popular project be say other maintainers fit don face similar challenges and build solutions for them. diff --git a/_articles/pidgin/building-community.md b/_articles/pidgin/building-community.md new file mode 100644 index 00000000000..315c2037cd2 --- /dev/null +++ b/_articles/pidgin/building-community.md @@ -0,0 +1,258 @@ +--- +lang: pidgin +title: Na Welcoming Communities we go Build +description: Make you build one community wey go encourage people make them use, contribute, and promote your project. +class: building +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +--- + +## Set that your project make aeh succeed + +You don launch your project, you dey spread the word, and people dey check am out. Correct! Now, how you wan make them stick around? + +One welcoming community na one investment into your project's future and reputation. If your project just dey start to see its first contributions, make you start by dey give early contributors one positive experience, and make you dey easy for them to dey come back. + +### Make people dey feel welcome + +One way to think about your project's community na through wetin @MikeMcQuaid call 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 dey build your community, consider how person wey dey the top of the funnel (potential user) fit possibly waka reach the bottom (active maintainer). Your koko na to reduce any wahala for each stage of the contributor experience. Na when people fit see better results without too much stress, them go feel encouraged to do more. + +Start with your documentation: + +* **Make am easy for person to use your project.** [One friendly README](../starting-a-project/#writing-a-readme) and clear code examples fit make am easier for anybody wey land for your project to begin. +* **Explain contribution make aeh clear**, using [your CONTRIBUTING file](../starting-a-project/#writing-your-contributing-guidelines) and make sure say your issues dey up-to-date. +* **Good first issues**: To helep tear rubber contributors start, think am say [labeling issues wey dey simple for beginners to handle](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub go show these issues for different places for the platform, e go increase useful contributions and reduce friction for people wey wan handle issues wey too hard for their level. + +[GitHub's 2017 Open Source Survey](http://opensourcesurvey.org/2017/) talk say incomplete or confusing documentation na the biggest problem wey open source users dey face. Good documentation go invite people to interact with your project. E fit happen say one person go open an issue or pull request. Use these interactions as opportunities to waka them down the funnel. + +* **When new person land for your project, thank them for their interest!** E fit just take one bad experience for person to no wan come back again. +* **Be responsive.** If you no respond to their issue for one month, e possible say them don forget your project. +* **Open mind about the types of contributions wey you go accept.** Many contributors start with one bug report or one small fix. Many ways dey to contribute to one project. Make people fit help the way wey them wan help. +* **If one person submit one contribution wey you no gree with,** thank them for their idea and [explain why](../best-practices/#learning-to-say-no) e no follow your project scope, and you fit add link to the relevant documentation wey you get. + + + +Most open source contributors na "casual contributors": people wey only occasionally contribute to one project. One casual contributor fit no get time to sabi everything about your project, so your work na to make am easy for them to contribute. + +Encouraging other contributors na one investment in yourself, too. When you empower your biggest fans to run with the work wey dem dey passionate about, e go reduce the pressure to dey do everything yourself. + +### Make you write everything for document + + + +When you start one new project, e fit be like say e natural to dey keep your work private. But open source projects dey flourish when you document your process for public. + +When you write things down, more people fit participate at every stage of the way. You fit get help for something wey you never sabi say you need am. + +To write things down no mean only technical documentation. Anytime you feel the urge to write something down or privately discuss your project, ask yourself whether you fit make am public. + +Make you transparent about your project's roadmap, the types of contributions wey you dey look for, how contributions dey review, or why you make certain decisions. + +If you see say many people dey run into the same problem, make you document the answers for the README. + +For meetings, consider say make you publish your notes or key points for one relevant issue. The feedback wey you go get from this level of transparency fit surprise you. + +To document everything apply to the work wey you dey do, too. If you dey work on one substantial update for your project, make you put am for one pull request and mark am as one work in progress (WIP). So, other people fit dey involved for the process from the beginning. + +### Be responsive + +As you [promote your project](../finding-users), people fit get feedback for you. Them fit get questions about how things dey work, or them fit need help to begin. + +Try to dey responsive when person open one issue, submit one pull request, or ask question about your project. When you respond quick, people go feel say them dey part of one discussion, and them go dey more enthusiastic about participation. + +Even if you no fit review the request immediately, acknowledge am early to help increase engagement. @tdreyno respond to one pull request for [Middleman](https://github.com/middleman/middleman/pull/1466) like this: + +![Middleman pull request](/assets/images/building-community/middleman_pr.png) + +A Mozilla study talk say if dem review code within 48 hours, plenty contributors dey return and contribute again. + +Any talku talku about your project fit dey happen for other places online like Stack Overflow, Twitter, or Reddit. You fit set notification for some of these places so dem go alert you if person talk about your project. + +### Make you create one place where your community go gather + +E get two reason why you suppose create community place. The first reason na for dem, e go helep dem know each other. People wey get common interest must dey find place wey dem go yan about am. And when communication dey public and easy to reach, anybody fit read past messages make e understand wetin dey happen and fit join the talk. The second reason na for you. If you no create public place for people to discuss your project, dem fit contact you directly. For beginning e fit dey easy for you to respond to private messages "just this once". But as time dey go, especially if your project dey popular, you go dey tire. No gree make you dey communicate with people about your project for private. Instead, direct dem go one public place. + +Public communication fit be as simple as directing people make dem go open issue instead of sending mail give you directly or make dem comment for your blog. You fit also create mailing list, or make you create Twitter account, Slack, or IRC channel for people to talk about your project. Or you fit even try all of them! + +[Kubernetes kops] (https://github.com/kubernetes/kops#getting-involved) "Kubernetes kops dey set time every other week make dem helep community members: + +> Kops still get time wey dem set aside every other week to offer guidance and help to the community. Kops maintainers don agree to set time wey dem go use work with newcomers, helep with PRs, and yan about new features. + +Notable exceptions to public communication be: 1) security issues and 2) sensitive code of conduct violations. You suppose always get one way wey people fit report these issues for private. If you no wan use your personal email, set up one email wey dem go use just for this. + +## Make your community dey climb + +Communities get power. That power fit be good thing or bad thing, depending on how you use am. As your project community dey grow, there dey ways wey you fit use make am be force for building, no be destruction. + +### No dey tolerate bad actors + +Any popular project go always attract people wey go dey do bad things instead of helep. Dem fit dey start arguments wey no dey necessary, dey quarrel on top small-small things, or dey bully others. + +Do your best make you get zero-tolerance policy for these kind people. If you no fit control dem, these bad people fit dey make others for your community no dey comfortable. Dem fit even run. + + + +Regular debates on top small-small parts of your project dey distract others, and even you, from focusing on important work. New people wey show for your project fit see these arguments and no wan join. + +Any time you see bad behavior wey dey happen for your project, yan am out for public. Explain, with kind but firm words, why their behavior no good. If the problem no stop, you fit need [tell them make dem waka](../code-of-conduct/#enforcing-your-code-of-conduct). Your [code of conduct](../code-of-conduct/) fit be useful guide for these talks. + +### Meet contributors where dem dey + +Good documentation dey very important as your community dey grow. People wey no dey familiar with your project fit read your documentation make dem quickly understand wetin dey happen. + +In your CONTRIBUTING file, tell new contributors explicitly how dem go take start. You fit even make one special section for this purpose. [Django](https://github.com/django/django), for example, get one special landing page to welcome new contributors. + +![Django new contributors page](/assets/images/building-community/django_new_contributors.png) + +For your issue queue, label bugs wey dey suitable for different types of contributors, like [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) These labels go helep someone wey dey new to your project to easily look your issues and take start. + +Use your documentation to helep people feel welcome at every step. + +For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md): + +You no go fit talk with most people wey go show for your project. Some people fit come helep you wey you no go sabi because dem feel say dem dey intimidated or dem no sabi where to take start. Even few kind words fit helep make person no commot for your project for frustration. + +### Share the person waeh get your project + + + +People dey ginger to yan-kick for projects when dem feel like dem get sense of ownership. E no mean say you go come give dem your project vision or gree accept contributions wey you no want. But as you dey respect and appreciate other people efforts, e go make dem dey yan-kick. + +Try look for ways wey you fit share this ownership with your community as much as possible. Some yeye ideas wey you fit try include: + +* **No dey hurry to fix small-small (non-serious) wahala.** Instead, use am as chance to bring new contributors or show person way wan yan-kick. E fit look strange at first, but as time go dey, your investment go bring profit. For example, @michaeljoseph tell one person say make e submit pull request for [Cookiecutter](https://github.com/audreyr/cookiecutter) issue for down, instead of make e fix am himself. + +![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png) + +* **Start CONTRIBUTORS or AUTHORS file for your project** wey go list everybody wey don yan-kick for your project, like [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) do. + +* If your community don shapely well-well, **send newsletter or write blog post** to appreciate the people wey don yan-kick. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) na two examples wey dey good. + +* **Give every contributor access to commit.** @felixge see say this one dey ginger people, e make dem dey shine their patches [more](https://felixge.de/2013/03/11/the-pull-request-hack.html), and e even find new maintainers for projects wey e never dey touch for long. + +* If your project dey on GitHub, **move your project from your personal account go [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** and add at least one backup admin. Organizations dey make am easy to work with external people. + +The fact na say [most projects get](https://peerj.com/preprints/1233/) only one or two maintainers wey dey do plenty work. As your project dey grow or your community dey big pass, e go dey easy to find help. + +Even if you no fit always find person to answer the call, once you put signal for there, e dey increase chance say other people go waka come yan-kick. The earlier you start, the better for you, because e go make people waka come fast-fast. + +Na for [Welcoming Communities](http://hood.ie/blog/welcoming-communities.html), @gr2m yarn say e dey for your [best interest](https://peerj.com/preprints/1233/) to find contributors wey sabi and enjoy to do the things wey you no sabi. If you like code but e no dey easy for you to answer issues, try find people for your community wey sabi, make dem handle am. + +## Settling Wahala + +As your project dey begin, e dey easy to make major decisions. When you wan do something, e fit be like breeze, you go just do am. + +As your project dey popular, more people go dey chook eye for the decisions wey you dey take. Even if you no get big community of contributors, if your project get many users, people go wan add their mouth for the decisions or raise their own issues. + +Aside small-small issues wey e clear say your community go fit resolve, sometimes you fit see say one issue dey tough small small. + +### Arrange everything make kindness dey + +When your community dey tackle one yeye issue, tempers fit dey rise. People fit vex or feel frustrated and dem fit they chook mouth for each other or for your matter. + +Your work as maintainer na to make sure say these situations no go high. Even if you get strong opinion on top the matter, try play moderator or facilitator role, no just enter the matter dey force your views. If person no dey polite or e dey use mouth scatter discussions, [take action immediately](../building-community/#dont-tolerate-bad-actors) to make sure say discussions dey civil and productive. + +Other people dey look you for guidance. Set example wey go make sense. You fit still yan your disappointment, sorrow or concern, but do am calmly. + +Make your head nor dey hot e nor easy, but as you set good example, e go make your community strong. The internet dey thank you. + +### Treat README like say na constitution + +Your README [no be only set of instructions](../starting-a-project/#writing-a-readme). E also na place to yan about your goals, product vision, and roadmap. If people dey focus too much on top argument about one particular feature, e fit help if you go back your README, talk about the higher vision of your project. To focus on your README go even make the matter no dey personal, so that you go fit yan-kick with sense. + + +### Make we focus for the journey, nor be the destination + +Some projects dey use voting process to take make major decisions. E fit look sensible for eye at first, but voting dey show say them dey find 'answer,' instead of say them dey listen to each other concerns. + +Voting fit turn political, where people for the community go dey fear say them go gree do favors for each other or vote in one particular way. Nor be everybody go fit vote, whether e na the [silent majority](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) for your community or people wey dey use your project wey nor know say vote dey happen. + +Sometimes, voting na necessary way to take settle wahala. But as much as you fit, try dey emphasize ["consensus seeking"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) instead of consensus. + +For one consensus seeking process, community members go yan about major concerns until them believe say their talk don dey enough. When only small-small concerns still dey, the community go dey go front. "Consensus seeking" no dey expect say the community go reach perfect answer. Instead, e dey focus on listening and discussion. + + + +Even if you nor actually use consensus seeking process, as a project maintainer, e dey important make people know say you dey hear them. To show say you dey hear people and you dey ready to settle their wahala, e dey help to cool down tense situations. After that, follow your words with actions. + +Don't dey rush make you take decision just because you wan find solution. Try make everybody feel say dem don dey hear and all information dey public before you fit find solution. + +### Make we dey yan for action + +Discussion dey important, but difference dey between productive and unproductive talks. + +Encourage discussion as long as e dey carry us close to solution. If e clear say the talk dey delay or dem dey yan out of the matter or e dey like say dem dey yan personal talk, or people dey yan yeye about small details, e dey time to stop am. + +If you allow this kind talk to continue, e no go only bad for the issue wey dey ground, e go dey bad for the health of your community. E go show say this kind talk na normal thing wey them dey allow or even dey encourage, and e fit discourage people from raising or settling future issues. + +For every talk wey you talk or other people talk, ask yourself, _"How this one wan carry us closer to solution? + +If the talk dey scatter, make you ask the group, _"Which steps we wan take next?"_ to refocus the discussion. + +If the talk clear nor dey waka, e nor get clear action to take, or the right action don already happen, close the issue and yan why you close am. + + + + +### Choose your battles with sense + +Context dey important. Think about the people wey dey the discussion and how them represent the rest of the community. + +Na all the community dey vex or even follow for this issue? Or na just one person wey wan dey find trouble? No forget say you suppose consider your silent community members, nor be only the people wey dey yan. + +If the issue nor dey show the real needs of your community, you fit just gree say the concerns of few people matter. If this one na issue wey dey always come up and nor dey get clear solution, tell them say make them check discussions wey dem don already talk about the matter before and close the discussion. + +### Identify person or group wey fit be community tiebreaker + +With correct attitude and clear communication, many difficult situations fit dey easy to settle. But even for productive talk, e fit still dey difference for opinion on how to dey move front. For this kind situation, identify one person or group of people wey fit help settle the wahala. + +One tiebreaker fit be the main person wey dey control the project, or e fit be small group of people wey fit make decision based on voting. E good make you don already identify tiebreaker and the process for GOVERNANCE file before e go happen. + +Your tiebreaker suppose be last option. Issues wey dey cause fight for community dey make the community fit grow and learn. Embrace the opportunity and use collaborative process to find solution where you fit. + +## Community na the ❤️ of open source + +Healthy and vibrant communities na the engine wey dey fuel the plenty hours wey dem spend for open source every week. Many contributors dey point to other people as the reason why dem dey work - or nor dey work - for open source. As you sabi tap into that power constructively, you go fit help person somewhere get unforgettable open source experience. diff --git a/_articles/pidgin/code-of-conduct.md b/_articles/pidgin/code-of-conduct.md new file mode 100644 index 00000000000..6ed301d9c81 --- /dev/null +++ b/_articles/pidgin/code-of-conduct.md @@ -0,0 +1,58 @@ +--- +lang: pidgin +title: Una Code of Conduct +description: Make community people dey behave well and do constructive tins, by accepting and enforcing the code of conduct. +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## Code of conduct and why you need am? + +Code of conduct na document wey dey establish expectation for the way wey people go take behave for your project. To adopt, and enforce, code of conduct fit help create positive social atmosphere for your community. + +Code of conduct epp to protect not just the people wey dey participate for your project, but you too. If you dey maintain a project, you fit see say unproductive attitude from other people fit dey drain your energy and make you unhappy about your work as time dey go. + +Code of conduct dey give you power to encourage healthy and constructive community behavior. To dey proactive dey reduce the chance say you, or other people, go dey tire for your project, and epp you take action if person do something wey you nor gree with. + +## How you go take arrange code of conduct + +Make you try your best to arrange code of conduct early, if you fit, ideally when you first create your project. + +Apart from just communicating your expectations, code of conduct fit describe the following: + +- Where the code of conduct dey apply _(only on issues and pull requests, or community activities like events?)_ +- Whom the code of conduct dey apply to _(community members and maintainers, but what about sponsors?)_ +- Wetin go happen if person violate the code of conduct +- How person fit report violations + +Anywhere way you fit, try to use previous example. The [Contributor Covenant](https://contributor-covenant.org/) na code of conduct wey many open source projects, including Kubernetes, Rails, and Swift, don use, and e fit serve as example. + +The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) na two good examples of code of conduct. + +Put one CODE_OF_CONDUCT file for your project's main directory, and make sure say your community fit see am by linking am for your CONTRIBUTING or README file. + +## How to enforce your code of conduct + +You suppose explain how you go enforce your code of conduct **_before_** person violate am. Some reasons why you suppose do am be say: + +- E show say you dey serious about action when e dey necessary. + +- Your community go dey reassured say complaints go dey reviewed. + +- You go reassure your community say the review process go dey fair and transparent, if at any time dem dey investigated for violation. + +You suppose give people private way (like email address) to report code of conduct violation and explain who go receive that report. E fit be maintainer, group of maintainers, or code of conduct working group. + +No forget say person fit wan report violation about person wey dey receive those reports. In this case, give dem option to report violations to another person. For example, @ctb and @mr-c [explain for their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): + +> Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology. + +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). + +## How to enforce your code of conduct + +Sometimes, despite your best efforts, somebody go do something wey dey violate this code. There are several ways to address negative or harmful behavior when it comes up. diff --git a/_data/locales/pidgin.yml b/_data/locales/pidgin.yml new file mode 100644 index 00000000000..7a6a648f6dd --- /dev/null +++ b/_data/locales/pidgin.yml @@ -0,0 +1,31 @@ +en: + locale_name: English + nav: + about: About + contribute: Put hand + index: + lead: Open source software na people wey dey like you epp build am. Learn how to start and make your project big. + opensourcefriday: Na Friday! Spend few hours to contribute to the software wey you dey use and love. + article: + table_of_contents: Table of Contents + back_to_all_guides: Abeg, make I run go back to all those guides + related_guides: Related Guides + footer: + contribute: + heading: Put hand + description: You wan yan something? This mata wey dey here, e fit be your own. Abeg, helep us make e better. + button: Put hand + subscribe: + heading: Make we dey in contact + description: Make you be the first wey go hear about GitHub's latest open source tips and resources.. + label: Email adiress + button: Folow + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] with [love] by [github] and [friends]" + # Label for code octicon + code_label: code + # Label for love octicon + love_label: love + # Label for the contributors link + friends_label: padi diff --git a/assets/css/translate.scss b/assets/css/translate.scss index d8403e141b2..98c0508c3c9 100644 --- a/assets/css/translate.scss +++ b/assets/css/translate.scss @@ -26,6 +26,7 @@ $section_translation: ( "tr": "", "zh-hant": "章節", "zh-hans": "章节", + "pidgin": "Portion", ); @each $locale, $translation in $section_translation { From 05644cfd4ca0d874b24f18fc437e150d00cb7b04 Mon Sep 17 00:00:00 2001 From: LizzyOrji123 Date: Tue, 24 Oct 2023 13:49:02 +0100 Subject: [PATCH 3/8] finished up code-of-conduct.md and created finding-users.md and wrote in it --- _articles/pidgin/code-of-conduct.md | 60 +++++++++++- _articles/pidgin/finding-users.md | 144 ++++++++++++++++++++++++++++ 2 files changed, 202 insertions(+), 2 deletions(-) create mode 100644 _articles/pidgin/finding-users.md diff --git a/_articles/pidgin/code-of-conduct.md b/_articles/pidgin/code-of-conduct.md index 6ed301d9c81..d008849c68f 100644 --- a/_articles/pidgin/code-of-conduct.md +++ b/_articles/pidgin/code-of-conduct.md @@ -35,7 +35,14 @@ The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Ci Put one CODE_OF_CONDUCT file for your project's main directory, and make sure say your community fit see am by linking am for your CONTRIBUTING or README file. -## How to enforce your code of conduct +## How you go take think your code of conduct to stand gidi gba + + You suppose explain how you go enforce your code of conduct **_before_** person violate am. Some reasons why you suppose do am be say: @@ -53,6 +60,55 @@ No forget say person fit wan report violation about person wey dey receive those 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). -## How to enforce your code of conduct +## How your code of conduct go take stand gidi gba Sometimes, despite your best efforts, somebody go do something wey dey violate this code. There are several ways to address negative or harmful behavior when it comes up. + +### Gather plenty gist about the mata + +Arrange community member voice make aeh dey important as your own dey. If person report say somebody violate the code of conduct, take am seriously and investigate the matter, even if e nor match your own experience with that person. As you do like this, you dey show your community say you value their perspective and trust their judgment. + +The community member wey dey involved fit be person wey dey always cause trouble and dey make other people dey uncomfortable, or e fit be say e talk or do something just once. You fit take action based on the situation. + +Before you yarn, give yourself time to understand wetin happen. Read the person's past comments and conversations make you sabi who e be and why e fit do something like that. Try gather different perspectives from other people about the person and the way e take behave. + + + +### Carry action waeh make sense + +After you don gather and process enough information, you go need to decide wetin you go do. As you dey consider your next steps, remember say your goal as a moderator na to promote safe, respectful, and collaborative environment. Consider how you go take handle the matter and how your response fit affect the way other community members go take dey behave and their expectations for future. + +If person report say somebody violate the code of conduct, e na you suppose handle am, not the person wey report. Sometimes, the person wey report dey risk plenty things like e career, reputation, or physical safety. Forcing am to confront the person wey dey harass am fit put am for wahala. You suppose dey communicate directly with the person wey dey involved, except the person wey report request something different. + +You fit respond to code of conduct violation for different ways: + +- **Warn the person wey dey involved publicly** and explain how their behavior affect others, preferably for the place where e happen. If possible, public communication go show the rest of the community say you dey serious about the code of conduct. Make you dey kind but firm for your communication. + +- **Privately reach out to the person** wey dey involved to explain how their behavior affect others. You fit use private communication channel if the situation get sensitive personal information. If you communicate privately with person, e good make you CC those wey first report the situation, so dem go know say you don take action. Ask the person wey report make e agree before you CC am. + +Sometimes, you fit no fit resolve the matter. The person wey dey involved fit dey aggressive or hostile when you confront am, or e no fit change their behavior. For this kind situation, you fit consider stronger action. For example: + +- **Suspend the person** wey dey involved for the project, you go enforce am through temporary ban wey go stop am from participating for any aspect of the project. + +- **Permanently ban** the person from the project. + +Make you no take banning members lightly, e be like say e be something wey no fit change and no fit reconcile different perspectives. You suppose only take these measures if e clear say you no fit resolve the matter. + +## The work waeh you fit do as a maintainer + +Code of conduct nor be law wey dem just dey put as dem like. Na you be the enforcer of the code of conduct and e dey your responsibility to follow the rules wey the code of conduct don establish. + +As a maintainer, na you set the guidelines for your community and you go enforce those guidelines based on the rules wey dey your code of conduct. This one mean say, any report wey you receive about code of conduct violation, you suppose take am serious. The person wey report the matter suppose get thorough and fair review of wetin dem complain. If you come find out say the behavior wey dem report nor be violation, make you yan that one give dem straight and explain why you nor go take action on top am. As dem see that one, na them sabi how dem go fit take the behavior wey dem dey complain tolerate, or dem fit stop to dey participate for the community. + +If person report behavior wey nor _technically_ violate the code of conduct, e fit still show say there be problem for your community, and you suppose investigate this potential problem and take action as e dey necessary. This one fit include say you go revise your code of conduct to make am clear the kind behavior wey dem go accept, or make you talk to the person wey dem report say e dey skirt the edge of wetin dem expect and e dey make some participants dey uncomfortable, although e nor violate the code of conduct. + +In the end, as a maintainer, na you dey set and enforce the standards for acceptable behavior. You get the power to shape the community values of the project, and participants dey expect make you enforce those values in a way wey dey fair and even-handed. + +## Encourage the character wey you want make people see for this world 🌎 + +When person see say one project nor dey friendly or e nor dey welcoming, even if e just one person behavior people still dey tolerate, e fit make plenty contributors run comot, some of dem wey you never go fit even see. E nor dey always easy to adopt or enforce code of conduct, but if you dey promote environment wey dey welcoming, e go help your community grow. diff --git a/_articles/pidgin/finding-users.md b/_articles/pidgin/finding-users.md new file mode 100644 index 00000000000..a1b620e1ed3 --- /dev/null +++ b/_articles/pidgin/finding-users.md @@ -0,0 +1,144 @@ +--- +lang: pidgin +title: How to find the people to helep your project +description: You go helep your open source project grow if you bin put am with people waeh dey happy happy. +class: finding +order: 3 +image: /assets/images/cards/finding.png +related: + - beginners + - building +--- + +## Dey talk the koko + +Dem nor get law wey talk say you suppose promote open source project when you first launch am. Plenty reasons dey wey fit make person dey work for open source wey nor get to do with popularity. Instead make you hope say other people go find and use your open source project, you suppose spread the word about your hard work! + +## Make you dey find your message + +Before you start the real work of promotion for your project, you suppose sabi explain wetin your project dey do, and why e dey important. + +Wetin make your project different or interesting? Why you create am? As you dey think about your project's message and value, try look am through the eyes of the people wey fit use am and those wey fit contribute to am. + +For example, @robb dey use code examples to yan clearly why him project, [Cartography](https://github.com/robb/Cartography), dey useful: + +![Cartography README](/assets/images/finding-users/cartography.jpg) + +If you wan go deeper for messaging, check Mozilla's ["Personas and Pathways"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) exercise for developing user personas. + +## Helep people to dey find and folow your project + + + +**Make you get clear handle to promote your work.** Twitter handle, GitHub URL, or IRC channel na easy way wey you fit use point people to your project. These outlets still dey give your project's growing community place wey dem go fit gather. + +If you nor wan set up outlets for your project now, make you dey promote your own Twitter or GitHub handle for everything wey you dey do. Promoting your Twitter or GitHub handle go show people how dem fit take contact you or follow your work. If you go talk for meeting or event, make you sure say your contact information dey for your bio or slides. + + + +**Make you think about create website for your project.** Website dey make your project dey friendly and easy to navigate, especially when you combine am with clear documentation and tutorials. Having website still show say your project dey active and e go make your audience feel comfortable say dem fit use am. Give examples to show people as dem fit take use your project. + +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), co-creator of Django, talk say website na _"by far the best thing we did with Django in the early days"_. + +If your project dey for GitHub, you fit use [GitHub Pages](https://pages.github.com/) create website. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/), and [Middleman](https://middlemanapp.com/) na [few examples](https://github.com/showcases/github-pages-examples) of excellent, comprehensive websites. + +![Vagrant homepage](/assets/images/finding-users/vagrant_homepage.png) + +Now wey you don get message for your project and easy way wey people fit take find your project, make you waka comot go yan with your audience! + +## Go where your project's audience dey (online) + +Online outreach na correct way wey you fit take share and spread the word quickly. As you use online channels, e fit help you reach wide audience. + +Make you use existing online communities and platforms to reach your audience. If your open source project na software project, e possible say you fit find your audience for [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 wey you believe say people go benefit well or go dey excited about your work. + + + +See as you fit find ways to share your project well: + +* **Know the relevant open source projects and communities.** Sometimes, you nor need promote your project directly. If your project dey perfect for data scientists wey dey use Python, make you sabi the Python data science community. As people sabi you, opportunities go naturally show face to talk about and share your work. +* **Find people wey dey face the problem wey your project solve.** Search through forums wey relate to your project's target audience, and try to answer their questions. If e dey right, find polite way to suggest your project as solution. +* **Ask for feedback.** Introduce yourself and your work to audience wey your project fit benefit. Make you specific about the people wey you think say your project go fit help. Try to complete the sentence: _"I think my project go really help X, people wey dey try do Y_". Listen and respond to others' feedback, rather than just promoting your work. + +Generally, focus on helping others before you ask for something in return. Because anybody fit easily promote project online, e go get plenty noise. To stand out from the crowd, give people background about who you be, nor be just wetin you want. + +If nobody pay attention or respond to your initial outreach, nor let am discourage you! Most project launches nor dey one-time thing, e fit take months or years. If you nor get response the first time, try different method, or look for ways to add value to other people's work first. Promotion and launch of your project go take time and dedication. + +## Waka go where your project's audience dey (offline) + +![Public speaking](/assets/images/finding-users/public_speaking.jpg) + +Offline events dey very popular to promote new projects to people. Dem be very good way to reach audience wey dey engage and build better human connections, especially if you wan reach developers. + +If you be [newbie for public speaking](https://speaking.io/), you fit start by dey find local meetup wey relate to the language or system wey your project dey based on. + + + +If you never talk for event before, e dey normal to feel nervous! Just remember say the people wey dey the audience dey there because dem really wan hear wetin you wan talk about. + +As you dey write your talk, try focus on the things wey your audience go find interesting and get value from. Make your language dey friendly and approachable. Smile, breathe well, and enjoy yourself. + + + +When you feel say you don ready, try consider talk for conference to promote your project. Conferences fit help you reach plenty people, sometimes from different parts of the world. + +Find conferences wey relate to the language or system wey your project dey use. Before you submit your talk, try do research about the conference so that you fit arrange your talk to match the people wey go attend and increase your chance to talk for the conference. Sometimes you fit know the kind of audience wey you wan get by checking the people wey don talk for the conference before. + + + +## Kulekule your reputation + +Apart from the strategies wey we don yarn before, the best way to invite people to share and contribute to your project na to share and contribute to their projects. + +To help newcomers, share resources, and make thoughtful contributions to other people's projects go help you build positive reputation. To be an active member for open source community go help people to understand wetin you dey do, and dem fit dey pay attention to and share your project. To dey develop relationships with other open source projects fit even lead to official partnerships. + + + +E no dey too early or too late to begin build your reputation. Even if you don launch your own project before, dey always look for ways to help others. + +No get quick fix wey go give you audience. To gain the trust and respect of others dey take time, and building your reputation no dey end. + +## No relent! + +E fit tey before people go notice your open source project. E dey okay! Some of the most popular projects wey dey today, e take years before dem reach the level wey dem dey now. Focus on building relationships instead of dey hope say your project go just blow. Be patient, and continue to dey share your work with those wey dey appreciate am. From b5866e42a91b83fdcb7b53ab6a58afa6e974c15e Mon Sep 17 00:00:00 2001 From: Elizabeth Orji Date: Sat, 6 Jan 2024 00:01:58 +0100 Subject: [PATCH 4/8] Changed pidgin to PCM --- _articles/{pidgin => pcm}/best-practice.md | 0 _articles/{pidgin => pcm}/building-community.md | 0 _articles/{pidgin => pcm}/code-of-conduct.md | 0 _articles/{pidgin => pcm}/finding-users.md | 0 _data/locales/{pidgin.yml => pcm.yml} | 0 5 files changed, 0 insertions(+), 0 deletions(-) rename _articles/{pidgin => pcm}/best-practice.md (100%) rename _articles/{pidgin => pcm}/building-community.md (100%) rename _articles/{pidgin => pcm}/code-of-conduct.md (100%) rename _articles/{pidgin => pcm}/finding-users.md (100%) rename _data/locales/{pidgin.yml => pcm.yml} (100%) diff --git a/_articles/pidgin/best-practice.md b/_articles/pcm/best-practice.md similarity index 100% rename from _articles/pidgin/best-practice.md rename to _articles/pcm/best-practice.md diff --git a/_articles/pidgin/building-community.md b/_articles/pcm/building-community.md similarity index 100% rename from _articles/pidgin/building-community.md rename to _articles/pcm/building-community.md diff --git a/_articles/pidgin/code-of-conduct.md b/_articles/pcm/code-of-conduct.md similarity index 100% rename from _articles/pidgin/code-of-conduct.md rename to _articles/pcm/code-of-conduct.md diff --git a/_articles/pidgin/finding-users.md b/_articles/pcm/finding-users.md similarity index 100% rename from _articles/pidgin/finding-users.md rename to _articles/pcm/finding-users.md diff --git a/_data/locales/pidgin.yml b/_data/locales/pcm.yml similarity index 100% rename from _data/locales/pidgin.yml rename to _data/locales/pcm.yml From 0a40a96523fa127959497956430c6e1d879d7630 Mon Sep 17 00:00:00 2001 From: Eric Sorenson Date: Fri, 12 Jan 2024 15:49:55 -0800 Subject: [PATCH 5/8] Apply suggestions from code review Fixing up the metadata --- _articles/pcm/code-of-conduct.md | 2 +- _articles/pcm/finding-users.md | 2 +- _data/locales/pcm.yml | 4 ++-- assets/css/translate.scss | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/_articles/pcm/code-of-conduct.md b/_articles/pcm/code-of-conduct.md index d008849c68f..646f2a49d68 100644 --- a/_articles/pcm/code-of-conduct.md +++ b/_articles/pcm/code-of-conduct.md @@ -1,5 +1,5 @@ --- -lang: pidgin +lang: pcm title: Una Code of Conduct description: Make community people dey behave well and do constructive tins, by accepting and enforcing the code of conduct. class: coc diff --git a/_articles/pcm/finding-users.md b/_articles/pcm/finding-users.md index a1b620e1ed3..09b6ddd00d6 100644 --- a/_articles/pcm/finding-users.md +++ b/_articles/pcm/finding-users.md @@ -1,5 +1,5 @@ --- -lang: pidgin +lang: pcm title: How to find the people to helep your project description: You go helep your open source project grow if you bin put am with people waeh dey happy happy. class: finding diff --git a/_data/locales/pcm.yml b/_data/locales/pcm.yml index 7a6a648f6dd..6be4951f1f1 100644 --- a/_data/locales/pcm.yml +++ b/_data/locales/pcm.yml @@ -1,5 +1,5 @@ -en: - locale_name: English +pcm: + locale_name: Pidgin nav: about: About contribute: Put hand diff --git a/assets/css/translate.scss b/assets/css/translate.scss index 4d183d220fd..b913b0d43b0 100644 --- a/assets/css/translate.scss +++ b/assets/css/translate.scss @@ -27,7 +27,7 @@ $section_translation: ( "tr": "", "zh-hant": "章節", "zh-hans": "章节", - "pidgin": "Portion", + "pcm": "Portion", ); @each $locale, $translation in $section_translation { From bbd67b221965d46013bcbb99a433e7a0569d5f3a Mon Sep 17 00:00:00 2001 From: Eric Sorenson Date: Fri, 12 Jan 2024 16:51:17 -0800 Subject: [PATCH 6/8] Fix test failures - Markdown style wants `*` not `-` for lists - Removed some extra blank lines - The `retext-repeated-words` plugin has only a small list of words that are allowed to be repeated, but pidgin uses doubled words as intensifiers ("small small" for "very small"). I added hyphens ("small-small") because I saw some examples of that - Renamed the `best-practice.md` -> `best-practices.md` to match the rest of the site - Copied the untranslated articles in so the site build works --- .../{best-practice.md => best-practices.md} | 20 +- _articles/pcm/building-community.md | 4 +- _articles/pcm/code-of-conduct.md | 22 +- _articles/pcm/getting-paid.md | 178 ++++++ _articles/pcm/how-to-contribute.md | 526 ++++++++++++++++++ _articles/pcm/leadership-and-governance.md | 156 ++++++ _articles/pcm/legal.md | 160 ++++++ ...ing-balance-for-open-source-maintainers.md | 220 ++++++++ _articles/pcm/metrics.md | 128 +++++ _articles/pcm/starting-a-project.md | 356 ++++++++++++ 10 files changed, 1746 insertions(+), 24 deletions(-) rename _articles/pcm/{best-practice.md => best-practices.md} (96%) create mode 100644 _articles/pcm/getting-paid.md create mode 100644 _articles/pcm/how-to-contribute.md create mode 100644 _articles/pcm/leadership-and-governance.md create mode 100644 _articles/pcm/legal.md create mode 100644 _articles/pcm/maintaining-balance-for-open-source-maintainers.md create mode 100644 _articles/pcm/metrics.md create mode 100644 _articles/pcm/starting-a-project.md diff --git a/_articles/pcm/best-practice.md b/_articles/pcm/best-practices.md similarity index 96% rename from _articles/pcm/best-practice.md rename to _articles/pcm/best-practices.md index 195f3d1d556..069470ed728 100644 --- a/_articles/pcm/best-practice.md +++ b/_articles/pcm/best-practices.md @@ -1,5 +1,5 @@ --- -lang: pidgin +lang: pcm title: Best Practices for Maintainers description: Learn how to make your life easy as an open source maintainer, from documentation to community collaboration. Make sense of maintaining open source projects with these top-notch tips. class: best-practices @@ -42,16 +42,16 @@ As @lord don talk, project vision fit help you know wetin you go fit work on. As E fit hard you to write down rules. Sometimes you fit think say you dey police people or say you dey dull dem vibe. -But if you write rules fairly and you dey follow am, e go empower you. E go prevent you from doing tins wey you no like. People wey see your project fit no sabi your condition or circumstances. Dem fit think say dem dey pay you for the work wey you dey do, especially if na wetin dem dey use well well. Dem fit even think say you dey busy with new work or family matter. +But if you write rules fairly and you dey follow am, e go empower you. E go prevent you from doing tins wey you no like. People wey see your project fit no sabi your condition or circumstances. Dem fit think say dem dey pay you for the work wey you dey do, especially if na wetin dem dey use well-well. Dem fit even think say you dey busy with new work or family matter. E good make people sabi dis tins. If to maintain your project na part-time or you dey do am because you volunteer, make you talk the time wey you get. E no be say na the time wey your project need or wetin people dey ask you for, na the time wey you get na e you go talk. E fit good if you write down some rules like: -- How dem go review contribution (dem need test? Issue template?) -- The kind of contribution wey dem go accept (you wan make dem help you with specific part of your code?) -- When e go make sense for dem to follow up (e.g., "you fit expect response from maintainer within 7 days, if you no see any response by then, you fit ping the thread") -- How much time you dey spend for the project (e.g., "we dey spend like 5 hours per week on this project") +* How dem go review contribution (dem need test? Issue template?) +* The kind of contribution wey dem go accept (you wan make dem help you with specific part of your code?) +* When e go make sense for dem to follow up (e.g., "you fit expect response from maintainer within 7 days, if you no see any response by then, you fit ping the thread") +* How much time you dey spend for the project (e.g., "we dey spend like 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) na some examples of projects wey get rules for maintainers and contributors. @@ -65,7 +65,7 @@ If you meet other maintainers or you take big decision for private, write the co You don write down wetin you want, but people never read your documentation well. Sometimes you go still remind them say knowledge dey your documentation. -Saying no no dey fun, but make you try yarn "Your contribution no dey follow this project criteria" e no too personal like "I no like your contribution." +Saying "no" no dey fun, but make you try yarn "Your contribution no dey follow this project criteria" e no too personal like "I no like your contribution." You go fit yarn no for plenty situations wey you go see as maintainer like feature requests wey no follow your project plan or person wey dey disturb discussion. @@ -89,7 +89,7 @@ If you come across one contribution wey you no wan accept, your first reaction f No just allow one contribution wey you no want dey open because you dey feel bad or you dey try to dey nice. As time dey go, the issues and PRs wey you never answer go make your project come dey feel like say e too stress you and dey intimidate you. -E better make you quick-close contributions wey you sabi say you no wan accept am. If your project don already gather plenti matter wey never resolve, @steveklabnik get some advice on [how to quickly arrange the issues] so e go dey efficient. (https://words.steveklabnik.com/how-to-be-an-open-source-gardener). +E better make you quick-close contributions wey you sabi say you no wan accept am. If your project don already gather plenti matter wey never resolve, @steveklabnik get some advice on [how to quickly arrange the issues](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) so e go dey efficient. If you no wan accept one contribution: @@ -245,7 +245,7 @@ Just like any other work, make you dey take regular breaks so you go dey refresh avatar In maintaining WP-CLI, I've discovered I need to make myself happy first, and set clear boundaries on my involvement. The best balance I've found is 2-5 hours per week, as a part of my normal work schedule. This keeps my involvement a passion, and from feeling too much like work. Because I prioritize the issues I'm working on, I can make regular progress on what I think is most important.

-— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://web.archive.org/web/20220306014037/https/danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/) +— @danielbachhuber, ["My condolences, you're now the maintainer of a popular open source project"](https://web.archive.org/web/20220306014037/https://danielbachhuber.com/2016/06/26/my-condolences-youre-now-the-maintainer-of-a-popular-open-source-project/)

@@ -257,4 +257,4 @@ Taking breaks no only apply to vacations, e fit include say you no wan do open s ## Make you dey take care of yourself first! -To maintaining one popular project require different skills from the first first time of growth, but e no dey less rewarding. As one maintainer, you go dey practice leadership and personal skills for one level wey few people fit experience. Though e no dey easy to manage, setting clear boundaries and only taking on wetin you dey comfortable with go help you dey happy, refreshed, and productive. +To maintaining one popular project require different skills from the first-first time of growth, but e no dey less rewarding. As one maintainer, you go dey practice leadership and personal skills for one level wey few people fit experience. Though e no dey easy to manage, setting clear boundaries and only taking on wetin you dey comfortable with go help you dey happy, refreshed, and productive. diff --git a/_articles/pcm/building-community.md b/_articles/pcm/building-community.md index 315c2037cd2..1db3fef4f81 100644 --- a/_articles/pcm/building-community.md +++ b/_articles/pcm/building-community.md @@ -141,7 +141,7 @@ You no go fit talk with most people wey go show for your project. Some people fi - ### Choose your battles with sense Context dey important. Think about the people wey dey the discussion and how them represent the rest of the community. diff --git a/_articles/pcm/code-of-conduct.md b/_articles/pcm/code-of-conduct.md index 646f2a49d68..93287322020 100644 --- a/_articles/pcm/code-of-conduct.md +++ b/_articles/pcm/code-of-conduct.md @@ -24,10 +24,10 @@ Make you try your best to arrange code of conduct early, if you fit, ideally whe Apart from just communicating your expectations, code of conduct fit describe the following: -- Where the code of conduct dey apply _(only on issues and pull requests, or community activities like events?)_ -- Whom the code of conduct dey apply to _(community members and maintainers, but what about sponsors?)_ -- Wetin go happen if person violate the code of conduct -- How person fit report violations +* Where the code of conduct dey apply _(only on issues and pull requests, or community activities like events?)_ +* Whom the code of conduct dey apply to _(community members and maintainers, but what about sponsors?)_ +* Wetin go happen if person violate the code of conduct +* How person fit report violations Anywhere way you fit, try to use previous example. The [Contributor Covenant](https://contributor-covenant.org/) na code of conduct wey many open source projects, including Kubernetes, Rails, and Swift, don use, and e fit serve as example. @@ -46,11 +46,11 @@ Put one CODE_OF_CONDUCT file for your project's main directory, and make sure sa You suppose explain how you go enforce your code of conduct **_before_** person violate am. Some reasons why you suppose do am be say: -- E show say you dey serious about action when e dey necessary. +* E show say you dey serious about action when e dey necessary. -- Your community go dey reassured say complaints go dey reviewed. +* Your community go dey reassured say complaints go dey reviewed. -- You go reassure your community say the review process go dey fair and transparent, if at any time dem dey investigated for violation. +* You go reassure your community say the review process go dey fair and transparent, if at any time dem dey investigated for violation. You suppose give people private way (like email address) to report code of conduct violation and explain who go receive that report. E fit be maintainer, group of maintainers, or code of conduct working group. @@ -87,15 +87,15 @@ If person report say somebody violate the code of conduct, e na you suppose hand You fit respond to code of conduct violation for different ways: -- **Warn the person wey dey involved publicly** and explain how their behavior affect others, preferably for the place where e happen. If possible, public communication go show the rest of the community say you dey serious about the code of conduct. Make you dey kind but firm for your communication. +* **Warn the person wey dey involved publicly** and explain how their behavior affect others, preferably for the place where e happen. If possible, public communication go show the rest of the community say you dey serious about the code of conduct. Make you dey kind but firm for your communication. -- **Privately reach out to the person** wey dey involved to explain how their behavior affect others. You fit use private communication channel if the situation get sensitive personal information. If you communicate privately with person, e good make you CC those wey first report the situation, so dem go know say you don take action. Ask the person wey report make e agree before you CC am. +* **Privately reach out to the person** wey dey involved to explain how their behavior affect others. You fit use private communication channel if the situation get sensitive personal information. If you communicate privately with person, e good make you CC those wey first report the situation, so dem go know say you don take action. Ask the person wey report make e agree before you CC am. Sometimes, you fit no fit resolve the matter. The person wey dey involved fit dey aggressive or hostile when you confront am, or e no fit change their behavior. For this kind situation, you fit consider stronger action. For example: -- **Suspend the person** wey dey involved for the project, you go enforce am through temporary ban wey go stop am from participating for any aspect of the project. +* **Suspend the person** wey dey involved for the project, you go enforce am through temporary ban wey go stop am from participating for any aspect of the project. -- **Permanently ban** the person from the project. +* **Permanently ban** the person from the project. Make you no take banning members lightly, e be like say e be something wey no fit change and no fit reconcile different perspectives. You suppose only take these measures if e clear say you no fit resolve the matter. diff --git a/_articles/pcm/getting-paid.md b/_articles/pcm/getting-paid.md new file mode 100644 index 00000000000..7fd4a32af4c --- /dev/null +++ b/_articles/pcm/getting-paid.md @@ -0,0 +1,178 @@ +--- +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 +order: 7 +image: /assets/images/cards/getting-paid.png +related: + - best-practices + - leadership +--- + +## Why some people seek financial support + +Much of the work of open source is voluntary. 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 +* [Zalando](https://opensource.zalando.com) published its [open source contribution policy](https://opensource.zalando.com/docs/using/contributing/) for employees + +Projects that originated at a large company, such as [Go](https://github.com/golang) or [React](https://github.com/facebook/react), will also likely employ people to work on open source. + +Depending on your personal circumstances, you can try raising money independently to fund your open source work. For example: + +* @Homebrew (and [many other maintainers and organizations](https://github.com/sponsors/community)) fund their work through [GitHub Sponsors](https://github.com/sponsors) +* @gaearon funded his work on [Redux](https://github.com/reactjs/redux) through a [Patreon crowdfunding campaign](https://redux.js.org/) +* @andrewgodwin funded work on Django schema migrations [through a Kickstarter campaign](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) + +Finally, sometimes open source projects put bounties on issues that you might consider helping with. + +* @ConnorChristie was able to get paid for [helping](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol work on their JavaScript library [through a bounty on gitcoin](https://gitcoin.co/). +* @mamiM did Japanese translations for @MetaMask after the [issue was funded on Bounties Network](https://explorer.bounties.network/bounty/134). + +## Finding funding for your project + +Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work. + +Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing in 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) +* **[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/cli) 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/pcm/how-to-contribute.md b/_articles/pcm/how-to-contribute.md new file mode 100644 index 00000000000..196c21f34d4 --- /dev/null +++ b/_articles/pcm/how-to-contribute.md @@ -0,0 +1,526 @@ +--- +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 +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 software you rely on + +Lots of open source contributors start by being users of software they contribute to. When you find a bug in an open source software you use, you may want to look at the source to see if you can patch it yourself. If that's the case, then contributing the patch back is the best way to ensure that your friends (and yourself when you update to the next release) will be able to benefit from it. + +### Improve existing skills + +Whether it's coding, user interface design, graphic design, writing, or organizing, if you're looking for practice, there's a task for you on an open source project. + +### 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, [like @CBID2 did for OpenSauced's documentation](https://github.com/open-sauced/docs/pull/151) +* Curate a folder of examples showing how the project is used +* Start a newsletter for the project, or curate highlights from the mailing list, [like @opensauced did for their product](https://news.opensauced.pizza/about/) +* 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, [like @frontendwizard did for the instructions for freeCodeCamp's CSS Flexbox challenge](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077) + + + +### 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. A good example of an effective Contributing Guide would be the one from [Codecademy's Docs repository](https://www.codecademy.com/resources/docs/contribution-guide). +* **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 like [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs). + +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 whether its to improve a contributor's line of code, grammar usage, use of images, etc. Some projects, such as [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint-fix.yml), use certain GitHub Action flows to automate and quicken their code reviews. +* **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. A good example of this would be [CHAOSS' weekly Newsletter](https://chaoss.community/news/) +* **Synchronous chat channel:** Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges. A good example of this would be [EddieHub's Discord community](http://discord.eddiehub.org/). + +## 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! + +> According to a study conducted by Igor Steinmacher and other Computer Science researchers, [28% of casual contributions](https://www.igor.pro.br/publica/papers/saner2016.pdf) to open source are documentation, such as typo fixes, reformatting, or writing a translation. + +If you're looking for existing issues you can fix, every open source project has a `/contribute` page that highlights beginner-friendly issues you can start out with. Navigate to the main page of the repository on GitHub, and add `/contribute` at the end of the URL (for example [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)). + +You can also use one of the following resources to help you discover and contribute to new projects: + +* [GitHub Explore](https://github.com/explore/) +* [Open Source Friday](https://opensourcefriday.com) +* [First Timers Only](https://www.firsttimersonly.com/) +* [CodeTriage](https://www.codetriage.com/) +* [24 Pull Requests](https://24pullrequests.com/) +* [Up For Grabs](https://up-for-grabs.net/) +* [First Contributions](https://firstcontributions.github.io) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) +* [OpenSauced](https://opensauced.pizza/) + +### 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 main branch. On GitHub, you can see this information in the Insights tab of a repository's homepage, such as[Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse) + +
+ + +
+ +
+ + +
+ +
+ + +
+ +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 it 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 doing the following: + +* **Raising an Issue:** These are like starting a conversation or discussion +* **Pull requests** are for starting work on a solution. +* **Communication Channels:** If the project has a designated Discord, IRC, or Slack channel, consider starting a conversation or asking for clarification about your contribution. + +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 small fixes such as 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 open it as a "draft" or mark as a "WIP" (Work in Progress) in the subject line or "Notes to Reviewers" sections if provided (or you can just create your own. Like this: `**## Notes to Reviewer**`). 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. It's important to 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 your contribution + +Before we start celebrating, one of the following will happen after you submit your contribution: + +### 😭 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 give a polite reminder and still do not receive a response, it's possible that nobody will ever respond. It's not a great feeling, but don't let that discourage you! 😄 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. A good example of this would be [the feedback that another contributor has given to @a-m-lamb on their pull request to Codecademy's Docs](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286). + +If you don't have time to work on the issue anymore due to reasons such as the conversation has been going on for months, and your circumstances have changed or you're unable to find a solution, let the maintainer know so that they can open the issue for someone else, like [@RitaDee did for an issue at OpenSauced's app repository](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346). + +### 👎 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/pcm/leadership-and-governance.md b/_articles/pcm/leadership-and-governance.md new file mode 100644 index 00000000000..6fd75930d5d --- /dev/null +++ b/_articles/pcm/leadership-and-governance.md @@ -0,0 +1,156 @@ +--- +lang: en +title: Leadership and Governance +description: Growing open source projects can benefit from formal rules for making decisions. +class: leadership +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/HEAD/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](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/). + +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-node-js-collection/healthy-open-source-967fa8be7951) + +## 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://foundation.nodejs.org/) helps support [Express.js](https://expressjs.com/), a Node-based framework. diff --git a/_articles/pcm/legal.md b/_articles/pcm/legal.md new file mode 100644 index 00000000000..30d391b2f76 --- /dev/null +++ b/_articles/pcm/legal.md @@ -0,0 +1,160 @@ +--- +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 +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, with this guide you don't have to start from scratch. (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 to explicitly give these permissions with a license. + +These rules also apply when someone contributes to your project. Without a license or other agreement in place, any contributions are exclusively owned by their authors. That means nobody -- not even you -- can use, copy, distribute, or modify their contributions. + +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/en/github/site-policy/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), which allows others to view and fork your project, but your work otherwise comes with no permissions. + +If you want others to use, distribute, modify, or contribute back to your project, you need to include an open source license. For example, someone cannot legally use any part of your GitHub project in their code, even if it's public, unless you explicitly give them the right to do so. + +## 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 [popular open source licenses](https://innovationgraph.github.com/global-metrics/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? + +It's hard to go wrong with the [MIT License](https://choosealicense.com/licenses/mit/) if you're starting with a blank slate. It's short, easily understood, 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**, each of which will have its own open source license with terms you have to respect. For example, if you're open sourcing a Node.js project, you'll probably use libraries from the Node Package Manager (npm). + +Dependencies with **permissive licenses** like [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc), and [BSD](https://choosealicense.com/licenses/bsd-3-clause) allow you to license your project however you want. + +Dependencies with **copyleft licenses** require closer attention. Including any library with a "strong" copyleft license like the [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), or [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) requires you to choose an identical or [compatible license](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) for your project. Libraries with a "limited" or "weak" copyleft license like the [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) and [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) can be included in projects with any license, provided you follow the [additional rules](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) they specify. + +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 may be comforted by an express patent license from all contributors. In this case, the [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) (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 policies for open source project licensing. Some companies require your projects to bear a permissive license to permit integration with the company's proprietary products. Other policies enforce a strong copyleft license and an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)) so only your company can use the project in closed source software. Organizations may also have certain standards, social responsibility goals, or transparency needs which could require a particular licensing strategy. Talk to your [company's legal department](#what-does-my-companys-legal-team-need-to-know) for guidance. + +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 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 at the first hint of any desire to change licenses. Even if you have or can obtain permission from your project's copyright holders for a license change, consider the impact of the change on your project's other users and contributors. Think of a license change as a "governance event" for your project that will more likely go smoothly with clear communications and consultation with your project's stakeholders. All the more reason to choose and use an appropriate license for your project from its inception! + +**Your project's existing license.** If your project's existing license is compatible with the license you want to change to, you could just start using the new license. That's because if license A is compatible with license B, you'll comply with the terms of A while complying with the terms of B (but not necessarily vice versa). So if you're currently using a permissive license (e.g., MIT), you could change to a license with more conditions, so long as you retain a copy of the MIT license and any associated copyright notices (i.e., continue to comply with the MIT license's minimal conditions). But if your current license is not permissive (e.g., copyleft, or you don't have a license) and you aren't the sole copyright holder, you couldn't just change your project's license to MIT. Essentially, with a permissive license the project's copyright holders have given permission in advance to change licenses. + +**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](https://github.com/thehale/git-authorship) 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 pre-approve certain license changes via an additional contributor agreement ([see below](#does-my-project-need-an-additional-contributor-agreement)). 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/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license). + +An additional contributor agreement -- often called a Contributor License Agreement (CLA) -- can create administrative work for project maintainers. How much work an agreement adds depends on the project and implementation. A simple agreement might require that contributors confirm, with a click, that they have the rights necessary to contribute under the project open source license. A more complicated agreement might require legal review and sign-off from contributors' employers. + +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://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement. +* You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco). +* Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0. +* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement. +* You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes. + +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](#which-open-source-license-is-appropriate-for-my-project)). 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](#which-open-source-license-is-appropriate-for-my-project)). + +* **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/23/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/blog/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/pcm/maintaining-balance-for-open-source-maintainers.md b/_articles/pcm/maintaining-balance-for-open-source-maintainers.md new file mode 100644 index 00000000000..c418b476786 --- /dev/null +++ b/_articles/pcm/maintaining-balance-for-open-source-maintainers.md @@ -0,0 +1,220 @@ +--- +lang: en +untranslated: true +title: Maintaining Balance for Open Source Maintainers +description: Tips for self-care and avoiding burnout as a maintainer. +class: balance +order: 0 +image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png +--- + +As an open source project grows in popularity, it becomes important to set clear boundaries to help you maintain balance to stay refreshed and productive for the long run. + +To gain insights into the experiences of maintainers and their strategies for finding balance, we ran a workshop with 40 members of the Maintainer Community, allowing us to learn from their firsthand experiences with burnout in open source and the practices that have helped them maintain balance in their work. This is where the concept of personal ecology comes into play. + +So, what is personal ecology? As described by the Rockwood Leadership Institute, it involves "maintaining balance, pacing, and efficiency to sustain our energy over a lifetime." This framed our conversations, helping maintainers recognize their actions and contributions as parts of a larger ecosystem that evolves over time. Burnout, a syndrome resulting from chronic workplace stress as [defined by the WHO](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), is not uncommon among maintainers. This often leads to a loss of motivation, an inability to focus, and a lack of empathy for the contributors and community you work with. + + + +By embracing the concept of personal ecology, maintainers can proactively avoid burnout, prioritize self-care, and uphold a sense of balance to do their best work. + +## Tips for Self-Care and Avoiding Burnout as a Maintainer: + +### Identify your motivations for working in open source + +Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus. + +### Reflect on what causes you to get out of balance and stressed out + +It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers: + +* **Lack of positive feedback:** Users are far more likely to reach out when they have a complaint. If everything works great, they tend to stay silent. It can be discouraging to see a growing list of issues without the positive feedback showing how your contributions are making a difference. + + + +* **Not saying 'no':** It can be easy to take on more responsibilities than you should on an open source project. Whether it's from users, contributors, or other maintainers – we can't always live up to their expectations. + + + +* **Working alone:** Being a maintainer can be incredibly lonely. Even if you work with a group of maintainers, the past few years have been difficult for convening distributed teams in-person. + + + +* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project. + + + +* **Conflicting demands:** Open source is full of groups with different motivations, which can be difficult to navigate. If you're paid to do open source, your employer's interests can sometimes be at odds with the community. + + + +### Watch out for signs of burnout + +Can you keep up your pace for 10 weeks? 10 months? 10 years? + +There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) that can help you reflect on your current pace and see if there are any adjustments you can make. Some maintainers also use wearable technology to track metrics like sleep quality and heart rate variability (both linked to stress). + + + +### What would you need to continue sustaining yourself and your community? + +This will look different for each maintainer, and will change depending on your phase of life and other external factors. But here are a few themes we heard: + +* **Lean on the community:** Delegation and finding contributors can alleviate the workload. Having multiple points of contact for a project can help you take a break without worrying. Connect with other maintainers and the wider community–in groups like the [Maintainer Community](http://maintainers.github.com/). This can be a great resource for peer support and learning. + + You can also look for ways to engage with the user community, so you can regularly hear feedback and understand the impact of your open source work. + +* **Explore funding:** Whether you're looking for some pizza money, or trying to go full time open source, there are many resources to help! As a first step, consider turning on [GitHub Sponsors](https://github.com/sponsors) to allow others to sponsor your open source work. If you're thinking about making the jump to full-time, apply for the next round of [GitHub Accelerator](http://accelerator.github.com/). + + + +* **Use tools:** Explore tools like [GitHub Copilot](https://github.com/features/copilot/) and [GitHub Actions](https://github.com/features/actions) to automate mundane tasks and free up your time for more meaningful contributions. + + + +* **Rest and recharge:** Make time for your hobbies and interests outside of open source. Take weekends off to unwind and rejuvenate–and set your [GitHub status](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) to reflect your availability! A good night's sleep can make a big difference in your ability to sustain your efforts long-term. + + If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day. + + + +* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time. + + + + Learn to be firm in shutting down toxic behavior and negative interactions. It's okay to not give energy to things you don't care about. + + + + + +Remember, personal ecology is an ongoing practice that will evolve as you progress in your open source journey. By prioritizing self-care and maintaining a sense of balance, you can contribute to the open source community effectively and sustainably, ensuring both your well-being and the success of your projects for the long run. + +## Additional Resources + +* [Maintainer Community](http://maintainers.github.com/) +* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon +* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg +* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge +* [SustainOSS](https://sustainoss.org/) +* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/) +* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid +* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com) +* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series + +## Contributors + +Many thanks to all the maintainers who shared their experiences and tips with us for this guide! + +This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: + +[@agnostic-apollo](https://github.com/agnostic-apollo) +[@AndreaGriffiths11](https://github.com/AndreaGriffiths11) +[@antfu](https://github.com/antfu) +[@anthonyronda](https://github.com/anthonyronda) +[@CBID2](https://github.com/CBID2) +[@Cli4d](https://github.com/Cli4d) +[@confused-Techie](https://github.com/confused-Techie) +[@danielroe](https://github.com/danielroe) +[@Dexters-Hub](https://github.com/Dexters-Hub) +[@eddiejaoude](https://github.com/eddiejaoude) +[@Eugeny](https://github.com/Eugeny) +[@ferki](https://github.com/ferki) +[@gabek](https://github.com/gabek) +[@geromegrignon](https://github.com/geromegrignon) +[@hynek](https://github.com/hynek) +[@IvanSanchez](https://github.com/IvanSanchez) +[@karasowles](https://github.com/karasowles) +[@KoolTheba](https://github.com/KoolTheba) +[@leereilly](https://github.com/leereilly) +[@ljharb](https://github.com/ljharb) +[@nightlark](https://github.com/nightlark) +[@plarson3427](https://github.com/plarson3427) +[@Pradumnasaraf](https://github.com/Pradumnasaraf) +[@RichardLitt](https://github.com/RichardLitt) +[@rrousselGit](https://github.com/rrousselGit) +[@sansyrox](https://github.com/sansyrox) +[@schlessera](https://github.com/schlessera) +[@shyim](https://github.com/shyim) +[@smashah](https://github.com/smashah) +[@ssalbdivad](https://github.com/ssalbdivad) +[@The-Compiler](https://github.com/The-Compiler) +[@thehale](https://github.com/thehale) +[@thisisnic](https://github.com/thisisnic) +[@tudoramariei](https://github.com/tudoramariei) +[@UlisesGascon](https://github.com/UlisesGascon) +[@waldyrious](https://github.com/waldyrious) + many others! diff --git a/_articles/pcm/metrics.md b/_articles/pcm/metrics.md new file mode 100644 index 00000000000..145dd18119b --- /dev/null +++ b/_articles/pcm/metrics.md @@ -0,0 +1,128 @@ +--- +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 +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](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), 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. + +[CHAOSS](https://chaoss.community/) is a welcoming, open source community focused on analytics, metrics and software for community health. diff --git a/_articles/pcm/starting-a-project.md b/_articles/pcm/starting-a-project.md new file mode 100644 index 00000000000..15b01773ef7 --- /dev/null +++ b/_articles/pcm/starting-a-project.md @@ -0,0 +1,356 @@ +--- +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 +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 is free to use, study, 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 and collaboration, allowing people to spread and improve projects quickly. Also because it gives users a potential to control their own computing, relative to closed source. For example, a business using open source software has the option to hire someone to make custom improvements to the software, rather than relying exclusively on a closed source vendor's product decisions. + +_Free software_ refers to the same set of projects as _open source_. Sometimes you'll also see [these terms](https://en.wikipedia.org/wiki/Free_and_open-source_software) combined as "free and open source software" (FOSS) or "free, libre, and open source software" (FLOSS). _Free_ and _libre_ refer to freedom, [not price](#does-open-source-mean-free-of-charge). + +### 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/HEAD/Content/Part%201/2-b2-cafelog.md). + +* **Transparency:** Anyone can inspect an open source project for errors or inconsistencies. Transparency matters to governments like [Bulgaria](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) or the [United States](https://sourcecode.cio.gov/), regulated industries like banking or healthcare, and security software like [Let's Encrypt](https://github.com/letsencrypt). + +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 @dguo's ["Make a README" guide](https://www.makeareadme.com/) or @PurpleBooth's [README template](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) to write a complete README. + +When you include a README file in the root directory, GitHub will automatically display it on the repository homepage. + +### 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/HEAD/CONTRIBUTING.md) with: + +> First off, thank you for considering contributing to Active Admin. It's people like you that make Active Admin such a great tool. + +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/HEAD/CONTRIBUTING-template.md) or @mozilla's ["How to Build a CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/). + +Link to your CONTRIBUTING file from your README, so more people see it. If you [place the CONTRIBUTING file in your project's repository](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub will automatically link to your file when a contributor creates an issue or opens a pull request. + +![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://angular.io/guide/styleguide) and [jQuery](https://contribute.jquery.org/style-guide/js/) are two examples of projects with rigorous coding styles and guidelines. + +It isn't necessary to write a style guide for your project when you're just starting out, and you may find that you enjoy incorporating different coding styles into your project anyway. But you should anticipate how your writing and coding style might attract or discourage different types of people. The earliest stages of your project are your opportunity to set the precedent you wish to see. + +## 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 61402398873891ee73586a1a772cbea571038e26 Mon Sep 17 00:00:00 2001 From: Eric Sorenson Date: Fri, 12 Jan 2024 18:18:44 -0800 Subject: [PATCH 7/8] More updates for test failures - The missing `index.html` in this directory was preventing the site build from completely working - Renamed Internal anchor links like `#sabi-to-say-no` to match the new section header names - I'd blithely copied the untranslated files in but not changed their front matter to match the directory name --- _articles/pcm/building-community.md | 8 ++++---- _articles/pcm/getting-paid.md | 2 +- _articles/pcm/how-to-contribute.md | 2 +- _articles/pcm/index.html | 6 ++++++ _articles/pcm/leadership-and-governance.md | 2 +- _articles/pcm/legal.md | 2 +- .../maintaining-balance-for-open-source-maintainers.md | 2 +- _articles/pcm/metrics.md | 2 +- _articles/pcm/starting-a-project.md | 2 +- 9 files changed, 17 insertions(+), 11 deletions(-) create mode 100644 _articles/pcm/index.html diff --git a/_articles/pcm/building-community.md b/_articles/pcm/building-community.md index 1db3fef4f81..273a14338c8 100644 --- a/_articles/pcm/building-community.md +++ b/_articles/pcm/building-community.md @@ -1,5 +1,5 @@ --- -lang: pidgin +lang: pcm title: Na Welcoming Communities we go Build description: Make you build one community wey go encourage people make them use, contribute, and promote your project. class: building @@ -35,7 +35,7 @@ Start with your documentation: * **When new person land for your project, thank them for their interest!** E fit just take one bad experience for person to no wan come back again. * **Be responsive.** If you no respond to their issue for one month, e possible say them don forget your project. * **Open mind about the types of contributions wey you go accept.** Many contributors start with one bug report or one small fix. Many ways dey to contribute to one project. Make people fit help the way wey them wan help. -* **If one person submit one contribution wey you no gree with,** thank them for their idea and [explain why](../best-practices/#learning-to-say-no) e no follow your project scope, and you fit add link to the relevant documentation wey you get. +* **If one person submit one contribution wey you no gree with,** thank them for their idea and [explain why](../best-practices/#sabi-to-say-no) e no follow your project scope, and you fit add link to the relevant documentation wey you get.