SandBox

Differences between revisions 26 and 35 (spanning 9 versions)
⇤ ← Revision 26 as of 2010-08-30 04:26:32 →
Size: 32013
Editor: 94
Comment:
← Revision 35 as of 2017-09-19 03:15:55 → ⇥
Size: 10172
Editor: itnet7
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
#title Building Buzz - Building Alliances = Community Knowledge Base =
Line 5: Line 5:
''From The Art Of Community by O'Reilly
(http://www.artofcommunityonline.org) by Jono Bacon''		 ||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>||
Line 8: Line 7:
== Building Alliances == Welcome to the community knowledge base!
Line 10: Line 9:
Good communication resources and contacts are critical for promotional ideas and concepts to flow from you to the outside world. If you are going to build some great buzz, you need to know how to communicate effectively in different channels. This requires two skills, which
must be mastered separately for each channel:		 This page is here to provide an index of documents and articles that can help you build strong, vibrant communities. It is encouraged that the community create new articles to help expand and grow our existing documentation to help create even better teams. If we all work together to expand this documentation, we can create a pretty compelling resource.
Line 13: Line 11:
 * Find the opportunity to make use of that channel. As an example, if you want to be featured in a particular magazine, you need to create an opportunity in which you can get your content there. This almost always involves building contacts. You should get to know the editors of the magazine and build a relationship that could allow you to feature some content in their channel. If you want to add a document to the Knowledge Base, see [[BuildingCommunity/AddingCommunityGuide|this page]].
Line 15: Line 13:
 * Ensure that your buzz in that channel is appropriate. The norms of communication between different mediums vary, but the differences can often be subtle and unwritten. If you act outside the expected boundaries (particularly in volunteer channels), it can impact negatively on your community. == Guides / HOWTOs ==

This section contains guides and HOWTOs for doing things effectively in the Ubuntu community, from setting up resources to resolving issues and being productive.

=== Team Processes ===

Things that all teams should be doing.

 * [[BuildingCommunity/TeamReporting|Team reporting]] - reporting to the wider project what your team is working on

=== Team Resources ===

 * [[BuildingCommunity/CreatingWikiHomepage|Creating your team wiki homepage]] - how to create a homepage for your team on the Ubuntu wiki
Line 18: Line 28:
Buzz is designed to be consumed by lots of people. You want as much focus and attention on your community as possible. The more relevant eyeballs, the better. As part of your planning stage for a buzz campaign, you should weigh the amount of effort involved with the number of relevant eyeballs. You want to ensure that your time and effort preparing materials and content is worthwhile and that a reasonable number of people see your work.  * [[BuildingCommunity/SampleTeam|Sample Team Wiki Site]] - see this collection of suggested wiki pages for a sample team and use them as the basis for your own team.
Line 20: Line 30:
Much of this boils down to readership, and readership varies tremendously. Sometimes you can ask for this information, such as with magazines, but sometimes it is more of a guess. There will be some resources that you will assume have a large audience (such as a very popular website) and some with less (such as a blog). ==== General Information ====
Line 22: Line 32:
An important consideration in this area is how the growth of the Internet has changed audience figures. It used to be general wisdom that paper publications were always the source of high audience figures. This is often no longer the case, as many websites—even a number of blogs have hundreds of thousands of regular visitors. General information and details about the LoCo project.
Line 24: Line 34:
== The Professional Press ==  * LoCoTeams - the main homepage of the LoCo project.
 * [[LoCoFAQ]] - one FAQ to rule them all! A big list of LoCo related questions.
 * LoCoTeamsList - the list of approved and new teams.
 * LoCoTeamContacts - how to contact the project leaders.
 * LoCoTeamMeeting - details of the fortnightly LoCo team meetings held on IRC.
Line 26: Line 40:
The professional press is a large and extensive channel. It encompasses magazines, websites, journals, videos, multimedia content, and more. Each of these publications has professional paid staff who have a responsibility to publish quality content. The professional press has three primary concerns at the forefront of its mind: ==== Joining a Team ====
Line 28: Line 42:
'''Quality content''' Details about joining teams.
Line 30: Line 44:
First and foremost, the professional press wants to produce leading content. It wants wellproduced content that is of interest to its audience. Great content drives an increased...  * LoCoTeamJoining - how to join your local LoCo team.
Line 32: Line 46:
'''Readership/audience''' ==== Running a Team ====
Line 34: Line 48:
Professional publications rely on readership numbers. It is these numbers that largely justify the continuation of the publication. Having high audience numbers depends on getting the previous item in place: quality content. Help and resources for running a team.
Line 36: Line 50:
'''Advertising opportunities'''  * LoCoTeamHowto - our main guide to starting a LoCo team.
 * LoCoTeamRegions - a guide to picking how much of a region your LoCo team covers
 * LoCoGettingApproved - how to get your team approved.
 * LoCoExampleApplication - an example approval application.
 * LoCoGettingCds - how to get free Ubuntu CDs.
 * LoCoResolvingProblems - details on resolving problems and conflict in your team.
 * LoCoWorkingWithOtherGroups - how to best work with other local groups such as Linux User Groups.
 * LoCoTeamLeader - thoughts on being an effective leader.
 * LoCoTeamDealingWithMoney - best practices for dealing with money
 * LoCoTeamSpeakers - a list of those who are available to speak at conferences about Ubuntu.
 * LoCoWorkingWithOtherGroups - how to further promote Ubuntu while helping your area LUGs
Line 38: Line 62:
Most publications make a significant chunk of their revenue from advertising, and advertising does have an impact on content. Although many publications would deny it, advertising deals are often agreed based upon relationships between the publication and
the company. These relationships need to be maintained to continue to bring in revenue. In many cases the content in a publication may be heavily critical of a company, product, or initiative. Although this should never matter, for many publications it does, and the producer of the content is either advised to change the content or focus on other topics.		 ==== LoCo Resources and Facilities ====
Line 41: Line 64:
You should factor these attributes into your plan for building buzz. You want to target the most appropriate publications that are relevant to your community. You will need to provide them with quality content that is of interest to their audience and consider any potential advertising conflict. You will need to build a relationship with the publication. With these publications largely staffed by paid personnel, it is entirely reasonable to formally contact them via email or phone and ask them if you can contribute some content. A great first step would be to ask if they could feature your community in their news section. In some cases you may have the chance to build some relationships that you can return to when opportunity strikes later. The first time I experienced this was years back at the start of my career. It was my first time at the Linux Expo in London. I was there running an exhibition stand for the first time for the
KDE project. While there, I went to an after-show party, and the editors from Linux Format magazine were there. I got to chatting to them, had more than a few drinks, and a little while later asked them if they would consider publishing something from me. Nick Veitch, editor at the time, responded with, “Sure, write something, but if it is rubbish we won’t publish it.” I wrote my article, it got published, and so started my journalism career.		 Guides and documentation about setting up the various resources and facilities your LoCo team may want to use.
Line 44: Line 66:
Linux Format opened many doors for me, but most importantly, it gave me a platform to talk about things that I considered interesting. It opened up a set of opportunities that have since helped with building buzz and promotion in the open source projects that I have been involved in. Though it’s been some years since my days writing for Linux Format, I got in touch with then staff writer and now editor-in-chief Paul Hudson to gather some insight from the perspective of an editor to share with you all. Paul is a firm believer of the have-a-go approach to getting content in: Both of us got into the world of free software journalism by saying, “hey, why don’t I write for
you?” and I think that same situation occurs a lot—people don’t realise how much they can contribute until they just ask. I think people imagine some sort of incredible vetting process must take place in order to write for magazines—as if only people in smoking jackets with PhDs from the school of ignorant snobbery are able to get stuck into writing, but that’s simply not true. Well, not always true, at least! Technical magazines and websites are crying out for people to get involved and just share what’s cool and what’s new in their world.		  * LoCoCreatingWebsite - how to create a website, a map of your area in which users can add themselves, a planet blog aggregator, and details about free hosting options.
 * LoCoCreatingForum - how do you set up a forum for your team?
 * LoCoDocsDay - how to get involved in our regular documentation days.
 * LoCoBot - details about using our IRC bots for logging and other facilities.
 * LoCoTeamDocsToDo - Things for us to complete
 * LoCoTemplates - templates for your LoCo sites.
Line 47: Line 73:
Paul regularly handles a slew of wannabe writers and passionate community members keen to get their projects featured in the magazine. With this in mind, he offers some useful guidance for improving the likelihood of getting coverage in magazines:
Don’t use email. We get stacks of emails, and most of them remain unread. The reason for this is that PR agencies blast us with all sorts of emails about things whether they are relevant to the magazine or not, so inevitably some important emails get lost in the mess. Instead, call first, ask to speak to the news editor or someone else on the team, and just have a chat to them. They want good contacts as much as you do, so if you’re someone who represents a project that’s on their radar, they would love to be in touch with you. They are also much more likely to read your emails if you’ve already made contact by phone. When you write release announcements, make it really clear what’s new. This is something the GNOME project, as one such example, does well (http://library.gnome.org/misc/release-notes/2.24#rnusers). They list the new features with pictures, so that someone can decide at a glance whether it’s worth looking into.
If you are a software project, provide at least one screenshot that shows off the best feature you’ve got to offer. Remember, these guys are looking for “wow” things to print, and if you can send them a shot of your software looking awesome, they are much more inclined to run it as a news story.		 ==== LoCo Activities ====
Line 51: Line 75:
Remember that even in technical magazines, some people are still journalists first and geeks second. Put your documentation online and link to all the technical information you like, but when you’re trying to get a journalist interested in what you have to say, it’s much more important to say “MyProject 2.0 uses 25% less RAM than MyProject 1.0” than to say “The switch to the xyz toolkit blah blah blah please send me straight to your Trash folder.” Sure, drop in all the technical information you want later on, but you need to win them over in the first two sentences by focusing on what really kicks ass in your software. If you’re not producing software, getting into magazines is slightly trickier, because magazines rarely want to print a story if it’s similar to something else they ran recently. So if your user group wants to get featured, you need to step outside the installfest (unless it’s big) and do something pretty darn special. Whatever you do, take a photo and make it available under a Creative Commons license that allows commercial use. The rules change with nontechnical magazines because once you enter the mainstream, you need to focus more on people. The New York Times won’t find the Gecko web rendering engine interesting, but it will find Spread Firefox interesting because grassroots marketing really is changing the browser landscape. Guides about different types of work your team can do.
Line 53: Line 77:
While Paul offers some useful advice on the best-practice methods of getting content in the hands of editors, he is keen to emphasize that many communities simply don’t get out and try, and this makes for a huge opportunity for printed nirvana: Let me try to make this a bit clearer with a specific example from Linux Format. We run a page of LUG information every month, and we have to email people to try to get content to fill those pages, despite printing an open plea every issue asking people to get in touch. So it’s not that community members are struggling to get their information in—it’s more that many of them just aren’t trying. Perhaps they think we’re not interested. Perhaps they think we won’t print it. But as they so rarely try, most of them will never know.
Maybe they’re just targeting magazines that are just a little bit out of their reach, but that’s another schoolboy error—Editor X is much more likely to print an article about your community if Editors Y and Z already have. So start small; find a magazine that fits your niche closely and get yourself covered in there. Then use that to help get coverage in other places, building it up bit by bit.		  * LoCoActivism - How-to guide for digital freedom activism
 * UbuntuAtConferences - how to get a "conference pack" from Canonical
 * LoCoRunningInstallfests - a guide to running a local Installfest event.
 * LoCoRunningReleaseParty - a guide to running a Release Party event.
 * LoCoTeamEducation - how to advocate Ubuntu / Kubuntu / Edubuntu to educational users and organisations.
 * LoCoComputerFairHowto - organising a computer fair booth
 * '''Jams!''' - Jams are get-togethers of Ubuntu activists who work on Ubuntu directly to make it better. Useful information and materials about running '''[[RunningBugJam|Bug Jams]]''' and '''[[MOTU/RunningPackagingJam|Packaging Jams]]'''.
Line 56: Line 85:
The professional press can seem a bit unnerving. Professional journalists often feel like a live-by-the-seat-of-your-pants collection of hard-working, focused, and unrelenting writers. Don’t let this worry you. Journalists are good people and they get asked for content
opportunities all the time. Just go out there and ask. When I started doing this, I would ask everyone. I would email 10 or 15 magazines to see if I could contribute content. I would not spam them: each email would be focused on that specific publication, and each would be relevant to my topic. I would recommend that you email over a list of topics that you can write about and ask if you could write something about those topics. Alternatively, write an article and submit it. The benefit of the latter is that the journo has direct access to content, which is often an attractive proposition. Just go out there and ask; there really is no harm.		 ==== Mailing Lists ====
Line 59: Line 87:
== The Amateur Press ==  * loco-contacts - the main mailing list for the project is loco-contacts. You can join it by visiting https://lists.ubuntu.com/mailman/listinfo/loco-contacts
 * Team Mailing Lists - see https://lists.ubuntu.com for details of the team mailing lists.
Line 61: Line 90:
In the last five years, the amateur press world has exploded. The Internet has provided an incredible medium in which anyone can write about anything and have the chance to grow an audience. Technology and open access to information have provided an incredible opportunity to be heard, and many have built new reputations out of these opportunities. Consequently, millions of blogs and thousands of podcasts have sprung up around the world. The amateur press is a world largely fueled by volunteers. The authors write their words not to claim a paycheck, but to share their ideas, perspectives, and opinions. Although populated by amateur scribes, this does not necessarily equate to a lack of quality. Some of the greatest work I have ever read has shown up on a blog. This could be the musings of Lessig on the
copyright wars (http://www.lessig.org/blog/ ) or the deeply amusing yet incredibly wellwritten and inspired political blather of Flyingrodent (http://flyingrodent.blogspot.com/ ). Both are inspired works, yet very different in content and presentation. The timeline of the amateur press revolution largely matched that of the professional press revolution many years earlier. The publishing world exploded onto the scene and thousands of books, newspapers, and journals sprung up. Each of these publications had its own perspective on its respective topic, and it became very difficult for readers to identify where the real quality was. The solution to this was the launch of other publications that read, reviewed, and collated this content (a great example being The Week at http://www.theweek
.com/ ).		 ==== IRC Channels ====
Line 65: Line 92:
We have started to see much of this in recent years with blogs and podcasts. Websites such as Technorati (http://technorati.com/ ) have been sifting through the blogosphere and identifying the most popular and interesting blogs. Well-respected members of given communities will also often provide their “blogroll,” which lists the blogs that they enjoy reading. These resources all provide an excellent opportunity to identify which blogs you should be focusing on. The amateur press is hugely important for buzz. The professional press is far more complicated and restricted in terms of getting heard, whereas often a few emails exchanged with the amateur press will net great results.  * #ubuntu-locoteams - the main IRC channel for the LoCo project.
Line 67: Line 94:
It’s not surprising why:
Line 69: Line 95:
 * The amateur press has a shared appreciation for volunteer community. They understand your reasons and intentions and will often want to promote them.
 * There is no advertising conflict in most of the amateur press: they can write about whatever they want.
 * There is typically no limitation on content. On a blog you can write as many posts as you like. This opens up more opportunities for you to get in on the content.		 === Events ===
Line 73: Line 97:
The most significant mediums in the amateur press arena are blogs, podcasts, and videos. Let’s take a quick look at all three and explore their cultures.  * [[BuildingCommunity/TeamIrcSessions|Running Team IRC Sessions]] - how to run discussion, training, show and tell or other team related sessions via IRC
 * [[BuildingCommunity/BookingUbuntuMeetingChannel|Booking #ubuntu-meeting]] - how to book the #ubuntu-meeting IRC channel
 * [[BuildingCommunity/RunningReleaseParty|Running a Release Party]] - how to organise and run an Ubuntu Release Party.
 * [[BuildingCommunity/RunningCommunityStands|Running community Ubuntu stands at shows/conferences]] - a guide to running an exciting, dynamic, well staffed stand at a conference
 * [[BuildingCommunity/RunningAnUbucon|Running an Ubucon]] - a guide to running a community-driven Ubucon event
 * [[BuildingCommunity/EventsGettingOrganised|Getting Organised]] - Getting started with organising your event
 * [[BuildingCommunity/OrganisingPhysicalEvents|Organising Physical Events]] - How to organise your real-life physical event
 * [[BuildingCommunity/EventsGettingSponsorship|Getting Sponsorship]] - Use the best available methods to secure sponsorship for your event
 * [[BuildingCommunity/OrganisingOnlineEvents|Organising Online Events]] - Plan and organise your on-line event
Line 75: Line 107:
== Blogs == === Supporting Workflow with Tools ===
Line 77: Line 109:
Weblogs (typically known as blogs) started out life as online diaries. In them people would share what they were doing, what they were thinking, and what interested them. When blogging started, there were few blogs, and most were devoted to deeply technical topics.
Alan Cox was one of the earliest bloggers that I am aware of. Living in Swansea in Wales, Cox developed his celebrity among early Linux fans due to his work on the Linux kernel. Cox worked on incredibly low-level deep and dirty programming. It was about as unrelentingly
hardcore as you could get. When I first started reading his diary, I was fascinated. This was not the work of Alan Cox
communicated through a journalist’s eyes. What I was reading were the direct thoughts of the man himself. Without wishing to sound like an overenthusiastic psychology major, I felt like I was actually closer to the person I was reading about. It gave a direct line to his world, and it pretty much rocked mine.		  * [[BuildingCommunity/UnderstandingWorkflow|Understanding Your Workflow]] - Learn how to select the right tools for the right job!
 * [[BuildingCommunity/BuildingGreatInfrastructure| Building Great Infrastructure]] - Points to ponder when setting up your teams' or projects' tools.
 * [[BuildingCommunity/BuildingAndMaintainingTransparency|Building And Maintaining Transparency]] Transparency leads to stronger communities.
 * [[BuildingCommunity/RegularWorkflowAssessment|Regular Workflow Assessment]] Regular assessments will refine your team or project.
Line 82: Line 114:
Since then blogging has expanded somewhat. In addition to blogs being used as personal diaries, many are now referred to as personal publishing systems. Many people, myself included, instead use blogs as a means of writing articles that are of interest to them. I use my
blog to write about community, music, technology, usability, and more. I also use it as a medium to express achievements, goals, and more.		 === Building Buzz ===
Line 85: Line 116:
It is entirely conceivable that both your existing community members and the people you want to have as friends have blogs. With this in mind, blogging should be a critical component in your buzz-building. The first task is knowing which blogs to build buzz with. Look for relevant blogs and strike up a relationship with the authors. Explain what your community is doing, and what your goals are. Try to get the author on board with your mission. You can then ask whether the author would be interested in sharing your work on his blog. If you have your own blog, you could offer to provide a link to his blog in exchange.  * [[BuildingCommunity/MindShare|Mind Share]] - Perception, change of attitudes, based on common goals and beliefs.
 * [[BuildingCommunity/BuildingBlocksOfBuzz|The Building Blocks of Buzz]] - Building excitement, and Motivate others.
 * [[BuildingCommunity/SettingUpYourBase|Setting Up Your Base]] - Specific examples on setting up your environment for buzz.
 * [[BuildingCommunity/TheBuzzCycle|The Buzz Cycle]] - How to evaluate your affectiveness with buzz.
 * [[BuildingCommunity/BuzzTargets| Buzz Targets]] - Real World Examples of Buzz Targeting done right.
 * [[BuildingCommunity/BuildingAlliances| Building Alliances]] - Harvesting your relationships, can help you spread your buzz.
 * [[BuildingCommunity/BuildingBuzzSummary| Building Buzz - Summary]] - Summary of the previous links content.
 * [[BuildingCommunity/BuildingBuzz|Start Building Your Team's Buzz]] - List of places and ideas where you can start applying what you've learned.
Line 87: Line 125:
Blog wars. Although blogging has had a hugely positive impact on how people can articulate and share opinions and perspectives, there has been a dark side. Blogging has also become a medium in which much overzealous opinion can sometimes be expressed a little too quickly.
Unfortunately, I have a rather embarrassing example of someone who fell into this trap: yours truly.		 === Measuring Community ===
Line 90: Line 127:
First, a bit of background. There used to be a company called Lindows that made a version of Linux that shared many visual and operational similarities to Windows. Microsoft frowned at the name “Lindows,” and a fight started to change the name. Lindows initially resisted, but after mounting pressure, changed their name to Linspire. Now to the issue. Let me take the liberty to explain in the words of the article itself:  * [[BuildingCommunity/MeasuringCommunity|Measuring Community]] -
 * [[BuildingCommunity/FoundationsOfFeedback|Foundations of Feedback]] -
 * [[BuildingCommunity/HooksAndData|Hooks and Data]] -
 * [[BuildingCommunity/AnonymityAndPrivacy| Anonymity & Privacy]] -
Line 92: Line 132:
Recently a chap named Andrew Betts decided to take the non-free elements out of Linspire and release the free parts as another Linspire-derived distribution called Freespire. This act of rereleasing distributions or code is certainly nothing new and is fully within the ethos of open source. In fact, many of the distributions we use today were derived from existing tools. Unfortunately, Linspire saw this as a problem and asked for the Freespire name to be changed. Reading through the notice of the change, the language and flow of the words screams marketing to me. I am certainly not insinuating that Betts has been forced into writing the page, or that the Linspire marketing drones have written it and appended his name, but it certainly doesn’t sound quite right to me. I would have expected something along the lines of “Freespire has been changed to Squiggle to avoid confusion with the Linspire product”, but this is not the case. Instead we are treated to choice marketing cuts such as “To help alleviate any confusion, I contacted Linspire and they made an extremely generous offer to us all”. Wow. What is this one-chance-in-a-lifetime-not-sold-in-stores offer? Luckily, he continues, ‘they want everyone who has been following my project to experience ‘the real’ Linspire, FOR FREE!!!”. Now, pray tell, how do we get this “real” version of the software “FOR FREE!!!”? “For a limited time, they are making available a coupon code called ‘FREESPIRE’ that will give you a free digital copy of Linspire! Please visit http://linspire.com/freespire for details”. === Disputes and Conflict ===
Line 94: Line 134:
Oh...thanks.  * [[BuildingCommunity/DealingWithConflict|Dealing With Conflict]] - how to deal with conflict in your team
 * [[BuildingCommunity/CoCAndDisputes|The role of the Code Of Conduct in Disputes]] - some notes about where the Code Of Conduct plays a part in dispute and conflict resolution
 * [[BuildingCommunity/TakingConflictToTheCommunityCouncil|Taking Conflict To The Community Council]] - a guide to what to do when taking conflict issues to the community council
 * [[BuildingCommunity/Conflict/NatureofBeast]] - The nature of conflict
 * [[BuildingCommunity/Conflict/CalmBeforeStorm]] - Signs of impending conflict, what to look out for
 * [[BuildingCommunity/Conflict/Resolution]] - How to resolve issues of conflict
Line 96: Line 141:
I gave Linspire a pretty full-throated kick in the wedding vegetables in my blog entry. I told the story, objected to what I considered hypocrisy given their own battle with similar-sounding trademarks, and vented. I wish Guitar Hero had existed back then: it would have been a better use of my time. I was wrong. My article was never going to achieve anything. Shortly after the article was published, then-CEO Kevin Carmony emailed me. He was not a happy bunny. His objection, and it was valid, was that I flew off the handle without checking in with him first. My blog entry was my first reaction. The happy conclusion to this story is that I apologized to Kevin,
admitted to being a bit of an arse, and we have remained friends. In fact, a little while later I joined the Linspire Advisory Board shortly before I joined Canonical to work on Ubuntu. It’s funny how things work out.		 === Governance ===
Line 99: Line 143:
== PRACTICE WHAT YOU PREACH ==  * [[BuildingCommunity/TheCaseForGovernance]] - When, why and how your community needs formalized governance
 * [[BuildingCommunity/LearningFromTheLeaders]] - Learn from existing successful governance structures
 * [[BuildingCommunity/SettingUpACommunityCouncil]] - How to bootstrap your community governance structure
 * [[BuildingCommunity/ExpandingGovernance]] - When and how to expand your governance structure
 * [[BuildingCommunity/UbuntuGovernanceLinks]] - Links to further reading on how Ubuntu is governed
Line 101: Line 149:
In this chapter we have discussed the important attributes in setting up a website and blog for your project and also how to build buzz using other people’s blogs. Importantly, you personally should have a blog. Use it as an opportunity to discuss your own personal interests and also to talk about your community. === Burnout ===
Line 103: Line 151:
Podcasts  * [[BuildingCommunity/Burnout]] - How to avoid and handle burnout
Line 105: Line 153:
Podcasts are audio shows that are distributed on the Internet. They typically have between one and four presenters, and they are often based around fairly specific topics. Many listeners use a special piece of software called a podcatcher to subscribe to a podcast so that when new episodes of a podcast are released, they are automatically downloaded to a media player such as an iPod. This is a fantastic way to keep listeners updated with new content. A significant reason behind the success of podcasts is that they deliver interesting specialist content to the listener to fill those dull minutes traveling to work. Many podcasts include interviews, reviews, features, debates, and other content. They vary hugely in both audio and content quality, and some podcasts have netted thousands of listeners. == Articles, Blog Entries and Multimedia ==
Line 107: Line 155:
As I mentioned earlier in this book, I cofounded a podcast with some friends called LugRadio. The show was very specifically focused on open source and digital rights. It took a lighthearted and irreverent approach to the content, and we deliberately focused on making the content social, fun, and amusing. Each show presented a range of topics for discussion, and each of us would weigh in and share our thoughts, often resulting in raucous debate and discussion. Podcasts are always looking for pointers to interesting content and announcements. You should email the presenters and explain what you are working on, and see if they would be interested in featuring your community on the show. If you manage to get a spot on a popular
podcast, it could bring a wealth of new blood to your community. Although you may feel a little funny about emailing the presenters out of the blue, go ahead! If you don’t ask, you don’t get.		 Blog entries and articles:
Line 110: Line 157:
When pitching to a podcast, the most important tip is that your tone should match that of the podcast. When we were doing LugRadio, we would often get offers for interviews and features, but often the tone would be right out of a Marketing 101 textbook. This not only demonstrated that the person making the offer had not listened to the show, but it was a red flag for boring, emotionless content that had no place on LugRadio. On the other hand, we also got offers of content that was fun, loose, and insightful, and these were snapped up instantly.  * [[http://www.jonobacon.org/?p=868|Misinformation: The Enemy Of Community]] by Jono Bacon
 * [[http://www.jonobacon.org/?p=751|Transparency in process]] by Jono Bacon
 * [[http://www.oreillynet.com/onlamp/blog/2006/04/the_increasing_importance_of_c.html|The Increasing Importance of Community]] by Jono Bacon
 * [[http://www.oreillynet.com/onlamp/blog/2005/09/hindsight_is_always_2020.html|Hindsight is Always 20/20]] by Jono Bacon
 * [[http://www.oreillynet.com/onlamp/blog/2004/04/advocating_honesty.html|Advocating honesty]] by Jono Bacon
 * [[http://headrush.typepad.com/creating_passionate_users/2006/12/how_to_build_a_.html|How To Build a Community: Part 1]] by Kathy Sierra
Line 112: Line 164:
If you get accepted for an interview or to have your community featured, listen to a number of episodes of the podcast to get a feel for the tone. Use it as a guide, but don’t be afraid to share your own personality: you have the opportunity to inspire people to join your community, so just be yourself within the context of the podcast. Finally, always ensure you have a web address to point the listeners to. This will provide an option to feed them more information, and the link can be listed in the podcast’s show notes. Ensure the website that the link points to is packed with content that’s ready when the episode of the podcast is published. Multimedia:

 * [[http://www.jonobacon.org/?p=878|How To Herd Cats And Influence People]] by Jono Bacon

-- [[LaunchpadHome:itnet7]] <<DateTime(2017-09-18T23:15:55-0400)>>
Line 115: Line 171:
NOTE

As a gesture to the makers of the podcast, it is highly recommended that you spread the word about the podcast episode that your community is featured in. You could do this on your website, in your community’s communication channels, and on blogs. This will help build a strong relationship with the podcast, leaving the door open for future content and interviews.
----

Videos

Online video has become increasingly popular as the Internet has become faster and more accessible. Although a hefty Internet connection is required to suck said videos down onto your computer for viewing, the sheer popularity of services such as YouTube (http://www.youtube.com) and blip.tv (http://blip.tv/ ) has demonstrated that many do indulge in such audiovisual delights on the Internet. While some of us may reminisce about the dark days of dial-up Internet access, it is important to remember that many parts of the world still rely on slower dial-up connections. For these folks, videos are simply not an option. As such, before you get too excited to step into the shoes of Steven Spielberg, you should consider how accessible videos are for your community. As an example, if you are reaching out to a community in a remote part of Africa, you may want to rely on another lower-bandwidth medium. In general, my recommendation is to make use of video, but not as a primary medium. Instead, use it to complement your other, more widely accessible resources.

By far the most popular video service at the time of writing is YouTube. The idea is simple: anyone can upload a video and anyone with a web browser equipped with Macromedia Flash can view it. YouTube opened the doors for anyone with a webcam or a cheap video camera to be able to create and publish online video. This has resulted in thousands of hours of freely accessible video hitting the Internet. This is only part of the value of YouTube, though. Videos on YouTube are hugely discoverable: it is possible to upload a video and have thousands of people stumble across it. This happens because each video on YouTube also displays a list of videos that are related to the one being viewed. This feature alone hugely increases the likelihood of people finding your videos. To do this you need to ensure that you name and add keywords to describe the content of your video in a way that enhances the chances of a certain demographic of user being able to find it. As an example, if you are part of a mapping community, you might want to tag your video with the words “map,” “geography,” “geo,” “location,” and any specific regions that were featured in the video. It is stunning how many people will find your videos, and this is further bolstered by word of mouth and the simplicity of embedding videos in web pages.

Another hugely useful feature of YouTube are channels. These are home pages on YouTube that contain videos from a certain provider (such as an artist, actor, or your community). There are different types of channels on YouTube designed for different types of provider that have additional facilities such as custom logos, blog entries, and tour dates. A huge benefit of a channel is that people can subscribe to it and will be notified when you add a new video. This is an excellent way to keep people hooked into your videos. YouTube channels are something we have used extensively in the Ubuntu community. As part of our ongoing efforts to educate and train developers in how to contribute to Ubuntu, we created the Ubuntu Developer Channel on YouTube at http://www.youtube.com/ ubuntudevelopers. On the site, we uploaded tuition videos, developer interviews, and more. At each Ubuntu Developer Summit, we would interview attendees to get updates about their work on the next release and perform question and answer sessions with key community members. These videos were hugely successful, and many of them gathered thousands of views within weeks of going online. The channel has over 1,800 subscribers at the time of writing.

YouTube is an excellent resource for delivering education and best practice, and I highly recommend you make use of it if you have the resources and time. Another interesting option for video is live streaming. This is where you produce a live videocast that people can view as it is being recorded at a scheduled time. Traditionally, live streaming has always been off-limits for most of us: the bandwidth requirements are so epic that it makes it too costly and impractical. Fortunately there is another option in the form of Ustream (http://www.ustream.tv). The concept is neat: the video you record on your computer with your lower-bandwidth Internet connection is streamed to the Ustream server, and then your viewers connect there with
Ustream’s oodles of bandwidth to show your video. This means that your viewers don’t hammer your own Internet connection, and it puts streaming in the hands of us all. Ustream not only provides a simple means of streaming video, but also includes other features, such as a live chat channel for the show, and recording, tagging, and syndication facilities. The live chat channel is particularly interesting: it provides an opportunity for viewers to interact with the presenter as the broadcast is happening. This means that a viewer could tune in and comment on the content, and the presenter can read the comment and repeat it in the broadcast.

This is something I first tried around the time I was wrapping this book. While experimenting with Ustream, I tested it by broadcasting live from my living room and posting the link to the videocast on Twitter and identi.ca. Within minutes I had 24 people viewing my entirely ad hoc and off-the-cuff broadcast. With my interest piqued, I decided to start performing a regular show called At Home with Jono Bacon (http://www.ustream.tv/channel/at-home-with-jono-bacon). Whether you make use of prerecorded or live video, there are some nuggets of best practice that are useful to keep your viewers engaged in your content:

 * Do your best to keep production values high. As an example, if you are recording the video with your laptop’s webcam, consider buying an external microphone. Many of the builtin mics in laptops sound awful and distort easily. Ensure that the location the camera points at looks clean, uncluttered, and professional, and wear clothes that don’t distract the viewer.
 * Before you produce your video, make some notes about what you will discuss. The easiest way of doing this is to make a series of bullet points with the topics you want to feature. If you are nervous, you may want to write a script, but I would highly recommend that you don’t: unscripted content that is well delivered is far more natural and engaging.
 * If possible, have more than one presenter. Multiple presenters always make for more interesting shows because there is an opportunity to bounce off each other with conversation, spark up debate, or play specific roles (e.g., the teacher and the learner).
 * When creating an educational program (such as a tuition video), consider embedding in the video the focal point of the tuition (e.g.,the computer screen if a programming video) or slides. There are many free tools that can capture computer screen content to video to help with this, such as Screencast-o-matic (http://www.screencast-o-matic.com/ ), Wink (http://www.debugmode.com/wink/ ), and recordMyDesktop (http://recordmydesktop.sourceforge.net/ ).
 * YouTube and Ustream allow you to put notes next to your video. This is an excellent place to list the topics you are covering in the video, provide links to websites, and credit those involved in the content and creation of the video.
 * Consider the licensing of your content before you release it. I would always recommend that you license your video under a Creative Commons license (more information on this is at http://www.creativecommons.org/ ). You should also consider the license of thirdparty content. As an example, if you want to use the latest U2 tune in your video, you might not be able to legally use it, or if you can, you may need to cough up some royalties. Be very careful here: although it is tempting to just go ahead and use the song, many online video producers have been busted for copyright infringement. I would always recommend that you play it safe and only use properly licensed content for your needs.
 * Finally, you should be aware that at the time of writing the Macromedia Flash plug-in that many video websites use (including YouTube and Ustream) is closed source. Some proponents of software freedom and open source may refuse to view those videos for this reason. If this is likely to be problematic, it is recommended you also provide access to your videos in an entirely free format, such as Ogg Theora (http://theora.org/ ).		 [[CategoryBuildingCommunity]]

Community Knowledge Base

Welcome to the community knowledge base!

This page is here to provide an index of documents and articles that can help you build strong, vibrant communities. It is encouraged that the community create new articles to help expand and grow our existing documentation to help create even better teams. If we all work together to expand this documentation, we can create a pretty compelling resource.

If you want to add a document to the Knowledge Base, see this page.

Guides / HOWTOs

This section contains guides and HOWTOs for doing things effectively in the Ubuntu community, from setting up resources to resolving issues and being productive.

Team Processes

Things that all teams should be doing.

  • Team reporting - reporting to the wider project what your team is working on

Team Resources

General Information

General information and details about the LoCo project.

Joining a Team

Details about joining teams.

Running a Team

Help and resources for running a team.

LoCo Resources and Facilities

Guides and documentation about setting up the various resources and facilities your LoCo team may want to use.

  • LoCoCreatingWebsite - how to create a website, a map of your area in which users can add themselves, a planet blog aggregator, and details about free hosting options.

  • LoCoCreatingForum - how do you set up a forum for your team?

  • LoCoDocsDay - how to get involved in our regular documentation days.

  • LoCoBot - details about using our IRC bots for logging and other facilities.

  • LoCoTeamDocsToDo - Things for us to complete

  • LoCoTemplates - templates for your LoCo sites.

LoCo Activities

Guides about different types of work your team can do.

Mailing Lists

IRC Channels

  • #ubuntu-locoteams - the main IRC channel for the LoCo project.

Events

Supporting Workflow with Tools

Building Buzz

Measuring Community

Disputes and Conflict

Governance

Burnout

Articles, Blog Entries and Multimedia

Blog entries and articles:

Multimedia:

-- itnet7 2017-09-19 03:15:55

CategoryBuildingCommunity

itnet7/SandBox (last edited 2017-09-19 03:15:55 by itnet7)