Session Notes

From Community Leadership Summit Wiki

This page is where you can add session notes from your sessions at the Community Leadership Summit 2009. Doing so is simple, just follow these instructions:

  • Add a title for your session, with three-= (===) heading level.
  • Include session time, title, and room/group number
  • Type in your notes


Link your session notes directly from the Session schedule Saturday 2009 and Session schedule Sunday 2009 page.

Contents

Session Notes

Saturday, July 18, 2009

11am mysql future session #3

Monty Widenius

You can watch directly from wikimedia or download a portion of this session.

What's up with MySQL?

Drupal developer: they have concerns about business direction of MySQL. Broadening Drupal so they're less dependent on MySQL (mostly in Drupal Fields API), while also trying to make Drupal work more efficiently with MySQL.

Others: Many customers are asking whether Oracle can be trusted to keep developing upgrading MySQL. It can' go away because it's under the GPL.

Some discussion of MySQL AB business model and its relation to duel-licensing and GPL.

Original duel-licensing developed by MySQL AB still in effect at Sun, will also be used by MariaDB. If you want to incorporate MySQL into your commercial product without opening your code, get a commercial license.

Some claims that duel-licensing inhibited community involvement, others say that it was just a technicality and that management attitude toward community was real inhibitor. MariaDB proponents claim that MySQL AB/Sun management in later years deliberately decided not to pursue contributions from user base.

Contemplating about the Future

Suggestion that they offer quid-pro-quo to contributor's code: either pay contributor or promise that any product that incorporates that code remain under open source for at least two years.

Advantages of duel-licensing for MariaDB same as for MySQL AB. In addition, makes it possible to contribute code back to Oracle core, and to buy core back from Oracle if advantageous to both.

Advantages of open source: even though the management of many large companies say they don't care whether the software is open source, developers at lots of companies do make changes to code.

Bruce Perens

MariaDB trying to ensure MySQL will flourish regardless of Oracle's support. MariaDB will not try to be a single company that will grow and can be bought. Monty, founder and owner, says they will hire developers but not use consultants, letting Percona and others create code independently. Interested in fostering an ecology of community modules, as other popular open source projects have. MariaDB leaves front-line support to others but fixes bugs in the code. Directs money as much as possible to its employees to recruit the best. Oracle can't pre-empt MariaDB because MariaDB has all the core people on a very complex project.

Oracle has not made any announcement about their plans for MySQL. Most software companies like to deliver products on free platforms, so MySQL can be useful to Oracle. And they know it will stay alive anyway. Monty suggested that Oracle is likely to add proprietary add-ons.

Knights of the MySQL Round Table

Can anti-trust law keep Oracle from doing things that could make it hard for small companies such as MariaDB, such as putting in features that make MySQL interoperate with Oracle? Oracle would probably gain no advantage by doing those things anyway.

Drizzle is a small MySQL that makes non-enterprise features optional. Seems to be convenient if there are Oracle managers who want to suppress MySQL's attractiveness to the enterprise. Monty predicted that Drizzle will be developed outside the company after an Oracle purchase.

Open Database Alliance could come to cover other open source databases besides MySQL.

Attendees:

Monty Widenius

Henrik Ingo

Kurt von Finck

Newton Chan

Erik Kort

David Schlesorsk

Andy Oram

Deirdre Straughan

Vivek Ayer

Emil Eifrem

Bryan Smith

Bradley M. Kuhn

David Strauss

Larry Rosen

Chris Messina

Bruce Perens

11am tools session #7

organizer: Kaliya - user centric identity

BJ women; meetup; wikianswers.com; mozilla; maps/tomtom; oreilly

too many email lists. tools to monitor activity bursts. irc monitoring. yahoo pipes.


use mess of perl scripts (amm auto meta news). reverse bastard copyleft - will release under. Mozilla planet - using thunderbird to read feeds, no good. agregating all blogs under one roof. Google shared items. can restrict to recent blog entries. HAving a planet is a good thing. Hen Apache: svnsearch.org - a way to create subversion history of a project. Markmail.org (aggreg mailing lists). Apache attic; how to tell if community is dead. Wikianswers: Message boards - private discussions, but publicly visible. How to delegate tasks - find moderators. Q: how to come up with a tool that promotes delegation. Promote users to supervisor. Clever admin pages. How about a reputation system. SVN uses "contibulizer" tool that finds comments, compiles contributor lists. Spots good contributors.

Maemo.org - Nokia community. Uses karma system that measures contributions over time. See who is most active in aspects of site. Bugzilla, forums, midgard - queries into the database, phpbb. Opensource world has attendeance counts and audience ratings for speakers. Used for rating and inviting next year. Validate participants via a point system. Find people that you can give a larger role.

Fedora community - talk to action ratio. Talks a lot, but doesn't commit a patch. NSR. Looking at mailing lists. Meetbot. Evaluate content from personas.

MS codeplex - identified 5 personas that they categorize people in. Timid, pro, etc.

Visualization tools --- evaluate online content, produce spreadsheet. Getsatisfaction - some people clog up the forums with their problems. Send them to getsatisfaction. emotive karma system-contiributions are rated by usefulness, how they make people feel. stackoverflow - add contributions to questions. rate usefulness of answer. Culture! Encourage people to plagiarize others content and improve on it. All rep systems boil down to some judgement.

Standards for identity on the internet.

Meetup: try to help sharing across groups.

corporate twitter tool: catch tweets about a company or product and assign to operators that work on them. Needed tool to combine: Google alert, etc. radiant 6 - $500/month. Biz360. Search not only blog mentions, but also in comments. Can become really expensive. A dashboard is totally needed.

the MS codeplex lady uses Tweetdeck with a codeplex panel open all the time. Raw twitter search prefered - everyone gets a voice.

Red cross has "professional listener" that searches every morning for red cross mentions.

---> tools that should exist. Find out what someone you come across has done before. Community CRM. Name, short bio, all identifiers. Get all of someone's identity information. Gets the whole context of someone's online identity. Will make community seem smaller, so that it can grow bigger. Build on cvCRM. Djangopeople.net does something similar. Community pressure to get an entry. People can manage their own data. jay@mozilla.com working on it.

Facebook gives recognition by tracking top people.

SugarCRM for community management? SOme people try to use it.

Useful metrics for people to monitor. FInd flame wars. Joey Hess has a tool for analyzing the shape of threads. Bash scripts for analyzing average lengths of threads. Papers on the subject are out- people at heart of conversation. Univ of Syracuse.

Mozilla forums are accessible by mail, news and RSS. Easiest way via Google groups. Plug mailman in everywhere. Mailman archives suck.

lettermelater.com - same questions every month. Wanted: Get people to tag conversations so that it can be followed online.

Martin 20:56, 18 July 2009 (UTC)

11am Session #9: Playing into the Future, a project jam

The purpose of this session was to develop inspiring project ideas to build towards a positive future and innovate through collaborative play. An intention is that the experience and artifacts of the session could inspire future work of participants in session and new projects to be exhibited in the Program for the Future, built upon the collaboration principles of Doug Engelbart. The methodology of this session is derived from Change Jam, an open source group method for project formation, developed in Dreamfish.

Session initiators

  • Tiffany von Emmel, Dreamfish - [[1]]
  • Mei Lin Fung, Program for the Future - [2]]

Attendees

  • Rich Reader - video
  • Peter Kaminski - Social software expert, Dreamfish
  • Cliff Figallo, GuildSmith - how local communities will network.
  • Chris - Ubuntu
  • Bob Ketner, Virtual Communities Manager at The Tech
  • Aaditya Batia, Developer Intern at The Tech
  • Stina Cooke, Museum Exhibit Designer formerly from Boston Science Museum
  • Veera Swaminathan, Singapore Ambassador for the Program for the Future Challenge
  • Grant Bowman
  • Teresa, Open Solaris
  • Michael Tiemann, Open Science and Tech museum, Signis, RedHat

Video http://richreader.blogspot.com/2009/07/playing-into-future.html

Photos Community Leadership Summit Group - http://www.flickr.com/groups/1153088@N20/

Break out themes

  • Collaborative Platforms
  • Consensus / organize information
  • Working together to create new ways to do things

Jam Design We did micro-version of Change Jam, because of the short time slot (see long format at Change Jam - http://www.socialtext.net/changejam/index.cgi ).

  • Speed dating of project ideas: Where would I like to contribute?
  • Listeners write on the other's card.
  • Synthesize idea on sticky note, then put in the center and together to see if there are synergies.
  • Clusters break out to form project ideas.
    • use project idea template on fun stock paper as scratch pad
  • Create Project Names
  • Clusters reports back to large group in a performative way.
  • Write "Project Name x" on Paper fish, pinned
  • Go forth: How we can have fun playing into the future at this conference?
  • Following up with people within a couple days to further project ideas that got traction.


2pm Session #5: Creating new government

Creating_new_government

2pm Session #7: Money and community

Money in communities

3pm video blogging session #5

Video blogging

Moderator: Deirdré Straughan, Community Strategist and Social Media Producer at Sun

http://blogs.sun.com/deirdre/entry/what_i_m_doing_in

Interests of group: learn how to easily do video blogging, encourage participation by amateurs. Some already putting up videos, such as of speaker presentations.

Professional video services usually prohibitively expensive

Can get perfectly good results with consumer or prosumer equipment

Look for a camera with a standard hot shoe, so lots of other things can connect. Also good to have a head phone jack, solves the problem of poor sound. Have one that has both battery and wall power, in case someone trips on the cord when you're filming.

Lighting and sound can be difficult to get right

Instead of connecting mike to camera, because it's a mini-jack. Instead can attach XLR adaptor to mini-jack, or something like Beachtek with two XLR adaptor, is placed between tripod and camera and has its own volume control.

Hearing is more important than seeing well, people will put up with poor lighting.

Some lenses on cheaper cameras don't do zoom well. They take in a large scene, crop it to the area you're zooming to, and expand the area--harming visual quality significantly.

Conference sites usually have the cables and extras you need, better than trying to carry every possibility around yourself.

Wireless mikes useful. You can attach the transmitter to a professional sound board if one is available, attach receiver to camera.

But you have to make sure the professional sound board is set up right. Sometimes there's something making noise near the sound board.

If you have multiple cameras, you can depend on different cameras for parts that get lost, but results are hard to edit.

RODE has a directional mike for less than $200, sits on camera. Shotgun microphone allows you to aim at audience when someone is talking. Shotgun microphone is convenient, but better to get the mike right next to the speaker.

Compact tripod can be compressed to 18 inches high.

Length: people are willing to watch something long so long as you have something to say. Don't feel pressured to cut down content.

Blip.tv has a resumable upload, useful if you're overseas or in another area with uncertain connectivity.

Vimeo.com has no limits on length of video uploaded.

Fora.tv is trying to acquire serious technical content, may film you in the Bay Area for no extra cost. Normally charges $500 to take an hour and edit it.

Editing takes the most time. Editing takes two to sixty times as much time as the videoing. A lot of the time is taken up by cutting unnecessary material.

Don't feel that you need well-honed skills and expensive editing software: you can do a lot for a blog with modest skills and consumer-grade software.

Some sites let you download to phone, YouTube streams to phone instead.

Parleys.com offers client for downloading.

Seesmic.com is a social networking community built on video, has good interface.

Hard to get video responses, very few in comparison with text responses.

Streaming: Veodia.com, Dyyno.com. Dyyno stores on your own system while streaming it out, so make sure you do a backup later.

Live streaming takes a lot of bandwidth, needs Ethernet. Need 360 Kb for 30 frames per second.

Live chat useful to feed questions from remote audience back into live event.

Very active speaker can show pixel jitter when you're streaming.

On the other hand, speakers unfamiliar with the camera may be afraid to move at all, so tell them it's OK to move. But you can limit the range by putting marks on the floor if they're comfortable with that.

Streaming sites usually don't accept HD, so set camera to DV.

SD chips can be good if the camera is good, but you need an SD chip with sufficient memory. Tape is usually more cost effective, but don't edit the tape because quality will degrade; use tape just to take the video and then load it on a computer.

Attendees

Andy Oram

BJ Wishinsky

Rich Reader

M. K. Fox

Rikki Kite

Irene Koehler

Jeff Osier-Mixon

Brett Husbands

Mei Lin Fung

Greg Weinstein

Kieren Lal

Mary Vincent

Shirley Lin

Michael Van Riper

Sara N Choudary

3pm Session #9: Trademarks vs. Community

Trademark of Brands:

In the US: If the name belongs to everyone, then it belongs to no one. In Brazil: Another company registered the trademark 'OpenOffice', and, when OpenOffice.org distributed some OpenOffice CDs, they were sued via the Brazilian gov't. In Germany: If you violate a trademark, you receive an invoice from the Government for a large sum of money. After the fact, which may be the first time you hear that you have violated a trademark.

All of us who are in communities are ultimately heading for trademark problems.

Examples:

  • Mozilla didn't provide a good 'unofficial' name for community edition. Iceweasel was a result of a fork that didn't have another option. Firefox is the most popular end-user open source project in the world. And if
  • Debian - Official Brand vs. Unofficial Brand. Official Debian CDs must have a specific binary.
  • Linux - Linux was registered before Linus Torvalds did and he had to get it back.
  • Joomla - 5,000 joom-sites, so, to protect the trademark, they must fill out a form to agree with the Joomla terms of service. Don't have to wait for a letter.
    • Group agrees that if you don't control the name, you may lose your trademark.
    • if there is a trademark involved, then every use must be licensed, and the license must involve some sort of quality.
    • If you don't, then someday a corp. will take you to court and use as evidence.
  • Eclipse - has chosen NOT to reinforce its own trademark, but the attendees of this session believed this wasn't appropriate. (In other words, they should have.)
  • Example: "We grant licenses to companies on these conditions". (You must control the quality via the license, but you don't have to specify high quality.)
    • Non-infringing uses of the trademark don't threaten the trademark, so someone could say "Such and such for Joomla", which would be OK. (In legal jargon, this is called "nominative usage".)
  • If you are trying to change the software, then there should be a 'build flag' that will 'build' the software product without the product name.

4:15pm session 5: Encouraging good behaviour in meetings

Promoting good behaviour in meetings

4:15pm session 7: How do you describe what you do? ("Elevator pitch")

There was some confusion about the scheduling of this session. A small quorum showed up (four people) but not the official moderator. We decided to brainstorm on the problem anyway.

  • Organizer: None

We all agreed that describing open source work to non-technical folks is hard. The first strategy identified, therefore, was to skip that part: talk about the end product rather than the open-source approach: 

I help ensure that official voting results really match the ballots cast
I contribute to a suite of office-worker software tools
I enhance a document-publishing system to do stuff for my customers

Turning to the difficult part of describing open-source work to non-technical listeners, we found several approaches: 

I freely share my work with others who have agreed to freely share their work with me

I create (or enhance) infrastructure on which my customers want to build products and value.

Our field is moving so quickly, we can profit by being first, and use open-source development to ensure there's always something newer to be first in.

Sunday, July 19, 2009

11:00am: Quality Assurance in communities (Session 2, Room C4)

Moderator: Louis Suarez-Potts, OpenOffice.org

Community very valuable--someone running an unusual combination of options or languages will turn up a bug no one else would find--but not predictable enough. Need releases that satisfy corporate demands.

What standards to use, and how to coordinate? Has to work with informal testers such as students and instructors, for instance, which OOO often works with.

How do we articulate power? How important are bugs affecting particular communities such as localization?

May have competing interests from different corporations or even corporate offices in one corporation.

Recommendation: set up QA team early in the project. If you have a central team, such as a company, include some customers on it.

IRC or other text-based communication is useful so people from many cultures can participate. More people can read and write English than are comfortable speaking and hearing it.

Bilingual users valuable because they can let you know about bugs in language versions that no one on the core team knows.

How handle thousands of bug reports, poorly described?

Wine developer: Wine does it informally, doesn't work well. Holding a developer bug day. Online, not face-to-face.

Mozilla has bug day too. Get together a set of volunteer triagers. Trying to get volunteers to actually lead bug days. Coordinate through IRC, not face-to-face. Hold bug days close to releases to verify that bugs are fixed. Monthly bug days also.

In Germany, OOO gets together students for bug fixing, who actually have fun.

How do you organize bugs? Wine has links to low-hanging fruit. Just lets you search all bugs, look particularly at old ones (over six months).

Useful to indicate dependencies, difficulty of fixing a bug. Whom to ask on IRC or wherever. Manager should be there to keep up interest.

In-person meetings really help, because friendlier environment and goes faster.

Mozilla lists bugs by component.

Glassfish uses Sun-specific environment.

Another model: 6 or 7 developers but open to external inputs. Structured input with as much detail as possible. Triaging meeting once a week evaluates every bug and assigns to right person. When funded, started QA, process for releases, etc.

Open source products rarely include QA and resources needed when pitching to funders.

How does QA for distributed model differ from centralized one?

Important to have well-managed releases, release on time. Wine didn't really have releases for first years, until picked a volunteer to organize a release. Need someone to coordinate.

BSD had 25 releases at regular six-month intervals.

Why important to be on time? To meet user expectations, also developers.

Wine releases a beta, users can track the progress of their bug reports.

Another model: set a goal for features and quality, release once the software is ready.

Internal developers on Qt motivated to fix bugs because huge user base will jump on bugs.

Important to make sure the people you want to test have access to your resources, such as existing unit tests. Customers sometimes have their own regression tests, and you want to let them know when you test those things so they can remove tests.

Many projects (particularly started by companies) have internal and external communities. Important to treat all users at same level, not reserving certain functions for certain people. Such projects have to work out carefully the relationship between internal and external communities.

Even a volunteer-driven project may have privileged developers (such as a security team) with access to an internal bug database; not all bugs are in the public database.

Open source projects, like commercial ones, receive notices of security problems privately. How do you choose people for a security team? And how do you hide a bug that you don't want the public to know about.

How do you distribute a security fix that might be a major download and installation task? Some projects modularize updates so only the patched part has to be downloaded.

Give customers a warning that an important update is coming. If an exploit is publicized, the discussion over the fix might as well be public as well.

How do you report the severity of a security problem without hurting the credibility of the project? Tempting to retreat to PR euphemisms.

Privacy of customers must be respected when publishing bug reports, sometimes required by law.

Moailla updates on six-week cycle, but old versions are updated only for very important changes like security patches and major bugs.

Sometimes an internal system makes it hard to integrate outside contributions. You often have to manually maintain information in two places.

Which bug tracker to use? Depends on other tools such as version control. Some bug trackers work better than others with non-code issues.

Bugzilla and Trac will let you hide fields so you can remove private customer information.

Launchpad allows bugs in one project to be linked to upstream products. A bug can include a task for another project. Launchpad scans bug list periodically, checks whether upstream project fixed it, notifies developer on the current project. Launchpad was not open source but is in the process of being opened.

About half the attendees thought it important for a bug tracker to be open source when used for an open source project.

Planigle is a Rails-focused company developing an open Rally-like project.

Ikiwiki.info maintains a tracking system that can submit information to git repositories for different functions.

One project has dependencies on many other projects, so its plugins are tracked by bug trackers in all these other projects. Might be hard to submit non-bug issues such as roadmap questions to other projects.

Attendees:

Louis Suarez-Potts

Andy Oram

Cory Stousland

June Cuhler

Knut Yrvin

Clint Talbert

Pat Patterson

Matt Ray

Tom McTighe

Bill Kendrick

Don Marti

Emil Eifrem

Adam Christian

Mikeal Rogers

Stefano Maffulli

Elin Waring

Marco Steinhaeuser

Larry Rosen

Going OpenSource, 1:30, group 1

Building Your (Developer) Community

Helping Community become Self Empowered, 1:30, Room 2

Thanks so much to people that came and took part in the discussion!

This was a session spurred from a hallway discussion on Saturday. We've all used Personas to do use case design, where you create an idea of a person and you decide what that person needs/expects from the software. My question to the group was: can we use this idea to create personas for people in our community membership as a means to teach people to become better leaders in the community so that you can create a self-empowering community.

A great discussion was spurred from that, and we went down many different thoughts. So, what follows is my set of notes from the session, which are pretty all over the place. Feel free to add your own notes.

I haven't tried this idea yet, but I plan to in the Mozilla community. My blog is at cmtalbert.wordpress.com, and I'll be blogging the idea and success (or failure) from there.

The notes follow:

  • LoveBombing (great term from a Meetup guy, didn't get his name) - when someone first starts in a project, let them know that the leaders of the group care about them and that there are resources for help/question answering etc.
    • Creating a mechanism so that people can easily see who the newbies are is sometimes useful to create a more welcoming culture.
    • You have to let people know that their contribution matters
    • A way to do that is to go back to people once you have solved the bug/problem they reported and let them know that the issue is solved, ask them to check it out and re-test the feature (specific to bug reporting)
  • Visibility and responsibility
    • Use a combination of employees AND community members to give kudo's to the community members.
    • WikiAnswers has had great success with badges and encouraging people to gain badges as a motivation mechanism
    • Sometimes Responsibility means that you have the power to mess something up, and that motivates people because it demonstrates to the person that the organization trusts you not to mess anything up. So, trust is a huge factor, and having "safe methods" for people to get involved might actually be self defeating.
  • 5 factors of Motivation (from a sociology perspective)
  1. Skill Variety - not just hitting nails as they go by, doing something interesting
  2. Task identity - you (the member) are clearly responsible for this thing
  3. Significance of task - the task must make a difference
  4. Autonomy - trusted to do the task on your own
  5. Feedback - not just telling people about "you're doing a good job" but finding ways to tie that feedback into the task itself, making the feedback relevant, and building feedback loops into the community.
  • Feedback Loops
    • These open the system to some amount of gaming, how do people deal with that?
      • The narrower the focus of the community, the less gaming that will happen because people realize that by gaming the system they are essentially stealing from people they know
      • Also, create a system such that when people game the system, they are actually helping the system and the community - case in point is wiki Answers.
    • You have to ask is the feedback supporting good behavior? And if not, tweak it so that it is.

Best Quote Ever: (unfortunately we didn't get her name): When talking about how to motivate people: "If it worked in Kindergarten, it will work forever."

And afterward, Andres put up a poster and invited people to add their ideas to identify different community personas. Thanks!! Here's the link

User Group Ninjas, 2:00, Session 5

User Group Ninjas

Metrics that Matter, 3:00, Group 4

Integrated Tools for Open Source Communities

Learning about integrated tools

Notes generated at http://etherpad.com/cls-tools

Introductions

  • Neal McBurnett, ElectionAudits
  • Sara Ford, Microsoft CodePlex
  • Don Marti, Open Source World
  • Jure Čuhalev, Zemanta
  • Deborah Williams-Colling, Addison Wesley
  • David Straus, Drupal
  • Greg Weinstein, ACM
  • Emil Eifrem, MySQL
  • Monty Widenius, MySQL
  • Aaditya Bartha, Ubuntu California
  • Sonya Berry, Java.Net
  • Jack Repenning, CollabNet
  • Tiffany VonEmmel, Dreamfish
  • Kaliya Hamlin, OpenID
  • Pat Patterson, Sun Microsystems

Topic: Single Sign On

Topic: Commit approval model How to manage contributions from your community / development model:

  • gatekeep model for integrating things into their codebase
    • Drupal: two gatekeepers for each release, test them and then decide wat gets in
  • broader commiting community, continous integration happens after things get into your code

Mentioned software:

Educating Your Members, 3:00, Room D

Educating Your Members

Retrieved from "http://www.communityleadershipsummit.com/wiki/index.php/Session_Notes"