diff --git a/docs/opencommunity.rst b/docs/opencommunity.rst new file mode 100644 index 0000000..bfe8651 --- /dev/null +++ b/docs/opencommunity.rst @@ -0,0 +1,305 @@ +============== +Open Community +============== + + One of our core goals is to maintain a healthy, vibrant developer and user + community. Most decisions are made using a lazy consensus model. All + processes are documented, open and transparent. + + The technical governance of the project is provided by the community + itself, with contributors electing team leads and members of the Technical + Committee. + + All project meetings are held in public IRC channels and recorded. + Additional technical communication is through public mailing lists and is + archived. + +"Open Community" is the critical piece of the Four Opens puzzle. It embodies +the key difference with single-vendor controlled open source projects. It is +about ensuring that the community is a cohesive, inclusive, level playing +ground where all the voices are heard and anyone can rise to leadership +positions. + +To build a truly open community, you need to balance the three forces: +developers, users and ecosystem. It's easy to think simply in terms of upstream +and downstream, but communities are complex organisms, and the reality is much +more dynamic. It's important to establish common goals and build strong +connections between the forces, because operating in silos will dilute the +power of the community. Each force affects the others and they have to be +working in harmony to achieve anything. + +Open Community defines how to best align these forces through: + +- Common mission & goals. - Effective governance & leadership. - Diversity & + Inclusiveness. - Contributor recognition & motivation. - 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 +---------------------- +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. + +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, which was circulated to the +public mailing list for feedback and new ideas [link to archive]. The list of +ideas from the etherpad was then put to a Condorcet vote [link to archive] for +the same group of contributors, and the result was: + +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. + +It is tempting, especially amongst tech people, to start with no rule, to to +make them up as you go along. This is anarchy as a form of governance, and a +community formed under the absence of rule will naturally resist later +organization, as something they did not sign up for and resent. + +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. + +A base framework for an Open Community governance would balance 4 basic 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. + +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. + +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. + +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. + +There is no one-size-fits-all implementation of those 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. + +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. + +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. + +Some of the things that indicate a healthy community are: + +Diversity & inclusiveness Nowhere are the three forces (developers, users, +ecosystem) more important than when dealing with diversity and inclusiveness. +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. + +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 carefully crafted, but also prominent, part of larger strategy to be +inclusive and diverse. The OpenStack Foundation initially adopted the Ubuntu +Code of Conduct when establishing its own. + + 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. + +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. + + Check the health of your community as you go. Do you have something similar + to the following? + + 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. + + Visible documentation of policies and enforcement + + Regular surveys and check-ins with your community + +The strength of the community can be enhanced through education, culture, +pro-active recruitment, in addition to the processes mentioned above. + +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. + +Contributor Recognition & Motivation + +Communication + +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 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 (example of collaboration across forces, product +definition) including 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 Goal 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 +