From db107ee0c72cc2e6a4a7f4cb69ceb53a7a63cf18 Mon Sep 17 00:00:00 2001 From: Ildiko Vancsa Date: Mon, 22 Feb 2021 16:22:23 +0100 Subject: [PATCH] Re-work the content under Practical Examples The previous patch moved out the action and examples from under the Open Community chapter. This patch updates the text to adjust to the content and flow of the book. Change-Id: Ib4918697427c20c34a01c699e1741158b83bc7ec Signed-off-by: Ildiko Vancsa --- doc/source/activities_and_processes.rst | 523 +++++++++++------------- 1 file changed, 238 insertions(+), 285 deletions(-) diff --git a/doc/source/activities_and_processes.rst b/doc/source/activities_and_processes.rst index 50a0efa..b8794e4 100644 --- a/doc/source/activities_and_processes.rst +++ b/doc/source/activities_and_processes.rst @@ -2,337 +2,290 @@ Practical Examples ================== -NOTE: This section still needs editing +The Four Opens is a set of principles to guide you when you build, support or +participate in an open source community to ensure a healthy and balanced +environment. +While there is no magic screenplay that would apply to all communities, there +are practices you can follow and steps you can take regardless of you being one +of the contributors, or if you work for a foundation or company that supports +the project. +This chapter will give you examples and recommendations to build on based on +the experiences of the OpenInfra communities and the ecosystem around them. We +will cover the following areas: -- Common mission & goals. -- Effective governance & leadership. -- Diversity & Inclusiveness. -- Contributor recognition & motivation. -- Open & Transparent Communication. -- Branding & positioning (example of collaboration across forces, product - definition). -- Education & On-boarding. -- Marketing & events. -- Ambassadors & meet-ups. -- Cross-community collaboration (NIH). +- Common mission & goals +- Effective governance & leadership +- Diversity & Inclusiveness Common Mission & Goals ---------------------- -A strong mission statement is one of the most critical elements to achieve -a healthy open source community. It's imperative to outline a long term vision -that is focused, but not overly constrained. A strong mission statement helps -define the community values and provides a guide to make decisions and -prioritize activities. It also helps new contributors and adjacent communities -quickly understand the goals of the project. +The idea behind open source software development is to share and work together +on tools and projects that provide solutions to common problems. While having a +challenge to share is a good start for collaboration, it cannot guarantee a +stable direction for the community in itself. This is why it is crucial to +define the common goals for the community and summarize them in a strong +mission statement. -Getting the current stake-holders input and buy-in is key to the success. -Typically a mission statement is developed in the early days of the project -when there are fewer contributors, which makes it critical and as a bonus, a -bit easier to have an open discussion and process. Similarly, changing the -mission statement should not be taken lightly, and can be a challenging process -as the community grows and there are a broader range of perspectives. A good -example of this process came from the Zuul project. Project leaders first -drafted example mission statements in an etherpad [#f1]_, which was circulated -to the public mailing list for feedback and new ideas [#f2]_. The list of -ideas from the etherpad was then put to a Condorcet vote [#f3]_ for the same -group of contributors, and the result was: "To provide software and processes +A clear mission statement and goals are essential to create and maintain +balance between contributors, users and the ecosystem around a community. They +should be easy to discover to give a clear view of the community values and +direction to everyone - established and new contributors, adjacent communities, +users, and so forth. + +It is important to spend time on making the mission statement and goals as +clear and simple as possible. In addition, the community can also define a long +term vision which describes the target they would like to reach. The vision can +serve as big picture to provide guidance for actions and decisions. However, as +both technology and the challenges are changing rapidly, it is worthwhile to +revisit the mission, goals and vision periodically to ensure they are still +accurate and update them if necessary. + +This step should be completed while the community is in the forming phase, as +the getting input and buy-in from everyone who is motivated to participate is +key to long term success. The advantage of developing the mission statement in +the early days is having fewer contributors who need to reach consensus through +an open discussion and process. As the community grows and evolves the process +of updating the mission statement and goals should also follow the same open +procedures, even if it seems harder at first. + +A good example to explore is how the Zuul community worked and agreed on their +goals and mission. Project leaders first drafted example mission statements in +an etherpad [#f1]_, which was circulated to the public mailing list for +feedback and new ideas [#f2]_. The list of ideas from the etherpad was then put +to a Condorcet vote [#f3]_ for the same group of contributors to choose the +variant that resonated with most, which was: "To provide software and processes to automate continuous integration, delivery, and deployment of interrelated software projects in a secure manner using project gating." Effective Governance & Leadership --------------------------------- -Any group needs some form of governance. Governance is the set of rules that -the group follows in order to address issues and make decisions. Open source -projects are just another group, so they need governance in order to avoid -decision apathy. There needs to be a place where the buck stops, with a clear -strategy in place to how to solve problems before they arise. +When you are working together with a group of people you will soon need +processes and governance to ensure smooth collaboration and operation. -It is tempting, especially amongst tech people, to start with no rules and to -make them up as you go along. This is anarchy as a form of governance, and a -community formed under the absence of rules will naturally resist later -organization, as something they did not sign up for and resent. +Governance is the set of rules that the group follows in order to address +issues and make decisions that affect the whole community or some of the +sub-groups and to avoid decision apathy. Governance can also help to resolve +any conflicts and help reaching consensus where needed. -It is also tempting to crown the project's initial creator as the "benevolent -dictator for life". That can work well, until the dictator becomes less -interested in the project or sadly disappears, at which point the project -enters governance limbo (as evidenced by the Gentoo and Python examples) with -no clear way forward. Or worse, engages in unchecked toxic and abusive behavior -that drives away contributors who aren't "tough enough" to handle the it. +While you cannot anticipate all challenges that the community will need to +overcome and every governance body that they will need over time, you should +still encourage your community - that you are a part of or supporting - to put +a basic structure in place. This can help to avoid anarchy where you can hit +big road blocks and obstacles if you try to create an organizational structure +later as the community is starting to grow. -A base framework for an Open Community governance would balance 4 basic rules: +There are multiple models to choose from and you can find examples to these +within existing communities. While it is not a common practice, it is an +option to have one person who takes on the responsibility to drive the project. +You can look into the Linux kernel, as an example, where the project's +initial creator became the "benevolent dictator for life" [#f5]_. Even though +the Linux kernel became very successful, this model has many risks that you +need to take into account. If the project leader looses interest or has another +reason to leave the community, it can enter governance limbo with no clear way +forward and challenges to make decisions the community agrees with (you can see +the Gentoo or Python projects as examples). The leader can also engage in toxic +and in some cases abusive behaviors that is hard to control and will affect +existing contributors and make it hard to on-board newcomers. + +A more common way forward is to create governance bodies, which are diverse +groups within the community, that are responsible to help and guide the +community to work towards its mission to achieve its goals. + +To build such framework, you should consider the following four rules: Contributor-driven bodies - It is critical that the people contributing code, documentation, - usage experience, mentoring time or any other form of contribution to - the project are aligned with the leadership of the project. + People who are active participants of the community are the best skilled and + positioned to become leaders. By building the governance bodies form the + project contributors, you can ensure that they are representing the community + that remains aligned with the leadership of the project. - Without contributor-driven bodies, leadership and contributors - gradually drift apart, to the point where the contributors no longer - feel like their leadership represents them, making the disruptive - decision to fork the project under a new, contributor-aligned - governance, generally leaving the old governance body with a - trademark and an empty shell to govern. + Without contributor-driven bodies and leadership contributors will most likely + gradually drift apart, to the point where they no longer feel like their + leadership represents them This can lead to making the disruptive decision to + fork the project under a new, contributor-aligned governance, generally + leaving the old governance body with a trademark and an empty shell to govern. Allowing for replacement - Nobody should be appointed for life, as life will change people. - Contributors should regularly be consulted, and the governance should - generally encourage turnover. + Nobody should be appointed for life. Processes should allow to revisit the + governance bodies and elect new leaders and group members from the community + by the community. This ensures that new views and ideas are brought into the + project leadership. + + It can also avoid the burnout of established leaders as well as encourage new + contributors to join and maintain the project if they have the opportunity to + become one of the leaders over time. Distinct groups call for distinct governance bodies - If a community is made of disjoint groups with little to no overlap - in membership, and those groups all need decisions to be made, then - they probably need to each have their own governance body at that level. + As a community grows it often ends up having disjoint groups with little or + no overlap between them. For example, these groups can be project teams, who + work on different services that make the end product of the community. These + project teams usually need a project leader and a stable group of people who + ensure quality work and efficient processes around that team and service. + + Ever group that is mainly standalone within a community needs to have its own + governance body at that level. Avoid vanity governance bodies - There is no point in having a governance body where there is nothing - to govern and no decision needed. Not every group of people in a - community needs a governance body. + In order to keep balance, the opposite of the former rule also applies. You + should avoid to overload a community with governance bodies which then only + make the community slower and least efficient. Once a community has an initial + framework it needs to be carefully revisited if all the governing bodies are + useful and necessary or if there is a need for a new group for an area that + is yet uncovered and therefore not operating efficiently. There is no one-size-fits-all implementation of these basic rules that would -work for any project. The size of the project is a critical difference. -Sometimes a multiple-level structure to properly balance autonomy and -consistency. +work for every project. The size of the project is a critical factor to take +into consideration, where larger communities may call for a multiple-level +structure to properly balance autonomy and consistency. -We generally recommend using regular elections using a ranking vote mechanism -(Condorcet, STV...). Condorcet is known to favor consensual candidates over -faction candidates. Staggered elections (replacing half the seats at each -election) ensures some leadership continuity. Limits in the number of seats -potentially held by employees from a single organization are usually a good way -to sidestep governance gaming. +Choosing the project leaders could also be a challenging task, but there are +popular ways to build the governing bodies. When a community is forming and +people don't necessarily know each other yet, it can be hard to make a decision +that involves the whole community. A common practice is to appoint the first +group or groups of leaders from the people who launched the project. + +After a first term -that often spans from 6-month to a year- when the community +is operational they are most often switch to an election-based process to find +new members to the governance bodies. Popular choices to make: + +- Use a ranking vote mechanism (Condorcet, STV...) +- Condorcet is known to favor consensual candidates over faction candidates +- Staggered elections (replacing half the seats at each election) ensures some + leadership continuity with the opportunity of new members to introduce +- Limits in the number of seats potentially held by employees from a single + organization are usually a good way to sidestep governance gaming Governance bodies should ideally only make consensual decisions, but when that -proves impossible and a decision needs to be made, a formal vote should be -held. It's useful that the body has an odd number of members to avoid having to -give anyone a tie-breaking specific power. +proves impossible and a decision needs to be made, this can be resolved to hold +a formal vote. You can also consider to have odd numbers of members to the +governance bodies to avoid having to give anyone a tie-breaking specific power. -Some of the things that indicate a healthy community are: +Diversity & Inclusiveness +------------------------- +Open source practices are all about open collaboration without limits and +boundaries, but it's much easier said than done. -Diversity & inclusiveness - Nowhere are the three forces (developers, users, ecosystem) more - important than when dealing with diversity and inclusiveness. +A community has to be an inclusive and safe environment to participate in for +everyone, regardless of their circumstances and characteristics, such as +gender, sexual orientation, disability, physical appearance, body size, race, +nationality or religion. In order to create such environment, you need to +create and maintain a culture within the community, which requires work and +conscious effort from the very first minute. And along with culture and human +behavior, the community also needs inclusive processes. - Providing an inclusive and safe experience for everyone, regardless - of gender, sexual orientation, disability, physical appearance, body - size, race, nationality or religion is not only critical to the - health of the entire open source community, it's something that must - be considered at the beginning of a project. +There are several steps that you can take to create a friendly, welcoming and +accessible environment for everybody no matter who and where they are. This +section mentions a handful of these for you to consider to apply in the +community you support or participate in. Code of Conduct - A code of conduct may not seem necessary as your community is getting - its start. However, creating a path for conflict identification and - resolution at the start can head off issues before they balloon out - of control and alienate valuable contributors and community members. - Make the code of conduct a carefully crafted, but also prominent, part - of the larger strategy to be inclusive and diverse. The OpenStack - Foundation initially adopted the Ubuntu Code of Conduct when - establishing its own. ++++++++++++++++ +While we all have and expects others to bring their best behavior and +intentions, there are cases when people's actions and interactions go beyond a +limit and become harmful. The community needs to be able to define their +standards to state their values, rules and expectations with regards to how +people are expected to behave and treat each other. The document that describes +these items is called a Code of Conduct. - The first lesson learned is the enforcement policy is equally as important - as the code of conduct. We did not put enough thought into how it was - applied or enforced across our various community events and activities. - Delaying the resolution process while your leadership consults legal - experts and attempts to come to a solution can be more damaging than the - violation itself. Having a clear path to enforcement and resolution sends - a strong message to the community that you have thought through the process - and are looking out for their best interest. +While it may seem self explanatory, and with that unnecessary to have from the +launch of the project, it is a crucial step and serves as the foundation to +create the open and inclusive culture and environment that is desired for every +open source community. - Representation? A few years into the project, we worked with the - community, including the Diversity Working Group, to publicly - document an enforcement policy. Again, we looked to another - successful open source community, Python and PyCon, as a basis for - our policy. This policy gives anyone who wants to report an issue a - clear call to action and sets expectations for how it will be handled - and gives the Foundation staff a clear process to follow and removes - the emotion from the process. +There are several well-crafted Code of Conduct documents that you and your +community can use as a basis to create your own with giving recognition to the +original document. As an example, portions of the Open Infrastructure +Foundation's Code of Conduct were derived from the PyCon Conference Code of +Conduct. - Check the health of your community as you go. Do you have something - similar to the following? +To take this a step further, defining your values and expectations is not +enough without a process to be able to enforce it and report violations. It is +very important to address the creation of such process along with the Code of +Conduct document. Having a process to report violations in a clear and +anonymous way and having a similarly clear resolution path are key to make your +community a safe environment for everyone in it. Violating the code of conduct +always have emotional implications and therefore being able to resolve the +conflict as soon as possible is in the best interest of both the community as +well as the individuals involved in the incident. - Groups that advocate for minorities: A working group to help ensure - projects and teams within the community are following the code of conduct - and properly representing diverse voices. +Advocacy and Support +++++++++++++++++++++ +Having a Code of Conduct and continuously putting effort into creating a +friendly and welcoming culture for the project are just the first steps, but +they are not necessarily enough to build a truly diverse community. People, +especially in under represented groups, can have a hard time when they start to +participate in a community that is new to them because of bad experiences +elsewhere or just because of being intimidated to join a larger group of people +who they don't know. - Visible documentation of policies and enforcement +Many communities recognized these challenges and contributors are forming +groups to put more focused efforts into helping newcomers to join a project as +well as to ensure that the community is a safe and friendly environment for +everyone. - Regular surveys and check-ins with your community +The OpenStack community recognized this need early on and formed a group called +Women of OpenStack (WOO), where they set it to their mission to help women in +technology to become part of this project. The group had a mailing list and a +channel on IRC in order to be reachable for anyone in need and they were also +meeting on a regular basis to find ways to advocate for women, and help them +with their first steps and contributions. While the name might suggests, the +group was open for anyone to join, regardless of their gender, who was wanted +to participate in reaching the group's mission and goals. The WOO group also +organized gatherings at OpenStack and some other events as well to reach out to +more and more people in need of their help and support. -The strength of the community can be enhanced through education, culture, -pro-active recruitment, in addition to the processes mentioned above. +Over time the WOO group transformed into the Diversity and Inclusion Working +Group to broaden the group of people to reach out to, as there are many under +represented groups in tech who need to find their voices and freedom to be able +to do what they are passionate about. -Consider that the needs for diversity and inclusiveness extend beyond the -normal development community and must be shared with your users and the -ecosystem at large. Don't assume that you know all of the barriers that your -community members may face. Take the extra steps to pro-actively ask them to -identify the challenges they face in trying to contribute and then break down -barriers to participation whether those barriers are time zones, culture, -gender, age, education, etc. Supporting a diverse set of leaders, both -geographical and by organization, can help reinforce this participation and -will ultimately make for a stronger community. +Inclusive Processes ++++++++++++++++++++ +When we talk about diversity it is easy to focus on the bigger movements that +consider factors like gender, race, religion, and so forth. But being inclusive +is even broader than that. -Contributor Recognition & Motivation ------------------------------------- +Especially in case of larger global communities, simple things like time zones +and spoken language can prevent someone from participating. It is very +important that both the community as a whole as well as individuals in it are +conscious about these factors when they build their processes and define their +ways to collaborate. -An open source project cannot survive without contributors, so it is important -for project leaders to motivate developers and find chances to encourage -them. It could be a mention in the project newsletters or an email sent to -public mailing lists or blog posts. Another good example could be the Open -Infrastructure Community Contributor Awards [#f4]_ which offer recognition to -behind-the-scenes heroes and are nominated at every Summit by other community -members. +To mention a simple example, if your community relies on meetings for strategic +discussions and to make decisions that means that you are excluding all the +people from the decisions making process who are unable to attend these +gatherings for any reason. This violates many pillars of the Four Opens, as the +people who are unable to participate in these discussions cannot make their +voices heard and participate and have much less chance to ever rise to +leadership positions, even if their motivation still remains up. -Open & Transparent Communication --------------------------------- +The OpenInfra communities rely a lot on their mailing lists to ensure that the +discussions that concern project teams or the whole community can reach +everyone before decisions need to be made. It is a conscious decision to +provide enough time and accessible channels for everyone to weigh in regardless +of where they are and what is their native language. On top of mailing lists +you can also use review tools like Gerrit or GitHub to publish items that you +need a decision on. These tools provide the possibility for everyone to read +the problem statement, even without creating a user and sign in, and to join +the discussion which is also logged to keep a conversation history. -Is there anything more emblematic of the modern work-force than attempting to -solve the problem of day-to-day communication? Open source communities face -standard issues of isolation due to remote work, time zone variations, travel, -and so on. There is typically no home office for teams to meet face-to-face in. -Conversely, remote tribes of team members can work together on a project, but -in the same physical office space, creating friction amongst other team -members. - -Highly transparent communication is imperative to help bridge these barriers to -a healthy community. Open communication channels (mailing list, IRC or slack, -web-site) not only help to document decisions, but enable new contributors to -catch up and get involved with the community. Providing a set of open source, -and internationally available, tools will aid collaboration and help build -community. OpenStack initially started collaborating with Google Docs, but -ultimately realized that we excluded a large portion of the world where Google -products were inaccessible/unavailable. - -Host meetings in a way that can be archived and searched, so that the -conversations are accessible to all time-zones and participants who do -not speak English as their first language. Internationalization -(translation, tool choices like google docs, time-zones), in general, -helps foster a more diverse group of contributors. - -Board meetings in particular should be open so that anyone can dial in. -Notes/re-cap should be sent out to the community at large via mailing lists -within 48 hours of the meeting. At the OpenStack Foundation, the transparency -policy for the board developed within the first year. - -In person communication is as important as online. Identify the most -accessible way to leverage the community and their channels to share your -messaging. This can include local user groups, regional meet-ups, -international/national summits, developer mid-cycles. All can be used to -further educate and engage your open source community. - -Branding & positioning ----------------------- - -Branding and positioning is an example of collaboration across forces -and product definition which includes tools and processes. - -Develop with stake-holders, open to community Some degree of -collaboration is useful and necessary, but only to an extent. This is -especially true in regards to visual identity since it can be -subjective and contentious. Design rationale should be provided to the -community to build consensus, but there should be key decision makers -to prevent the ideation process from continuing to infinity. Lessons -learned with project mascots In an attempt to provide consistency we -discovered removed individuality with some projects Slippery slope - -Once the projects got them, every small group also wanted their own -mascot Upside - These are actually picked up and used regularly by the -press and in group events. Critical to develop brand guidelines, to -give community guidelines to extend brand beyond internal resources -Development of consistent UX to be applied to web-sites, -documentation, etc.... This can be tough b/c the needs of the design -team don't always mesh with the needs/methods of developers managing -properties like documentation. Design must be available as an easy -plug in (HTML or javascript snippet) for headers and footers of sites. - -Marketing & Strategy --------------------- - -Once the initial branding and positioning has been finalized, share -with all key stake-holders. The challenge is often identifying the -correct channel to ensure everyone is apprised of updates and changes. -This may take time, but trying different options and even a -combination of a few often helps reinforce the messaging and branding -for the maximum impact. Ahead of the start of the year, identify the -largest areas of opportunity to increase brand visibility and -favorability to create a strategy. After identifying programs, events -and projects that can support the strategy, communicate this back to -the community, reaching out to the marketing teams at the ecosystem -companies directly to participate and provide feedback. This is your -biggest opportunity for a ripple effect. Stay apprised of market share -and user adoption metrics. Share these metrics openly and broadly, -particularly with the ecosystem companies and elected officials who -represent the three forces. This can be done in joint leadership -meetings, both remote and in person, as well as mailing list -newsletters. If the information could be perceived negatively, come -prepared with a solution or action plan to increase confidence of key -stake-holders. It's important to pro-actively share the negative -information when possible to prevent reactionary fear, uncertainty and -doubt. Identify key dates and milestones that celebrate the successes -of the community. Whether it's specific to a force, like a software -release or new case study or specific to the software or community -itself, like results in a market report or participation in a -supported event. This helps create momentum and rewards the positive -community efforts that are impacting another force or even the broader -industry. Leverage collaborative opportunities when possible. If the -broader market perceptions indicate a confusion around facts that -affect one of the three forces, collect the people most affected to -identify a way to pro-actively address the problem. An example would -be that OpenStack is seen as only a private cloud solution. A Public -Cloud Working Group that collaborates to create programs and most -recently messaging that will help alleviate the confusion is a -response that helps leverage the affected parties to address the -overarching issue. - -Events ------- - -Support upstream developers with dedicated space and events to -collaborate and get work done. This includes collaboration within a -project and cross-project collaboration. Create a productive event -that combines upstream developers with operators so that production -challenges and successes can be combined with software road-maps and -bug tracking. Create an opportunity for ecosystem companies to -interact with operators and developers to educate around available -products, gain insights from the market and participate in road-map -discussions. Identify gaps in both the community and the overall -market and use events as an opportunity to gather content, subject -matter experts and adjacent communities to share knowledge and solve -problems. OpenStack Days Industry events - -Education & On-boarding ------------------------ - -The goal is to make the barrier to entry as low as possible. Clear, -discoverable and digestible documentation Recorded and real time -on-boarding sessions - webinars, f2f sessions at events Suggest -training the trainer - creating a toolbox and guidelines to provide -to regional community members so they can lead their own on-boarding -sessions Documented ways to communicate with seasoned experts / join -meetings to accelerate on-boarding. Mentorship programs - -Ambassadors & Meet-ups ----------------------- - -Supporting global communities through user groups, ambassador -program, Providing resources & content for events and meet-ups, and -setting precedents for those events (branding, content, etc.), while -still giving them creative freedom building the relationships first; -find leaders outside of the Foundation to foster new user groups -leaders; collab sessions at Summits using tools available to all -regions community of 90,000; team of 23 (XX ambassadors, 100+ user -groups) Collaborating with local leaders to better understand -regional differences in the technology choices, use cases and -community involvement. Create a way to co-own user group contacts to -ease the transfer of ownership if people leave the community or if -there are any bad actors. - -Cross-community collaboration (NIH) ------------------------------------ - -From the very beginning invite other communities and projects to -collaborate and participate. In turn actively reach out to engage and -participate in other communities to enhance integration efforts. Need -examples here +Diversity is also represented in the ways how people can contribute. Even when +we talk about software development communities, not everyone is a software +developer who participates. You need documentation for the project, a website +where you can share information, people who report issues with the software, +speak at or organize events and many other things that are not about code +development, but essential for the long term success of your project. If you +only focus on and favor the technical contributors, the community will not be +an inclusive place anymore to a lot of people whose knowledge and experience +are key. +Being inclusive can be very challenging due to a lot of circumstances that a +community has to overcome. But it has to be a choice from the first day to +create a culture, where inclusivity is a principle that turns into action every +day, which includes the processes that the community creates to help them to +collaborate without boundaries. .. rubric:: Footnotes @@ -340,4 +293,4 @@ examples here .. [#f2] http://lists.zuul-ci.org/pipermail/zuul-discuss/2018-May/000394.html .. [#f3] https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_708e8e18e160cdcf .. [#f4] https://superuser.openstack.org/articles/open-infrastructure-community-contributor-awards-denver-summit-edition/ - +.. [#f5] https://en.wikipedia.org/wiki/Benevolent_dictator_for_life