mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-25 23:11:02 +08:00
Merge pull request #28628 from XiaotingHuang22/patch-3
translated by XiaotingHuang22
This commit is contained in:
Xingyu.Wang
GitHub
commit
07ac4f1413
@ -1,143 +0,0 @@
|
||||
[#]: subject: "3 steps for managing a beginner-friendly open source community"
|
||||
[#]: via: "https://opensource.com/article/21/8/beginner-open-source-community"
|
||||
[#]: author: "Isabel Costa https://opensource.com/users/isabelcmdcosta"
|
||||
[#]: collector: "lujun9972"
|
||||
[#]: translator: " "
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
|
||||
3 steps for managing a beginner-friendly open source community
|
||||
======
|
||||
As a member of an open source project, there's a lot you can do to help
|
||||
beginners find a way to contribute.
|
||||
![Working from home at a laptop][1]
|
||||
|
||||
When someone is new to contributing to open source, the best place to start is often beginner-friendly bugs and issues. But before they can do that, they have to be able to find those kinds of issues. As a member of an open source project, there's a lot you can do to help beginners find a way to contribute.
|
||||
|
||||
Bearing this in mind, the [AnitaB.org open source community][2] prioritizes making our community beginner-friendly. We have initiatives to ensure that we're inclusive for contributors at different levels of experience and for different types of contributions that don't only relate to coding.
|
||||
|
||||
I recently presented some of the community work we do at the [AnitaB.org][3] community at [Upstream 2021][4], the Tidelift event, which kicked off Maintainer Week, a weeklong celebration of open source maintainers. I discussed how there are three main parts to our strategy:
|
||||
|
||||
* How we communicate
|
||||
* Projects and issues
|
||||
* Open source programs
|
||||
|
||||
|
||||
|
||||
### How we communicate
|
||||
|
||||
Transparency is such an essential part of open source, and we apply transparency principles to our approach to communication. In practical terms, this means that all our community sessions are run openly, affect how we've set up Zulip chat and how we provide documentation.
|
||||
|
||||
#### **Open sessions**
|
||||
|
||||
Anyone can join our sessions and discuss topics related to our community. They can participate in discussions or just listen. These are available for everyone to see in our community calendar. We usually only use audio in these calls, which we've found can make people feel more comfortable participating.
|
||||
|
||||
We host project-focused sessions and a couple of category-related sessions, where people from different areas can discuss the same project and help improve our processes. Occasionally, we have "Ask Me Anything" sessions, where anyone can come and ask questions about anything related to open source.
|
||||
|
||||
We take notes of all sessions in a shared document and share the summary and a document link in [our Zulip][5].
|
||||
|
||||
#### **Our Zulip chat**
|
||||
|
||||
The open source Zulip chat platform is our primary community communication channel, although we also use the comments section on issues and pull requests on Github. In general, we have disabled private messaging to make sure we are as transparent as possible. We have only a few exceptions to this rule, where we have private streams for admins dealing with the logistics of the programs we run. We've found this approach is more welcoming, and it also enables us to have more visibility into conduct violations in the public chat.
|
||||
|
||||
We share all session summaries on the Zulip chat, including the main points discussed, action items, and documentation. This process might sound like an obvious requirement, but I've been surprised at how many open source projects don't provide notes so that people who did not attend can remain informed.
|
||||
|
||||
On Zulip, we discuss project roadmaps, answer questions and queries from the community, and actively **promote ways for people to contribute and where they can contribute. **Sometimes we celebrate contributors' wins—whether it's to highlight the first PR they have tested, reviewed, or the excellent work our volunteers do.
|
||||
|
||||
#### **Documentation**
|
||||
|
||||
We try to keep **open documentation about our processes**, such as FAQs, so those community members can learn at their own pace and in their own time about the community. This is intended to give them an idea of how we work and what type of work we do before reaching out to us.
|
||||
|
||||
### Projects and issues
|
||||
|
||||
Regarding our projects and issues management, we encourage multiple ways to contribute, create specific issues for first-timers only, and try to have an easy setup for projects.
|
||||
|
||||
#### **Multiple ways to contribute**
|
||||
|
||||
We make an effort to create **issues that require different contributions** such as documentation, testing, design, and outreach. This is to provide ways for anyone to contribute regardless of their experience level and area of interest. It helps the community get involved, and we've found that it enables members to work their way up and contribute to some low-effort but valuable tasks.
|
||||
|
||||
Types of contributions we promote are:
|
||||
|
||||
* Coding tasks that range in complexity.
|
||||
* Quality assurance tasks—where contributors can test our apps or pull requests and report bugs.
|
||||
* Design sessions where members can participate in discussions. Also, opportunities to create mock-ups and redesign parts of our apps, and explore user experience improvements.
|
||||
* Outreach tasks, we primarily promote on Zulip, where we suggest blogging to our Medium publication about their open source experiences and their contributions.
|
||||
* Documentation tasks that can include general community documentation or our project's documentation on Docusaurus.
|
||||
|
||||
|
||||
|
||||
#### **First-timers only issues**
|
||||
|
||||
We label some **issues as "first-timers only."** These are for people who have not contributed yet to the issue's repository. Labeling issues also enable us to have work for people beginning their open source journey during times of contributor influx, for example, during [Google Summer of Code (GSoC)][6].
|
||||
|
||||
Sometimes these might be "low-hanging fruit" that can get them acquainted with the process of contributing and submitting pull requests.
|
||||
|
||||
#### **Easy project setup**
|
||||
|
||||
We also care about having a **beginner-friendly setup **for our projects. We notice that the most active project is generally the easiest to set up. We know that contributing to a project you aren't familiar with can take a lot of effort and make or break the experience of contributing.
|
||||
|
||||
We try to provide instructions on how to run our projects on multiple operating systems. In the past, we had some projects with separate instructions to run on Unix environments, and we noticed contributors having difficulties running these projects on Windows. We've improved since then to avoid confusion among contributors who would ask for help on our Zulip.
|
||||
|
||||
We have been improving the README for one of our most active projects, [mentorship-backend][7], according to contributors' experience. One of the struggles for beginners in this project was setting part of the environment variables related to configuring an email account to enable the backend functionality to send emails. However, because this feature was not critical for local development, by default, we made the email setup optional so that emails, instead of being sent to users, were printed to the terminal. This approach still made the emails visible to the contributor. Similar to this change, we made [the SQLite database][8] the default for local development to avoid additional setup for the Postgres database, even though we use this in our deployed version.
|
||||
|
||||
We have noticed that some contributors have struggled to contribute to one of our projects, [bridge-in-tech-backend][9], where its setup is complicated and includes many more steps than [mentorship-backend][7]. Since we noticed this in one of our open source programs, we have been exploring improving its structure.
|
||||
|
||||
For most of our projects, we also provide a live or bundled version of the apps so that contributors can test the project without setting it up. This helps us provide a way for contributors who are not interested or familiar with the development setup to try the most recent version of our apps and contribute by reporting any bugs found. We have the links to these apps deployed on our [Quality Assurance guide][10].
|
||||
|
||||
### Open source programs
|
||||
|
||||
We organize two main programs in our community: Open Source Hack (a one-month program) and Open Source Ambassadors (a six-month program).
|
||||
|
||||
#### **Open Source Hack (OSH)**
|
||||
|
||||
In this program, we create issues in multiple categories of contributions—Documentation, Coding, Outreach, Testing, and Design (similar to the [Google Code-in][11] contest). Participants can contribute and receive digital certificates for contributing at least once to each category. One issue may include multiple categories, and the pull requests don't need to be merged for their contributions to be valid.
|
||||
|
||||
We select a few projects for this program, then mentors brainstorm and create issues for participants. When the program starts, participants can claim issues and begin contributing. Mentors support and review their contributions.
|
||||
|
||||
This approach encourages diversity of contributions and welcomes anyone, regardless of their coding ability, to contribute in a friendly and fail-safe environment.
|
||||
|
||||
#### **Open Source Ambassadors**
|
||||
|
||||
In this program, we select ambassadors from the community that ideally will cover each category of contributions we aim to promote. We've run this program twice so far.
|
||||
|
||||
The program aims to have members grow in helping manage projects and initiatives by responding to questions from the community, assisting contributors to get involved, and advocating for their assigned category.
|
||||
|
||||
In the first program we ran, we accepted anyone who applied. We assessed where members' interests lay and provided a structure for people who wanted to contribute but were initially uncomfortable with taking that step.
|
||||
|
||||
This edition was very enlightening for us as a community. It required a lot of management from admins, as we had a mix of experienced and inexperienced open source contributors and community members. Some ambassadors were confident in stepping up and leading initiatives, while others needed more support. For our second program, we decided to scale down the initiative. We only accepted contributors who were already familiar with the community and could lead on initiatives and projects and help us train the less experienced.
|
||||
|
||||
The second program became a positive feedback loop. Ambassadors who started as beginners, contributing to the first program we ran, became comfortable leading after learning from their experience with the program.
|
||||
|
||||
This change of approach enabled admins to focus more on supporting the ambassadors' team, helping them propagate our mission and continue making the community beginner-friendly, and mentoring more people to contribute.
|
||||
|
||||
### Summary
|
||||
|
||||
These programs have helped us bring awareness to different ways to contribute and give back to open source. Through these, we've found volunteers helping by managing projects and hosting open sessions, which contributes to managing the community and providing mentorship to our contributors.
|
||||
|
||||
Even though we have had a good response from contributors and helped people make their first contributions, we still have a lot of room for improvement. We will continue to enhance our project's setup and contribution guidelines to improve contributors' experience. We'll also continue to focus on making sure we always have and promote available issues across the organization and in different categories to promote an inclusive environment so that anyone who wishes to can contribute.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/21/8/beginner-open-source-community
|
||||
|
||||
作者：[Isabel Costa][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/isabelcmdcosta
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/wfh_work_home_laptop_work.png?itok=VFwToeMy (Working from home at a laptop)
|
||||
[2]: https://github.com/anitab-org
|
||||
[3]: https://anitab.org/
|
||||
[4]: https://youtu.be/l8r50jCr-Yo
|
||||
[5]: https://anitab-org.zulipchat.com/
|
||||
[6]: https://summerofcode.withgoogle.com/
|
||||
[7]: https://github.com/anitab-org/mentorship-backend#readme
|
||||
[8]: https://opensource.com/article/21/2/sqlite3-cheat-sheet
|
||||
[9]: https://github.com/anitab-org/bridge-in-tech-backend
|
||||
[10]: https://github.com/anitab-org/documentation/blob/master/quality-assurance.md
|
||||
[11]: https://codein.withgoogle.com/
|
||||
@ -0,0 +1,147 @@
|
||||
[#]: subject: "3 steps for managing a beginner-friendly open source community"
|
||||
[#]: via: "https://opensource.com/article/21/8/beginner-open-source-community"
|
||||
[#]: author: "Isabel Costa https://opensource.com/users/isabelcmdcosta"
|
||||
[#]: collector: "lujun9972"
|
||||
[#]: translator: "XiaotingHuang22"
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
|
||||
|
||||
3个步骤管理对新手友好的开源社区
|
||||
======
|
||||
|
||||
作为开源项目的成员，您可以做很多事情来帮助新手找到为项目作出贡献的方式。
|
||||
![在家使用笔记本电脑工作][1]
|
||||
|
||||
当有人刚开始为开源做贡献时，最好从对新手友好的故障和问题开始。但在他们修复故障之前，他们必须要能够找到这类问题。作为开源项目的成员，您可以做很多事情来帮助新手找到为项目贡献的方式。
|
||||
|
||||
牢记这一点，[AnitaB.org 开源社区][2] 优先考虑让我们的社区做到对新手友好。 我们提倡包容性，确保不同经验和水平的贡献者都可以参与进来，并且他们的贡献不止限于跟编程有关。
|
||||
|
||||
我最近在 [Upstream 2021][4] 上介绍了我们在 [AnitaB.org][3] 上所做的一些社区工作，Tidelift举办的活动启动了维护者周，这是一个为期一周的开源维护者庆祝活动。在活动中我讨论了我们战略的三个主要部分：
|
||||
|
||||
* 我们如何沟通
|
||||
* 项目和问题
|
||||
* 开源项目
|
||||
|
||||
|
||||
### 我们如何沟通
|
||||
|
||||
|
||||
透明度是开源的重要组成部分，我们将透明度原则应用于我们的沟通方式。实际上，这意味着我们所有的社区会议都是公开进行的，并且影响我们设置Zulip聊天的方式以及我们提供文档的方式。
|
||||
|
||||
#### **开放会议**
|
||||
|
||||
任何人都可以加入我们的会议并讨论与我们社区相关的话题。他们可以参与讨论或者旁听。会议相关信息在我们的社区日历中都可以找到。在这些通话中我们通常只使用语音聊天，我们发现这可以让人们在参与时感觉更自在。
|
||||
|
||||
我们举办以项目为中心的会议和一些与类别相关的会议。会议上，来自不同领域的人们可以讨论同一个项目并帮助改进我们的流程。偶尔，我们会有“自由提问（Ask Me Anything）”会议，任何人都可以来问任何与开源相关的问题。
|
||||
|
||||
所有会议我们都会在共享文档中进行记录，并在 [我们的Zulip（our Zulip）][5] 中共享摘要和文档链接。
|
||||
|
||||
#### *我们的Zulip聊天**
|
||||
|
||||
开源 Zulip 聊天平台是我们的主要社区交流渠道，虽然我们也在Github的评论区讨论问题和拉取请求（pull request）。一般来说，我们已禁用私人消息以确保我们尽可能透明。对于这条规则，我们只有少数例外，那些私人聊天是管理员在处理我们运行程序的后勤工作所用的。 我们发现这种方法更受欢迎，它还使我们能够更清楚公共聊天中的违规行为。
|
||||
|
||||
我们在 Zulip 聊天室分享所有会议摘要，包括讨论的要点、行动项目和文档。这些听起来好像是些显而易见的要求，但我一直惊讶于很多开源项目并不提供笔记，所以 Zulip可以让那些没有参加会议的人也随时了解情况。
|
||||
|
||||
在 Zulip上，我们讨论项目路线图，回答社区的问题和查询，并积极**促进人们通过不同的方式方法和在不同的场景下做出自己的贡献。 **有时我们为贡献者的成就而庆祝——无论是突出他们测试或者审查的第一个拉取请求，还是强调我们志愿者所做的出色工作。
|
||||
|
||||
#### **文档**
|
||||
|
||||
我们尽量保持**关于我们流程的开放文档**，例如常见问题解答，以便这些社区成员可以按照自己的节奏和时间了解社区。这是为了让他们在联系我们之前了解我们的工作方式以及我们从事的工作类型。
|
||||
|
||||
|
||||
### 项目和问题
|
||||
|
||||
关于我们的项目和问题管理，我们鼓励通过多种方式做出贡献，我们为新手专门创建特定的问题，并尝试让项目的设置变得简单。
|
||||
|
||||
#### **多种贡献的方式**
|
||||
|
||||
我们努力创建**需要不同贡献的问题**，例如文档、测试、设计和外展。这是为了让任何人，无关他们的经验水平和兴趣领域，都能做出贡献。这样能够帮助社区参与进来，而且我们发现它使成员能够从一些省力但有价值的任务开始一步步做出贡献。
|
||||
|
||||
我们提倡的贡献类型有：
|
||||
|
||||
* 不同复杂性的编程任务。
|
||||
* 质量保证任务——贡献者可以测试我们的应用程序或拉取请求并报告错误。
|
||||
* 社区成员可以参与讨论的设计会议。此外，创建模型和重新设计我们应用程序某些部分的机会，并探索改进用户体验。
|
||||
* 外展任务，我们主要在 Zulip 上推广，我们建议在我们的 Medium 出版物上发表博客，介绍他们的开源经验和他们的贡献。
|
||||
* 文档任务，可以包括一般社区文档或我们在 Docusaurus 上的项目文档。
|
||||
|
||||
|
||||
#### **仅限新手的问题**
|
||||
|
||||
我们将一些**问题标记为“仅限新手”。**这些问题适用于尚未为问题存储库做出贡献的人。为问题做标签还使我们能够让人们在贡献者涌入期间开始他们的开源之旅，例如，在 [Google夏日程式碼大賽(GSoC)][6] 申请期间。
|
||||
|
||||
有时，这些可能是“唾手可得的果实”，让他们可以熟悉作出贡献和提交拉取请求的过程。
|
||||
|
||||
|
||||
#### **简单的项目设置**
|
||||
|
||||
我们也很在意为我们的项目提供**新手友好的安装设置**。我们注意到最活跃的项目通常是最容易设置的。我们知道，为您不熟悉的项目做出贡献可能需要付出很多努力并且关乎贡献体验的成败。
|
||||
|
||||
我们尝试提供有关如何在多个操作系统上运行我们项目的说明。过去我们有一些项目在 Unix 环境中运行有单独的指令，我们注意到贡献者在 Windows 上运行这些项目有困难。自那以后我们不断进行改进，以避免让在 Zulip 上寻求帮助的贡献者产生混淆。
|
||||
|
||||
根据贡献者的经验，我们一直在改进我们最活跃的项目之一 [mentorship-backend][7] 的自述文件。新手在这个项目中遇到的其中一个困难是设置与配置电子邮件帐户相关的部分环境变量，以使后端功能能够发送电子邮件。 但是，由于此功能对于本地开发并不重要，因此默认情况下，我们将电子邮件设置设为可选，以便将电子邮件打印到终端，而不是发送给用户。 这种方法仍然使电子邮件对贡献者可见。 与此更改类似，我们将 [SQLite 数据库][8] 作为本地开发的默认设置，以避免对 Postgres 数据库进行额外设置，虽然我们在部署版本中会使用到Postgres。
|
||||
|
||||
我们注意到，一些贡献者在为我们的 [bridge-in-tech-backend][9]项目做出贡献时觉得很困难，该项目的设置很复杂，并且包含的步骤比 [mentorship-backend][7] 多得多。 自从我们在一个开源项目中注意到这一点以来，我们一直在探索如何改进其结构。
|
||||
|
||||
对于我们的大多数项目，我们还提供应用程序的实时或内部版本，以便贡献者无需设置即可测试项目。这有助于我们为不感兴趣或不熟悉开发设置的贡献者提供一种方式来尝试我们应用程序的最新版本，并通过报告发现的任何错误来做出贡献。我们在 [质量保证指南][10] 中放了这些应用程序的链接。
|
||||
|
||||
### 开源项目
|
||||
|
||||
我们在社区中组织了两个主要项目：Open Source Hack（一个为期一个月的项目）和 Open Source Ambassadors（一个为期六个月的项目）。
|
||||
|
||||
#### **开源黑客 (OSH)**
|
||||
|
||||
在此计划中，我们在多个类别的贡献中创建问题——文档、编码、外展、测试和设计（类似于 [Google Code-in][11] 竞赛）。 参与者可以为每个类别至少贡献一次并获得数字证书。 一个问题可能包含多个类别，并且无需合并拉取请求也能使贡献有效。
|
||||
|
||||
我们为这个计划选取几个项目，请导师们集思广益为参与者创造问题。项目开始后参与者可以认领问题并开始作出贡献。导师会支持帮助并审查他们的贡献。
|
||||
|
||||
这种方法鼓励贡献的多样性，并欢迎任何人，无论他们的编码能力如何都可以在友好和不怕出错的环境中做出贡献。
|
||||
|
||||
|
||||
#### **开源大使**
|
||||
|
||||
在此计划中，我们从社区中选择大使，理想情况下他们将涵盖我们旨在促进的每一类贡献。至今该计划已启动了两次。
|
||||
|
||||
该计划旨在让成员通过回答社区的问题、协助贡献者参与并为他们指定的类别宣传来帮助管理项目和计划。
|
||||
|
||||
第一届计划举行时我们接受了所有的申请者。我们评估了社区成员的兴趣所在，并为那些想要做出贡献但最初不敢踏出第一步的人提供了一个体系。
|
||||
|
||||
第一届计划的举办给了我们很多启发。因为我们的活动中既有经验丰富的开源贡献者和社区成员，也有初来乍到缺乏经验的新手，因此项目的执行要求管理员进行大量的管理工作。一些社区大使信心十足准备好进一步采取新措施，而其他大使则需要更多支持。到了第二届，我们决定缩减该计划，只接受那些已经熟悉社区、可以领导倡议和项目并帮助我们培训新人的贡献者。
|
||||
|
||||
第二届计划中形成了正反馈循环。那些在第一届计划中还是新手的大使们，通过为上一个项目做出贡献并且从项目经验中学习之后能够做到轻松带领项目。
|
||||
|
||||
这种方法的改变使管理员能够更加专注于支持大使团队，帮助他们传播我们的使命并继续让我们的社区对新手友好，并指导更多人做出贡献。
|
||||
|
||||
### 总结
|
||||
|
||||
|
||||
这些计划帮助我们提高了对开源贡献和回馈的不同方式的认识。通过它们，我们发现志愿者通过管理项目和举办公开会议来提供帮助，这有助于管理社区并为我们的贡献者提供指导。
|
||||
|
||||
尽管我们得到了贡献者的良好反响并帮助人们做出了他们的第一个贡献，但我们仍有很大的改进空间。我们将继续改进我们项目的设置和贡献指南，以改善贡献者的体验。我们还将继续专注于确保我们的组织始终拥有并推动不同类别的问题，促进包容性，以便任何有意愿做出贡献的人都能出自己的一份力。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/21/8/beginner-open-source-community
|
||||
|
||||
作者：[Isabel Costa][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[XiaotingHuang22](https://github.com/XiaotingHuang22)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/isabelcmdcosta
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/wfh_work_home_laptop_work.png?itok=VFwToeMy (Working from home at a laptop)
|
||||
[2]: https://github.com/anitab-org
|
||||
[3]: https://anitab.org/
|
||||
[4]: https://youtu.be/l8r50jCr-Yo
|
||||
[5]: https://anitab-org.zulipchat.com/
|
||||
[6]: https://summerofcode.withgoogle.com/
|
||||
[7]: https://github.com/anitab-org/mentorship-backend#readme
|
||||
[8]: https://opensource.com/article/21/2/sqlite3-cheat-sheet
|
||||
[9]: https://github.com/anitab-org/bridge-in-tech-backend
|
||||
[10]: https://github.com/anitab-org/documentation/blob/master/quality-assurance.md
|
||||
[11]: https://codein.withgoogle.com/
|
||||
Loading…
Reference in New Issue
Block a user