Community Meeting 17 Jan 2006
- 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?
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?
- 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