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
innovative
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
goals
=== 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
resolve.
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
QA
Bugs
reports
verification
fixes
Documentation
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
resolution
Ownership
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
(Ted)
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)
Offsite notes
Brainstorming Questions
Governance:
What are the issues that we need to address via governance?
What governmental mechanisms do we see being applicable?
Wiki/Website/Communications
things to do?
content to include?
Reduce Private Conversations
?
Target projects towards incorporating collaborators
projects?
collaborators?
how?
==============================================================
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 -
linux
design/usability
wx
python
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
innovative
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?
buzz
QA
bug
expanding test suites
bug verification
Testing
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
designing
participating
join caldav, calsify, http-auth work
help us with marketing
give us money
user participatory design
ad-revenue / eyeballs?
diversity
good tone in community
adult
collegial
friendly
positive
responsible
architectural feedback
success! people asking for support
tweaks - small improvements to main features
surprises
users supporting users
What we don't want?
buzz
outsized expectations
disappointment
negativity / bad attitude
more distraction
requirements outside our goals
forks(?)
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?
calendar
particpating and having your voice heard
credit
hope: ideas / inspiration
get a product that they want
bounties?
organization(s) gets features they want
cost savings
spinoffs
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
Ambivalent:
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
QA
Bug fixes
bug reports
bug verification
* (katie) Extension parcels
Documentation
* (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
design/product
development
build/release
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.
Projects:
* 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
Wrapup:
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
----
Ted Leung Open Source Applications Foundation (OSAF)
PGP Fingerprint: 1003 7870 251F FA71 A59A CEE3 BEBA 2B87 F5FC 4B42
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
