[Design] Summary of Community discussions at Ops Group offsite

Ted Leung 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
2. Wiki/Website/Communiations
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:
     high quality
     user centric
     open source
     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  
community design/development.

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  
design process.

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

* Governance
   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  
project today.
   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  
if necessary.
   There will be several projects starting up in this area.

* Wiki/Website
   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  
development lists.

* 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
     CalDAV hacks
     Interop testing
     Diversity via infusion from the community
     User Tests
         designing them
         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  
lists (Ted/All)
         training period
         explanation of alignment issues
         work to set the right tone
         perhaps additional education

     Attempt to engage small groups of contributors as well as  
individuals (Ted)

Continue to open up design and development processes (Ted)
     OSAF staff discussion (email and IRC) of the Fogel book (Ted)

-------------- next part --------------
Offsite notes

Brainstorming Questions

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


Fogel book:

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
    ex: syncml
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
    different technogies
    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
    clear tenets
    # 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:

A. Governance
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:
    high quality
    user centric
    open source
    applications (and now add services)

means we need to do things not found in typical open source projects
    integrate design
    good QA
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
        bug verification
    dogfood feedback
    developer help
        bug fixes
        parcels - extensions
        scripts - microfeatures
        core development
    cosmo test sites
    caldav hacks
    interoperability testing
    cross platform coverage
        linux platforms
    ports to other platforms
    localized products
    usability design experience people
        more people like Mimi / Rashim type people
    documentation help
    user tests
    join caldav, calsify, http-auth work
    help us with marketing
    give us money
    user participatory design
    ad-revenue / eyeballs?
    good tone in community
    architectural feedback
    success! people asking for support
    tweaks - small improvements to main features
    users supporting users

What we don't want?
    outsized expectations
        negativity / bad attitude
    more distraction
    requirements outside our goals
    architectural feedback
    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
    cost savings
    progress on standards
    resolution of csg build vs buy
    better collaboration
    improvment in other open source projects
    an innovative product
    non-windows, non-mac platform
    time savings
    productivity improvements

    feature suggestions

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
    Bug fixes
        bug reports
        bug verification
    * (katie) Extension parcels
    * (heikki/aparna) Testing - landing page, etc.
    Cosmo test suites
    Caldav hacks
    Interop testing
    * (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
    Standards help
    * (jared/sheila) Feedback triage council
        cosmo support for usage / metrics    
        * (sheila/jared) Dogfood feedback

What are the obstacles?
    Current phase
    Shared commitment
    (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? 
                chandler users
                scooby users
                cosmo administrators
            katie: the problem we need to solve is not end users; the problem is helping people engage the project
        technical writer:
            api docs
            other stuff
            website content
    Mitch: what are the projects that need leadership?
    Community development / wrangler
        forum administration
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
            tinderbox sheriff
            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?
        different categories
        different roles
        different projects
    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
    improve consensus
    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
        note taking/summariziation
-------------- 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 mailing list