r3 - 26 Jan 2006 - 11:51:55 - KatieCappsParlanteYou are here: OSAF >  Journal Web  >  CommunityHome > CommunityMtg20060117

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
Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r3 < r2 < r1 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.