Open Community Section
This commit is contained in:
parent
b07c46afb2
commit
0a930ba614
305
docs/opencommunity.rst
Normal file
305
docs/opencommunity.rst
Normal file
@ -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
|
||||||
|
|
Loading…
Reference in New Issue
Block a user