Community Meeting 17 Jan 2006

Discussion Threads

• Reactions to the Fogel book
• How to enroll interested participants
• Capturing FAQs, avoiding losing people
• What do we call our different communities
• How do we relate to public negative comments?
• Can we reach out to groups who won't approach us themselves
• Be aware of echo chamber, get broader feedback
• What is our organizational commitment to transparency and decision making authority outside osaf walls?
• Articulate writing can be painful, do it anyway
• Participant contributions needn't be valued equally
• Can "outsiders" earn authority?
• What scope is credibility "spendable" in?
• Forum for community development ideas?

Notes

Q: What stuck out when you read the book?

• comparisons between different open source projects -- put that on the table
• no secret formula: suggestions of what has and hasn't worked well
• a lot of individuality, different projects are different
• also read sun book
• try and avoid distinctions between staff and outsiders
• make procedures and processes clear
• osaf vs project (cosmo, scooby)
• two hundred bases, you should step on most of them
• felt like osaf was doing a good job
• Easier to make decisions, people in a room -- less efficient to do it on mailing lists -- frustrating to write up email, wait for no one to respond to it, then make decision 3 days later

Q: How are we doing as an open source project?

• people looking for basic information, they have trouble finding it

Q: Should we take the same approach across the projects? (e.g. contributor license)

• already have different licenses
• some things would make sense to not duplicate
• project is shaped by individuals, so expect projects to have slightly different flavors
• some prefer to leave mechanics up to individual projects
• could share legal template
• clearly defined where we can wiggle and where we can't

Q: How to respond when someone asks what process they should follow when engaging with the project?

• Cosmo has a pressing need, a potential volunteer asking for this information
• Ted is a resource for all projects, his role is as knowledge transfer agent
• It would be satifsying to have a checklist of what needs to be done by each project

Q: People are showing up in irc at off hours and its clear that they don't know where to find information.

• We are looking at overhauling information architecture of website and wiki.
• We have agreement that we could use some help (like mozilla developer site), get someone to help lead a similar kind of effort.
• Structured brainstorm, workshop meeting, open meeting, Ted and Jared are putting it together.
• We can take measures in the interim, including collaborating on a FAQ.
• Make it easy for people to know the canonical place to find information.

Q: Have we defined what our community is?

• Hackers
• Users
• people interested in anything open source
• people who are negative about the project and want to bring it down
• translators (not developers)

Q: Is there a problem with people being negative about the project?

• We can responding efficiently in forums to prevent a negative bubble.
• Perhaps ignore non substantive comments
• coordinated, factual response
• mixed feelings about responding to negative comments
• pr is everyone's responsibility

Q: Should we be preventing unrealistic expectations?

• the more polished our website, more expectation that we have a polished product
• make level of polish on materials, website match polish of project

Q: How do we define the community we want and seek out those people?

• Perhaps any negative reaction is happening in a contained community that is sort of incestuous, only a small microcosm.
• We've attracted some pim enthusiasts -- some don't have problems they are trying to solve with information management but enjoy thinking about it at an abstract level.
• It might be worth seeking a community that does not necessarily identify as being interested in an open source project. With some initial engagement with us they may be happy to participate as users.
• Example suggestion from csg: groups of elderly people who manage information and don't currently have appropriate tools. This group might not overlap our target of people who manage a lot of information, but might be interesting user base because they are far from what we know about already.

Q: What is purpose of writing things up?

• create transparency for internal clarity, coherence and accountability
• get outside input
• create a record of decision making and reasoning over the long term
• Observation: we always do better when stuff gets written down.
• Private work optimizes things in the short term, but not good in the long run.
• In the short term, it takes longer to write things up and involve people more broadly
• To get leverage in open source, figure out how to get more people involved and helping
• People self select to participate in ways that they provide value
• As staff, we need to think about how we provide leverage
• Internalize: the act of writing and articulating what you are trying to do helps you focus on the decisions you are trying to make.
• Its a generalization that writing helps you work out a problem, not all people work the same way. Some people like to write code first to understand a problem - people find their own rhythm.
• Technique: write as if you are writing informally to a friend/close colleague, then actually send it to the list

Goal: seeking to increase community participation dramatically

• we will do it until we get it right
• users: information intensive, but not necessarily technical
• ask what are our first principles?
• when people come with this or that agenda, be polite but don't need to be equally receptive to everyone's agenda
• community volunteers that help us get to our major goals, that is great
• people who want to do other stuff, we have a different stance (at the moment)
• not a free for all, helps build a community if it is clear what this project is about, easier to decide
• pim enthusiasts are not always exactly a direct fit
• we've done a pretty good job of not being distracted, but each new wave of interest will bring new people with agendas that may not be aligned

Q: Is there a way that an outside person can gain authority (credibility/influence)?

• staff member can rely that someone will respond
• make it clear that people can earn credibility and authority
• communicate more clearly that you can earn this
• How do we convey that notion to people coming to the project: what are the rules of engagement of the project?
• Requires expectation setting about what can be changed, what decisions are already made, etc.

Q: What is our governance model?

• what is the chain of command?
• don't want highly elaborated set of rules about how decisions are made, certain principles apply that are widely held among staff and community, and are the basis of legitimizing decisions
• discussion about what are the relevant principles and how do they play out
• Every team has the notion of a set of core contributors.
  • benevolent dictator model: dictator can say no
• Good to make it clear: if you want to participate, this is how you participate
• Perhaps it will become more clear with examples

Q: What is the scope of influence that someone can have if they are not on staff?

• What can be influenced, what cannot be influenced?
• Perhaps the vast majority of contributions will end up being qa, translations, etc.
• To have a huge impact on the core and future direction, implies a big committment and some accountability
• The more modularized we are, the easier it is for someone to impact one module, without being a dependency on the main schedule
• We're open to non-staff members having more influence