Embed Size (px)
DESCRIPTION
My presentation for SouthEast LinuxFest 2011.
Citation preview
How Can I Contribute to Open Source?
Dru LavigneCommunity Manager, PC-BSD ProjectSELF 2011
This presentation will discuss:
Some reasons why YOU should get involved
Tips for both contributors and projects on what a new contributor can do, finding a community (and getting found), getting started with contributions, and overcoming/reducing barriers to contributions
Why get Involved? Why me?
Why not you?
There's tons of stuff to do and not enough people to do it.
Existing contributors can't sustain forever (marriage, kids, crazy day job).
It's lots of fun! Really!
Benefits: Experience
Add to your experience portfolio (and your resume).
Learn how to use industry tools in large, collaborative, non-lab environments.
Learn hard and soft skills.
Learn from others in your spare time.
Benefits: Networking
Meet people from all over the world with a shared interest.
Benefit from the experience of other community members (some who are famous and have written cool stuff).
If you're thinking about landing a job, it really is about "who you know".
Benefits: Recognition
It is possible to build a name for yourself and become an authority on topic XYZ.
One way to break the glass ceiling as you become known for what you do, not what you look like.
Savvy employers Google potential hires—will they find you?
The better the “fit” with a community, the better the benefits.
Making a good fit takes work on both sides: the community and the contributor. Definitely a 2-way street.
All of the following tips can be looked at as two sides of a coin: one side is what the contributor should be looking for and one side is what the project should be providing.
When finding a community, a little research in the beginning may save you wasted time later: create a project short list.
Look for opportunities that match your interests.
A technical fit is not always the best-fit.
Shop around and don't feel the need to stay (or give up entirely) if the fit isn't working out.
Code Contributions
As a contributor:
What languages do you know and/or are interested in learning? (try searching by language at sourceforge.net or ohloh.net)
What version control systems (e.g. git, cvs, svn) are you familiar with, if any?
Do you already know people associated with a particular project or have a project in mind?
Code Contributions
As a contributor:
Lurk on the development team's communication channels: e.g. mailing list, IRC channel, forum.
Become familiar with the project's bug tracking system.
Submit patches.
If eligible, apply for GSoC.
Code Contributions
Is there a bugs database? Any limitations on who can submit bugs?
Is there a published style guide?
Are there opportunities to be mentored by more senior members?
Are there regular bug or code sprints? developer summits at conferences? who can participate? are people or docs available to guide new attendees?
QA Contributions
As a contributor:
Download and install testing, beta, or RC versions.
Spend some time going through that software's capabilities (e.g. screens, switches).
Carefully record any errors and what you did that produced the error and report your findings.
QA Contributions
As a project:
Is there a published release schedule? Are announcements made when beta or RC versions become available?
Is there a testing mailing list or a bug tracking system for testing feedback? Does anyone respond to feedback?
Are instructions available to guide users on how to submit useful feedback?
Doc Contributions
Does the project have a documentation team?
Does it have any documentation?
How steep is the learning curve for the tools used to manage documentation?
If steep, are their guidelines on how to use the tools or opportunities to train new contributors?
Doc Contributions
If not steep (e.g. wiki), what is the account creation process, is there someone who looks at changes, is there a process for “publishing” in other formats to match software release?
How open is the project to publishing or linking to technical blogs, how-tos, interviews, articles, whitepapers, etc.?
Is there a contact person for interviews, articles?
Localization/Translations
Is the software suited to localization (e.g. has menus)? How active are the translation teams? What languages have been translated?
Tools are available (e.g. Pootle) to automate string generation and provide user-friendly editor so that localizers only have to translate text (no tool learning curve)
Localization/Translations
Is the documentation translated? How active are the translation teams? What languages have been translated? Is there a process for generating translated docs to match software releases?
Translation tools are less automated and often require more scripts, manual intervention, and defined processes.
Localization/Translations
Contributors don't necessarily need technical knowledge of the software/documentation being translated, just fluency in two languages.
Project should have a published style guide for what does and does not get translated (e.g. acronyms, technical terms that remain in English, commands and output which should remain in English).
UI Design Contributions
Does the project have a UI (user interface) design team? What about accessibility?
Are requests for UI improvements taken seriously or ignored?
Is UI part of the roadmap creation process?
Graphics Contributions
Does the website need a design revamp?
Does the project have a logo or recognized “brand”?
Is there an artwork page where users can contribute and download artwork?
Is there cover art for the project's publications?
Social Media Contributions
Does the project have official social media sites (blog/planet, Facebook page, twitter account, etc.)
Are these updated regularly with content?
Is it easy to find these sites from the project's website?
Helper Contributions
As a contributor:
Respond to unanswered questions in IRC, mailing lists, forums.
Point new users to the information they need.
As a project:
Recognize such contributions, they ease the workload for many!
Advocacy Contributions
Every project needs help in this area!
You could create brochures, arrange events and contests, administer research surveys, perform datamining, maintain a news feed or blog roll, create ads for ezines, etc.
Allows you to use your talent and imagination without necessarily requiring deep technical knowledge.
Tips: Communication Channels
Contributors need to be aware which channels are available, what each is appropriate for, and to use the correct channel for the task at hand.
Projects need to review their available channels. Are they effective for the types of contributors you need? Prune ineffective ones and consider creating new ones that may reach more users. Make sure all channels can be found from the main website and each has a useful description.
Tips: Communication Channels
New contributors should lurk for a while or skim existing archives to become comfortable with the type of conversations that occur on each channel.
Projects should be aware of the tone of each channel and have a policy for acceptable behaviour and how to quickly deal with unacceptable behaviour.
Tips: Get to Know People
People tend to stay when they feel welcome and that their contributions add value.
Some communication channels should be non-technical to allow for informal discussions (e.g. introductions sub-forum or chat IRC channel, Facebook page).
Join a local user group or create one if none exists.
Tips: Get to Know People
Attend a conference; if funds are tight look for volunteer, speaker, or sponsorship opportunities. Don't underestimate the value of meeting community members in person.
Project should hold at least an annual conference with sponsorship opportunities.
Project can assist users in creating and advertising local events (e.g. installfest, unconference).
Tips: Overcoming Problems
Learn the rules of Netiquette.
Read the Project's FAQs.
Treat others how you want to be treated.
Be persistent--don't just pop in then disappear.
Tip: Overcoming Problems
If you encounter elitism, sexism, racism, or some other nasty-ism?
Don't pretend it didn't happen.
Privately bring it to the attention of a leader in the Project.
Project should have a policy for dealing quickly with incidents.
Tips: Finding Opportunity
Publish a wish or TO DO list containing small, concrete tasks suited to new contributors.
Look to reduce getting started barriers: e.g. account creation process, submission queues.
Look for ignored contributions and find out why: e.g. lack of manpower, lack of communication.
Tips: Reducing Barriers
Publish a “how you can help” list prominently on the Project website.
“Groom” people on IRC and forums: help them write a good bug report, encourage them to publish a how-to, blog their experience, tweet what is happening.
Have an outreach program to introduce the project in local schools.
Tips: Reducing Barriers
Use recognized tools and include “getting started” guides to reduce learning curve.
Hold regular code/doc/idea-athons.
Organize face-to-face events: local user groups, unconferences, participation in global events such as Software Freedom Day.
Tips: Reducing Barriers
Acknowledge contributions! e.g. don't let patches rot in a queue.
Pair new contributors with community members.
Think beyond the codebase!
Remember: open source is about community...
