ParticipationSystems: Difference between revisions

Copy edit after discussion w/ george
m (→‎Discourse Evolution: Added community ops to consulted)
(Copy edit after discussion w/ george)
Line 3: Line 3:
== Vision ==
== Vision ==


This program strives to create a Mozilla that is understandable, approachable, collaborative, satisfying to work with, well managed and diverse.  
This program’s purpose is to align the software and IT systems that we use to match our aspiration for being a great participatory organization, welcoming to staff, volunteers and allied communities alike. We want work at Mozilla to, in general, not care whether you’re an employee or not. Our software tools need to move to match that vision, and encourage (responsible) openness.
 
If we do this work right:
* We will have facilitated diversity and inclusion at Mozilla. We will become a benchmark for how to harness the collective intelligence of thousands of people to achieve an ambitious vision
* Community participation will be a core muscle available to all parts of Mozilla. It will be well run and programs will be routinely build in participation because they will provide real value
* High value contributions will result because Mozilla is knowable and understandable, and its pursuits are compelling. People are attracted to the project, see where they can contribute and how to do so
* When interacting with Mozilla, people will naturally locate themselves in the right context and altitude, and they will be able to naturally and appropriately connect with staff
* Their work is enjoyable, they get value out of working on Mozilla projects and they become confident that their efforts are impactful and recognized
* Mission aligned contributors and leaders will effectively work with us to invent, shape and defend the internet


== Current Challenges ==
== Current Challenges ==


We have a legacy to clean up: Mozilla is too messy & complicated to engage with all volunteers.  
We have a legacy to clean up: the systems we use at Mozilla are too messy and complicated -- this makes us less engaging and less able to strategically work across employee-volunteer-community boundaries.


Our leadership is unified, but the organization and its “operating system” isn’t yet. We have vestigial walls that need to be taken down, and some new systems that need to get built.
Our leadership is unified in wanting Mozilla to be truly open to volunteer participation, but the organization and its “operating system” needs some tweaks. We have walls that need to be taken down, and some new systems that need to get built.


== Identified pain points ==
== Identified pain points ==


# At a time of massive strategic change, boundaries between people are getting in the way of making headway
# The most frequent information and collaboration systems need to be accessible at least to NDA’ed volunteers (specifically, google documents/slides/etc and content that is in Mana)
#* no layered collaboration with different audiences
# We don’t have an identity system for volunteers, while we know that identity can unlock access and collaboration.  This is complex given the broader need for an identity strategy for staff that is happening in parallel.
# Systems of participation do not allow us to be strategic
# We have a set of useful components such as Mozillians, LDAP, etc, but they’re not yet integrated.
#* no tracking of who is doing what
# Volunteers who want to manage their contributions and touch-points with Mozilla have to interact with many different of systems and processes that are inconsistent and don't relate or speak to one another. This also makes it hard for them to find/understand opportunities for participation that exist.
# The volunteers we need often find it unrewarding and unnecessarily difficult to contribute to Mozilla
# We have no understanding of volunteer involvement in different areas (advocacy, coding, SuMo, innovation), and limited/fragmented tools and limited systems that allow us to manage our relationship with volunteers and help them be effective.
#* current enterprise habits provide friction in interactions with non-staff
#* current practice hampers community & reduces impact
#* fragmented relationship for Mozilla and the volunteers
# Past approaches to solving this have been ad hoc across Mozilla
#* bespoke, unconnected systems for different teams and areas


== How do we plan to provide change ==
== How do we plan to provide change ==
Confirmed users, Bureaucrats and Sysops emeriti
525

edits