[Design] Summary of Community discussions at Ops Group offsite
twl at osafoundation.org
Mon Dec 19 11:51:06 PST 2005
During the Operations Group Offsite, we spent several hours
brainstorming and discussing topics related to community. The
general areas that we wanted to discuss were:
1. Project Governance
3. Continued Reduction of Private Communications
4. Creating/Targeting projects at incorporating additional
contributers, particularly groups of contributors.
What follows is a summary of what we actually discussed. We
discussed some topics much more deeply than others. I've included my
raw notes as an attachment for those who want to see more. As
always, questions and comments are welcome.
=== Big Picture Takeaways
If we go back to the original mission/vision, our goals include:
applications (and in today's world, services)
Mitch feels that with 0.6 we have established the capability to move
towards usable product. We now need to add the capability to do
Mitch feels we have crossed a milestone in 0.7; where the tenets we
have are not what Mitch had in mind, but are better than what he had
in mind. This sets the stage for broadening participation in the
We are willing to take some hits to the product schedule in order to
invest more in building community. We are also willing to take on
projects that contribute to community goals as opposed to the product
=== Individual Topic Summaries
We had some discussion of areas where governance issues are
impacting the day to day operation of the project (see the notes for
details), and questions that we expect a governance model to helpe
Mitch said that he would like to have a principle based governance
(like Wikipedia, and perhaps Debian's social contract) rather than a
large system of rules and regulations. This is important because in
the absence of a specific rule, one can always appeal to the
principles for resolution. Some principles will be more important
than others, and all of them will come out of the vision or mission
of the project.
One important principle is that of individual responsibility. We
expect people to take responsibility for making things happen,
although we don't necessarily expect them to do everything
themselves. This is already embodied in the way that we run the
People in the project are given ownership of tasks or projects.
What we mean by ownership is really closer to the notion of
stewardship. People will be given responsibility for good outcomes.
Ownership does not mean dictatorial control, it means taking a
leadership role in collaborating with others, and resolving conflicts
There will be several projects starting up in this area.
Everyone agreed that this is a serious barrier to getting people
to participate or contribute. We spent some amount of time
discussing how to fix this. Ted and Lisa have a project to figure
out what needs to be done. Ted will own the goals/requirements and
Lisa will own the work/team to get this done. It is likely that we
will need a person with information architecture skills in order to
make real progress here.
* Reducing Private Communications
Everyone agreed that this is am important thing to do, and we've
been doing an increasing amount of stuff in the design and
* Targetted Projects
Ted wants to pursue some opportunities to work with small groups
of contributors. In order to make that happen, we need to think of a
small number of projects that we could use for this purpose.
=== Areas where we hope to benefit from community in the short term
(You can see the attached notes for the full list)
Extension parcels - Katie
Testing - Heikki/Aparna
Ports to unsupported platforms - Heikki
Localizations - Brian Kirsch/Philippe)
Feedback Triage council - Jared/Sheila)
For Chandler - dogfood feedback
For Cosmo - feedback from service users
Cosmo test suites
Diversity via infusion from the community
participating in them
Help on standards work
=== Projects we need to undertake to facilitate growing our community:
This is a starting point for our efforts. All of these projects will
get underway during the 0.7 timeframe.
Clarify project governance according to our discussion (Mitch)
Explain principle based approach to governance
List the principles we are using
Explain practical impacts on decision making and conflict
Polling / advisory voting is the norm
Clarify ownership in areas where it is unclear (Katie)
sometimes a group of people is the owner -- product team
Define and clearly and broadly communicate the community goals/plans
Make it easier for people to engage the project (Ted)
Overhaul website and other communications methods (Ted/Lisa)
Move more and more design and development discussions to the
explanation of alignment issues
work to set the right tone
perhaps additional education
Attempt to engage small groups of contributors as well as
Continue to open up design and development processes (Ted)
OSAF staff discussion (email and IRC) of the Fogel book (Ted)
-------------- next part --------------
What are the issues that we need to address via governance?
What governmental mechanisms do we see being applicable?
things to do?
content to include?
Reduce Private Conversations
Target projects towards incorporating collaborators
hard to trust the open process - Stearns
Liked the committers stuff, helped w/ wx situation - DavidS
how to do / role of management - Katie, also Phillippe
good to have a set of basic stuff to have guidance, etc
helped w/ tension btwn engineering manager vs being an open source project => saw a path to reconciling those two ideas - Katie
Mitch - management is shepherding
helped put all the littled details together - Katie
like a society/political process; natural tendency towards democracy - Philippe
helpful re: discussions on dealing w/ mailing lists and conversations in mailing lists - Sheila
share management tasks as well as technical tasks (issues, patch, etc mgrs) - processes are broken when only one person can do that - Jared
strengths - tinderbox release system - are a few complicated/serialized processes in there - Jared
2nd open source book I read; agreed to 80% or more; not a lot of surprises, but good to get confirmation - Heikki
disagreed on scaling (mailing lists, dealing w/ bug database, patch managers etc can't probaby be done by a single person if we have to scale up) - Heikki
descriptive vs prescriptive; structure and formatting section (wants to talk about that more) - Jared
importance of the website - when 2.0 crisis; big need there - Sheila; Jared
crazy idea - delete everything and selectively put stuff back - Mitch
crazy idea - editorialship of wiki is broken, not the wiki itself - Jared
navigation is difficult - Philippe
at least one of the several Mozilla wikis is managed by a tech writer - Heikki
public conversations have surfaced a number of issues that are all of our hard problems - Katie
in agreement w/ what we've heard so far - Mitch
perspective - we have a unique challenge because classic modes are only partially applicable because of our aspirations (mozilla is a good example) - user facingness makes it different - best practices of open source are different for user facing - different scaling problems for user-facing - mozilla recentralized in order to deal with the scaling issues; and needing to have some controls in order to ship 1.5
- going to be uncomfortable at times for people in the next phase - our good instincts might lead us astray in the new world.
- the more open/decentralized things are - you a pay a price in directness in seizing the mountain top
- how do we account for scale?
- somethings work while we are small, but that won't scale
Biggest obstacles to how to get there?
1. Mitch (he said so)
2. community has trouble coming to consensus (if the list decided to go off and do jabber => extra layer. "community will doesn't govern")
3. institutional memory not written down
4. information architecture problems
how to find existing information
good on ramps to information
(other projects are successful but yet have this problem)
5. interested parts have trouble engaging with project
maybe people expect things to be easy and then find out it's hard, they give up
6. expection extending chandler will be easy
7. tension between investing in lists (and community) and hitting release goals
8. governance is not clear
9. hard to know which emails to pay attention to ; what to ignore
10. monolithic chandler project; hard to get involved
11. architecture obstacles to community participation; how does a php scripter hack in the chandler ecology? -- available community is smaller; barrier of entry to non-python people (technologies limit participations);
cosmo and scooby can expand community
new anchor points
12. conflict avoidance - put a lot of energy into avoiding discussions which might turn into a conflict
13. time and energy spent in conflict
14. we do a lot for developers - bug council; specs written for them; we limit their world to just code; so instead of taking responsiblity for their share of the project, we encourage them to blame someone else.
15. major communities we don't engage with -
are we involved in those communities
are people from those communities interacting with us?
do a better job of pushings our changes back into other communities
16. we don't have metrics to answer questions and gauge progress - web page hits
17. people feel the open source process is untrustworthy or scary
18. too much process
19. not enough leadership
20. too little process
21. who is the product team? a governance issue
22. Cabal effect? design/architecture/management team that meets regularly and hands down stuff. things only get done when the cabal meets and then hands something down; perceived as a community disabler. We definitely have a cabal.
23. cabal is a perjorative term for such a group
is the style of decision making dysfunctional vis a vis our goals?
private decision making
recourse mechanisms? recourse at all?
timing of decision making?
24. how to engage with decision making?
25. we are not getting people to do ad-hoc testing
26. overall plausibility? vs calendar plausibility
27. too much hype? historically vs today?
28. mission is not crisp and clear?
29. the nature of what we are doing? desk top app project
30. expectations of directness/deliverables
# of bugs fixed
be clear on what we are aspiring to; see if our behavior matches our aspirations
tension between directed vs open (theme); don't assume that to be open is to forego directness
31. too many goals / expectations
Themes to address:
B. Wiki / Communications
C. Directed vs open - what's the model?
D. Targeting projects
E. Leadership/Conflict avoidance
Theme C - The Model:
Mitch: This where we are in new territory. In the big picture, we want to be faithful to the original vision:
applications (and now add services)
means we need to do things not found in typical open source projects
Q: how to do that in a way that involves a robust and open commmunity?
In 0.6 been successful at the goal of having dogfood. This is really good!
What we do next is partly driven by:
feedback that we get
Mitch would be willing to adjust/slow the rate of project in favor in longer term investment that gets us more of a community base. You could point everybody at achieving 1.0 or you could spread the investment. We have proven w/ 0.6 that we can do product. We need to not lose, that but now add the community part.
"I don't hear anybody saying that we shouldn't hire someone to do communications as their full time job" - Lisa - Mitch "Let's first look at what everybody's job in this space, before doing the 'let's solve this problem by hiring'"
Because Mitch now believes that we've established the capability to move towards usable product, we can make an informed choice about the rate at which we continue to make progress towards the product goals.
Willing to take on projects that contribute to the community goals as opposed to product goals.
Willing to lose some amount of product velocity, but not innovative or user centric - Katie
Might add resources in order to not slow things down.
Original plan had headcount in the mid 30's; for a while we couldn't metabolize the number of people we were adding.
other desktop examples: gimp (which lead to GTK), inkspace (SVG editor - for from a benevolent dictatorship) - philippe
governance by principle - Mitch
how do you make decisions?
what are the criteria for decision making
we don't want to overly depend on hierarchical mechanisms
we don't want to revisit?
what follows our principles and values?
some principles that can help"
your voice counts for more, if you actively contribute - you walk the walk
"this is what we are trying to do" - if you don't like it go somewhere else
we have respect for people w/ training in user centered design.
Mitch feels we have crossed a milestone in 0.7; where the tenets we have are not what Mitch had in mind, but are better than what he had in mind. Sets the stage for broadening participation in design. Feels confidence.
When thinking of he community: Let's look at 1.0 and a sandbox (legitimize activities that might not go into 1.0 but are important on community). w/ improvements in communications and improved on-ramps, then we might get some interesting stuff. Figure out how to facilitate those projects.
Conclusion: agree to mitch's statement of accepting hits to product velocity in order to work on community.
What do we want to get out of community involvement?
What do we want?
expanding test suites
parcels - extensions
scripts - microfeatures
cosmo test sites
cross platform coverage
ports to other platforms
usability design experience people
more people like Mimi / Rashim type people
join caldav, calsify, http-auth work
help us with marketing
give us money
user participatory design
ad-revenue / eyeballs?
good tone in community
success! people asking for support
tweaks - small improvements to main features
users supporting users
What we don't want?
negativity / bad attitude
requirements outside our goals
lots of time on support / squelching development => a price of success
Do we deserve all the stuff in the want list? -- Philippe
What does the community get from us?
particpating and having your voice heard
hope: ideas / inspiration
get a product that they want
organization(s) gets features they want
progress on standards
resolution of csg build vs buy
improvment in other open source projects
an innovative product
non-windows, non-mac platform
Ways we are different?
our culture - diversity
feature contributions in core
Wants that we can get traction on or should try to get traction on in the short term:
(* landing page) Buzz
* (katie) Extension parcels
* (heikki/aparna) Testing - landing page, etc.
Cosmo test suites
* (heikki) Ports to unsupported platforms
* (philippe/bkirsch) Localizations
Good tone in community
Diversity - a chandler course
Help design / do user tests
Usability / design experienced people
* (jared/sheila) Feedback triage council
cosmo support for usage / metrics
* (sheila/jared) Dogfood feedback
What are the obstacles?
(ted/lisa) Website / communications
what does user ed mean?
what's the difference between that and community?
lisa: help files; end users
sheila: which users?
katie: the problem we need to solve is not end users; the problem is helping people engage the project
Mitch: what are the projects that need leadership?
Community development / wrangler
What problems do we expect more explicit governance to help us?
What kinds of elements influence the governance style?
Why is governance on the agenda?
it is impacting our day to day decision making
ex: resolving nits of code base
debug vs release
what are the 0.7 tenets? - how did that decision get made? who got to make that decision.
what's the avenue for people to object/voice countering opinions?
underlies all long running threads
3 categories where governance plays in
does governance need to be the same across?
what are the questions / obstacles / issues
do we always use consensus/voting/majority?
decison maker uses polling as a tool
do we have module owners
is there a product team?
how democratic does it need to be?
will there be too much drag to the style that we pick?
will there be too much bureaucracy / to much overhead?
different goverenance for different areas
do we want to be less democractic about design, more democratic about development
how do we know what to vote on?
who calls votes?
set expectations: what are the rules?
how much weight do manager / owners have
ensure unity of design
how do you contributor? does the notion make sense for design?
can anyone become part of the product team?
what are formal roles? who can take these roles and how?
do we have something like PEPs?
"We don't have anything to be enhanced?"
help reduce chatter
decisions be recorded
be clear on how to register an objection or propose a change - what are avenues of recourse
Mitch ideas by way of wikipedia project (general principles):
1. have generally agreed principles
so you can appeal to the principles for resolution
some principles are more important than others
have discussions about which principles are important and drive for consensus on those principles
principles come out of the vision or the mission
2. principle of individual responsibility
responsibility for making things happen
not necessarily the how it happens
3. a negative goal: a lot of really formalized decision making rules / procedures.
engineers and developers want that.
needing lots of votes is a sign that people are being driven apart
4. in a bunch of ways we're a democracy, in a bunch of ways we are an aristocracy, and a bit of a monarchy; sometimes messy
5. incrementally add governance where we need to; but less is more; and deal with the use cases at hand; let things be a little messy and let things be a little unclear. If there is an owner, the owner decides. -- implies clarifying ownership and assignment of ownership
ietf principles & govt
principles are written down
osaf is missing more governance than we are principles;
Should we have owners?
What does ownership mean
"Steward" vs owner
requirement: one than one person working on one area of code should be ok
Find ways to put the collective responsibilty for respect/civility meme out there.
All voting is consultative and advisory unless everyone who has a stake agrees that the vote will be binding.
Can vote when the question is clear - yes or no.
Owners need to say: Ok, we've made a decision here, on the following basis.
* elucidate principles
* elucidate owners
* (katie/philippe) 20% project - scrum backlog
* (ted) some conversation about community to the OSAF staff
letting people know that we are going to make progress on community at the expense of progress
* that means public conversation - and then engage in a public discussion on public conversations
* mitch to elucidate principles/governance
* conversation re: fogel
....* discuss specific areas where we intend to make progress
Brainstorming worked well
Followup will determine how useful it was
Do at least every 6 months
(* lisa to follow up) How will these initiatives be tracked and communicated widely. - public communication
metricize private e-mail threads
irc = private conversation
-------------- next part --------------
Ted Leung Open Source Applications Foundation (OSAF)
PGP Fingerprint: 1003 7870 251F FA71 A59A CEE3 BEBA 2B87 F5FC 4B42
More information about the Design