diff --git a/doc/source/activities_and_processes.rst b/doc/source/activities_and_processes.rst index 50a0efa..c8dd39d 100644 --- a/doc/source/activities_and_processes.rst +++ b/doc/source/activities_and_processes.rst @@ -2,161 +2,232 @@ 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 +- Contributor recognition & motivation +- Open & Transparent Communication +- Events +- Education & On-boarding +- Ambassadors & user groups +- Cross-community collaboration 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 solution 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 that 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 succeed long term. 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". 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. - - 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. + 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 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 building a good +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. - Visible documentation of policies and enforcement - - Regular surveys and check-ins with your community +Actions + Inclusive language + Inclusive processes The strength of the community can be enhanced through education, culture, pro-active recruitment, in addition to the processes mentioned above. @@ -173,6 +244,15 @@ will ultimately make for a stronger community. Contributor Recognition & Motivation ------------------------------------ +Contributor motivation is key + Available leadership positions + Making sure contributors' voices are heard + +Contributor recognition + Contributors recognizing each other and share stories + Awards + + An open source project cannot survive without contributors, so it is important for project leaders to motivate developers and find chances to encourage @@ -219,69 +299,6 @@ 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 ------ @@ -301,32 +318,41 @@ 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 +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 +sessions +Documented ways to communicate with seasoned experts / join meetings to +accelerate on-boarding. +Mentorship programs -Ambassadors & Meet-ups ----------------------- +Ambassadors & User Groups +------------------------- Supporting global communities through user groups, ambassador -program, Providing resources & content for events and meet-ups, and +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 +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 +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 +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) ------------------------------------ +Cross-community collaboration +----------------------------- From the very beginning invite other communities and projects to collaborate and participate. In turn actively reach out to engage and