openinfra
/
four-opens
Code Issues Proposed changes

[WIP] 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 <ildiko.vancsa@gmail.com>
This commit is contained in:
Ildiko Vancsa 2021-02-22 16:22:23 +01:00
parent 7b1470f38e
commit 5bf7325e56
1 changed files with 220 additions and 194 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

414
doc/source/activities_and_processes.rst
View File

@ -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