From 061ca9602e7c47206c6c06000dc9f6d1c00df440 Mon Sep 17 00:00:00 2001 From: LizzyOrji123 Date: Sun, 22 Oct 2023 19:06:17 +0100 Subject: [PATCH 01/73] 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 c550756e43649de5f0ecb8f494dc4338590257cf Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Tue, 24 Oct 2023 04:37:19 +0000 Subject: [PATCH 02/73] build(deps): bump actions/setup-node from 3 to 4 Bumps [actions/setup-node](https://github.com/actions/setup-node) from 3 to 4. - [Release notes](https://github.com/actions/setup-node/releases) - [Commits](https://github.com/actions/setup-node/compare/v3...v4) --- updated-dependencies: - dependency-name: actions/setup-node dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] --- .github/workflows/tests.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml index 7c2c57a47ec..ed3402cdbc8 100644 --- a/.github/workflows/tests.yml +++ b/.github/workflows/tests.yml @@ -17,7 +17,7 @@ jobs: bundler-cache: true - name: Set up Node - uses: actions/setup-node@v3 + uses: actions/setup-node@v4 - name: Bootstrap run: script/bootstrap From 5adac1996777353f2377b6b4ba9e80a73b4da127 Mon Sep 17 00:00:00 2001 From: LizzyOrji123 Date: Tue, 24 Oct 2023 13:05:28 +0100 Subject: [PATCH 03/73] 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 04/73] 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 b80fb715495a62db52eddece327619f5f7eb5f03 Mon Sep 17 00:00:00 2001 From: Robson Cruz Date: Tue, 24 Oct 2023 19:32:19 -0300 Subject: [PATCH 05/73] docs(pt): translate article body --- ...ing-balance-for-open-source-maintainers.md | 153 ++++++++++-------- 1 file changed, 83 insertions(+), 70 deletions(-) diff --git a/_articles/pt/maintaining-balance-for-open-source-maintainers.md b/_articles/pt/maintaining-balance-for-open-source-maintainers.md index 1c832e12eaa..f5f0556a629 100644 --- a/_articles/pt/maintaining-balance-for-open-source-maintainers.md +++ b/_articles/pt/maintaining-balance-for-open-source-maintainers.md @@ -8,180 +8,193 @@ 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. +Com o crescimento de popularidade de projetos código aberto, se torna importante definir limites para te ajudar a equilibrar se manter motivado e produtivo ao longo do tempo. -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. +Para obter insights sobre as experiências dos mantenedores e suas estratégias para encontrar equilíbrio, realizamos uma oficina com 40 membros da Comunidade de Mantenedores, permitindo-nos aprender com suas experiências pessoais de esgotamento em código aberto e as práticas que os ajudaram a manter o equilíbrio em seu trabalho. É aqui que o conceito de ecologia pessoal entra em jogo. -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. +Então, o que é a ecologia pessoal? Conforme descrito pelo Instituto de Liderança Rockwood, envolve "manter o equilíbrio, o ritmo e a eficiência para sustentar nossa energia ao longo de uma vida." Isso moldou nossas conversas, ajudando os mantenedores a reconhecerem suas ações e contribuições como partes de um ecossistema maior que evolui ao longo do tempo. O esgotamento, uma síndrome resultante do estresse crônico no local de trabalho, conforme [definido pela OMS](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281), não é incomum entre mantenedores. Isso frequentemente leva a uma perda de motivação, incapacidade de se concentrar e falta de empatia pelos colaboradores e comunidade com os quais você trabalha. -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. +Ao abraçar o conceito de ecologia pessoal, os mantenedores podem evitar o esgotamento de forma proativa, priorizar o autocuidado e manter um senso de equilíbrio para fazer o seu melhor trabalho. -## Tips for Self-Care and Avoiding Burnout as a Maintainer: +## Dicas de Autocuidado e Prevenção do Esgotamento como Mantenedor: -### Identify your motivations for working in open source +### Identifique suas motivações para trabalhar em código aberto -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. +Dedique um tempo para refletir sobre quais aspectos da manutenção em código aberto o energizam. Compreender suas motivações pode ajudá-lo a priorizar o trabalho de uma maneira que o mantenha envolvido e pronto para novos desafios. Seja o retorno positivo dos usuários, a alegria de colaborar e socializar com a comunidade ou a satisfação de mergulhar no código, reconhecer suas motivações pode ajudar a direcionar o seu foco. -### Reflect on what causes you to get out of balance and stressed out +### Reflita sobre o que causa desequilíbrio e estresse -It's important to understand what causes us to get burned out. Here are a few common themes we saw among open source maintainers: +É importante entender o que nos leva ao esgotamento. Aqui estão alguns temas comuns que encontramos entre mantenedores de código aberto: -* **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. +* **Falta de feedback positivo:** Os usuários tendem a entrar em contato quando têm uma reclamação. Se tudo funciona bem, tendem a ficar em silêncio. Pode ser desanimador ver uma crescente lista de problemas sem o feedback positivo mostrando como suas contribuições fazem a diferença. -* **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. +* **Não dizer 'não':** Pode ser fácil assumir mais responsabilidades do que se deveria em um projeto de código aberto. Seja de usuários, colaboradores ou outros mantenedores, nem sempre podemos corresponder às expectativas deles. -* **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. +* **Trabalhar sozinho:** Ser um mantenedor pode ser incrivelmente solitário. Mesmo se você trabalha com um grupo de mantenedores, os últimos anos têm sido difíceis para reunir equipes distribuídas pessoalmente. -* **Not enough time or resources:** This is especially true for volunteer maintainers who have to sacrifice their free time to work on a project. +* **Falta de tempo ou recursos:** Isso é especialmente verdade para mantenedores voluntários que têm que sacrificar seu tempo livre para trabalhar em um projeto. -* **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. +* **Demandas conflitantes:** O código aberto é cheio de grupos com diferentes motivações, o que pode ser difícil de navegar. Se você é pago para fazer código aberto, os interesses de seu empregador às vezes podem entrar em conflito com a comunidade. -### Watch out for signs of burnout +### Fique atento aos sinais de esgotamento -Can you keep up your pace for 10 weeks? 10 months? 10 years? +Você consegue manter seu ritmo por 10 semanas? 10 meses? 10 anos? -There are tools like the [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) from [@shaunagm](https://github.com/shaunagm) and Mozilla's [personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) 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). +Existem ferramentas como a [Lista de Verificação de Esgotamento](https://governingopen.com/resources/signs-of-burnout-checklist.html) de [@shaunagm](https://github.com/shaunagm) e o kit de autoavaliação de ecologia pessoal da Mozilla (https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) que podem ajudá-lo a refletir sobre seu ritmo atual e ver se há ajustes que você pode fazer. Alguns mantenedores também usam tecnologia vestível para acompanhar métricas como qualidade do sono e variabilidade da frequência cardíaca (ambas relacionadas ao estresse). -### What would you need to continue sustaining yourself and your community? +### Fique atento aos sinais de esgotamento -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: +Você consegue manter seu ritmo por 10 semanas? 10 meses? 10 anos? -* **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. +Existem ferramentas como a [Lista de Verificação de Esgotamento](https://governingopen.com/resources/signs-of-burnout-checklist.html) de [@shaunagm](https://github.com/shaunagm) e o kit de autoavaliação de ecologia pessoal da Mozilla (https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw) que podem ajudá-lo a refletir sobre seu ritmo atual e ver se há ajustes que você pode fazer. Alguns mantenedores também usam tecnologia vestível para acompanhar métricas como qualidade do sono e variabilidade da frequência cardíaca (ambas ligadas ao estresse). - 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. + + +### O que você precisa para continuar sustentando a si mesmo e à sua comunidade? + +Isso será diferente para cada mantenedor e mudará dependendo de sua fase de vida e outros fatores externos. Mas aqui estão alguns temas que ouvimos: + +* **Conte com a comunidade:** Delegação e encontrar colaboradores podem aliviar a carga de trabalho. Ter vários pontos de contato para um projeto pode ajudar você a tirar uma folga sem preocupações. Conecte-se com outros mantenedores e a comunidade em geral – em grupos como a [Comunidade de Mantenedores](http://maintainers.github.com/). Isso pode ser uma ótima fonte de apoio mútuo e aprendizado. + + Você também pode procurar maneiras de se envolver com a comunidade de usuários, para ouvir regularmente feedback e entender o impacto de seu trabalho de código aberto. -* **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/). +* **Explore o financiamento:** Esteja você procurando um dinheiro extra para pizza ou tentando se dedicar integralmente ao código aberto, há muitos recursos disponíveis! Como primeiro passo, considere ativar [Patrocinadores do GitHub](https://github.com/sponsors) para permitir que outros patrocinem seu trabalho de código aberto. Se você está pensando em dar o salto para o tempo integral, inscreva-se para a próxima rodada do [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. +* **Use ferramentas:** Explore ferramentas como [GitHub Copilot](https://github.com/features/copilot/) e [GitHub Actions](https://github.com/features/actions/) para automatizar tarefas mundanas e liberar tempo para contribuições mais significativas. -* **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. +* **Descanse e recarregue:** Reserve tempo para seus hobbies e interesses fora do código aberto. Tire os fins de semana para relaxar e rejuvenescer - e ajuste seu [status do GitHub](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status) para refletir sua disponibilidade! Uma boa noite de sono pode fazer uma grande diferença em sua capacidade de manter seus esforços a longo prazo. - If you find certain aspects of your project particularly enjoyable, try to structure your work so you can experience it throughout your day. + Se você encontrar certos aspectos de seu projeto particularmente agradáveis, tente estruturar seu trabalho de forma que você possa experimentá-los ao longo do dia. -* **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. +* **Estabeleça limites:** Você não pode dizer sim para todos os pedidos. Isso pode ser tão simples quanto dizer: "Não consigo fazer isso agora e não tenho planos de fazê-lo no futuro" ou listar o que você tem interesse em fazer e o que não tem no README. Por exemplo, você pode dizer: "Só aceito solicitações de pull que tenham razões claras para sua criação" ou "Só reviso problemas em todas as quintas-feiras, das 18h às 19h." Isso estabelece expectativas para os outros e fornece algo a que você pode se referir em outros momentos para ajudar a reduzir as demandas de colaboradores ou usuários sobre o seu tempo. - 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. + Aprenda a ser firme em desligar comportamentos tóxicos e interações negativas. Não há problema em não dar energia a coisas com as quais você não se importa. -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. +Lembre-se, a ecologia pessoal é uma prática contínua que evoluirá à medida que você avança em sua jornada de código aberto. Ao priorizar o autocuidado e manter um senso de equilíbrio, você pode contribuir para a comunidade de código aberto de forma eficaz e sustentável, garantindo tanto o seu bem-estar quanto o sucesso de seus projetos a longo prazo. -## Additional Resources +## Recursos Adicionais -* [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 +* [Comunidade de Mantenedores](http://maintainers.github.com/) +* [O contrato social do código aberto](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon +* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg +* [Como lidar com pessoas tóxicas](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge * [SustainOSS](https://sustainoss.org/) -* [Personal ecology self-assessment kit](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla -* [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 +* [Kit de autoavaliação de ecologia pessoal](https://docs.google.com/document/d/1duOYQ6EbcDTH_CK6ux3BGRiVYptGTUMOtndZbbwulOY/edit#heading=h.mn38481ischw), Mozilla +* [Arte da Liderança Rockwood](https://rockwoodleadership.org/art-of-leadership/) +* [Dizer Não](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid +* [Governança do Código Aberto](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com) +* A agenda do workshop foi adaptada a partir da série [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) da Mozilla. -## Contributors +## Contribuidores -Many thanks to all the maintainers who shared their experiences and tips with us for this guide! +Muito obrigado a todos os mantenedores que compartilharam suas experiências e dicas conosco para este guia! -This guide was written by [@abbycabs](https://github.com/abbycabs) with contributions from: +Este guia foi escrito por [@abbycabs](https://github.com/abbycabs) com contribuições de: [@agnostic-apollo](https://github.com/agnostic-apollo) [@AndreaGriffiths11](https://github.com/AndreaGriffiths11) @@ -218,4 +231,4 @@ This guide was written by [@abbycabs](https://github.com/abbycabs) with contribu [@thisisnic](https://github.com/thisisnic) [@tudoramariei](https://github.com/tudoramariei) [@UlisesGascon](https://github.com/UlisesGascon) -[@waldyrious](https://github.com/waldyrious) + many others! +[@waldyrious](https://github.com/waldyrious) + muitos outros! From 7faba03ed44790d343b6bec55b13a553d791859d Mon Sep 17 00:00:00 2001 From: Robson Cruz Date: Tue, 24 Oct 2023 19:58:52 -0300 Subject: [PATCH 06/73] docs(pt): fix small typos on codeblocks also update meta header --- ...maintaining-balance-for-open-source-maintainers.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/_articles/pt/maintaining-balance-for-open-source-maintainers.md b/_articles/pt/maintaining-balance-for-open-source-maintainers.md index f5f0556a629..d6a187e0e40 100644 --- a/_articles/pt/maintaining-balance-for-open-source-maintainers.md +++ b/_articles/pt/maintaining-balance-for-open-source-maintainers.md @@ -1,8 +1,7 @@ --- lang: pt -untranslated: true -title: Maintaining Balance for Open Source Maintainers -description: Tips for self-care and avoiding burnout as a maintainer. +title: Mantendo o Equilíbrio para Mantenedores de Código Aberto +description: Dicas para o autocuidado e evitar o esgotamento como mantenedor. class: balance order: 0 image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png @@ -47,7 +46,7 @@ Dedique um tempo para refletir sobre quais aspectos da manutenção em código a * **Não dizer 'não':** Pode ser fácil assumir mais responsabilidades do que se deveria em um projeto de código aberto. Seja de usuários, colaboradores ou outros mantenedores, nem sempre podemos corresponder às expectativas deles.