8.5 KiB
How an open project's governance model evolves
As open projects mature, their governance models inevitably change.
Here's how we're evolving ours.
As we continue renovating the Open Organization community, we've been asking hard questions about how we want that community to function. What do we expect of one another, and of the new contributors yet to join us? How will we work best together? And how will we keep one another accountable for achieving our shared goals?
When open projects and communities discuss expectations like these, they're talking about "governance." In this case, "governance" refers to the various processes by which rights and responsibilities get distributed throughout a group. As community member Jen Kelchner puts it, "it's the framework that creates the structure of the organizational system and the rules by which the parts of that structure can and do interact with one another."
A community's governance model explains how that community functions. Maintaining a system of governance often helps a community define and describe the roles people play in that community.
Those shared definitions and descriptions are important. First, they allow community members to speak a common language about values and ambitions. They also advance community members' ability to contribute, because they make explicit the rules everyone is playing by. And they ensure community members receive the various types of status and social capital they need and deserve.
The best governance models are flexible and adaptable. They grow with their communities. As the Open Organization community grows, so does its governance model. We've needed to revisit how we describe our community and the opportunities for contribution it affords people. (We also fix typos.)
Let us describe what we're doing.
New commitments
Through this conversation, we've been able to update the Open Organization project description and vision.
That vision initially took shape nearly five years ago, when the Open Organization Ambassador team first formed. At the time, Red Hat community architects Jason Hibbets and Bryan Behrenshausen drafted a document describing what a community of passionate advocates for open organizational principles might look like. The vision was entirely aspirational, describing what could be—rather than what was. It served as a beacon to attract passionate contributors to a still-nascent project.
As soon as the community did attract new members, however, those members promptly wrote their own mission and vision for the Open Organization project, articulating their identity and purpose. And as we've grown, we've realized that we're all committed to even more than we originally described. Our community is adept at translating open organization principles for various audiences and contexts, and at helping different communities connect to our language and culture through their own languages and cultures.
The best governance models are flexible and adaptable. They grow with their communities.
For example, Laura Hilliger has long seen an overlap between openness and cooperatives (as have others in the community). She's spoken about that overlap and lived it through her career—serving as a translator between two "radical" economic and communal ideas that use different terminology but are seeking the same kind of fair-mindedness in their activities and collaborations. Other Open Org community members have written about Agile methodologies and their association with open principles, open principles at work in educational organizations, and more.
Our commitment to this sort of "translation work" wasn't highlighted in our working project description, so we updated the description to include it.
Role playing
Another hole we wanted to fill was a better description of the types of contributions one can make to this community. We wanted to talk about our contributors in a slightly more nuanced way, which we indicated in the initial project vision and then extrapolated into a fully fledged "Community Roles" wiki page.
Being specific about community roles helps us make the project more inclusive. It also gives us a method to codify policies and procedures because we can associate them with individual roles people can play in the Open Org community.
So we've made some decisions about how contributors get read/write access to community repositories, and how certain kinds of contributors can nominate people to "level up" in the community.
Just as people join communities, they also leave. Everyone's interests and passions change over time, and sometimes what brought them to your community is no longer meaningful to them. And that's okay.
We've also established a new kind of contributor, the "Maintainer," which gives Ambassadors expressing interest in leading and maintaining community-driven projects a way to show ownership and initiative around a particular project the community is working on. In short: It opens an important new contribution pathway and helps existing community members play an even more influential role in the Open Organization project.
And we're also recognizing the regular flux and flow that marks an open community like ours. Just as people join communities, they also leave. Everyone's interests and passions change over time, and sometimes what brought them to your community is no longer meaningful to them. And that's okay.
Sometimes, people will stay involved in a community because they feel a sense of belonging or status, even if they're not interested in doing the work anymore. And they carry with them important project history and context, which no one wants to see evaporate. So we're also adding another community role, the Open Organization Ambassador Emeritus. By giving community members emeritus status, we give Ambassadors the freedom to move on to something else without "kicking them out" of the project altogether.
All in all, defining and documenting roles and responsibilities will help our community attract contribution because it clearly explains what getting involved means and the benefits of doing so.
Next steps
We've come a long way. But there's more to be done.
The next bit of work we'd like to tackle is developing a code of conduct. Want to share your experience in this area? Why not join us and help out?
via: https://opensource.com/open-organization/20/7/evolving-project-governance
作者：Bryan Behrenshausen 选题：lujun9972 译者：译者ID 校对：校对者ID