= How to be a successful contributor = = Who this document is for = This document is targeted at people interested in contributing to the Fedora Project. Students, professionals and hobbiests all come together to produce software, marketing materials, art, documentation, etc. We all started as a new volunteer. The items below are designed to help you through the process of joining a team. It helps you know what we expect of you and what you can expect of us. = Things to know before you join = Everyone who joins a free software project does so with the best intentions of staying. The sad truth is few stay to become regular contributors and fewer still become leaders within the project. The biggest difference between those that stay and those that leave is commitment and time. Some volunteers may spend 15-30 hours per week contributing, doing that and holding down a proper day job is a difficult time management skill. Even at the lower end of 2-4 hours per week, volunteers should ask themselves if they can really do that even though its less then an hour per day. 4 hours a week for most people is an entire afternoon one day. That's a significant chunk of time. == Get permission from work == There is a mutually beneficial relationship between working for a living and volunteering. Many contributors will find their skill sets at work increase dramatically just by having access to and learning from another environment. This benefits employer and worker. It is completely worth it to sit down with an employer and ask for permission to contribute during work hours, even if it's only a couple of hours on a Friday afternoon. Explain the benefits to you and your employer. If they say no, then you'll have to volunteer in your own time. = Joining = The single biggest mistake most new contributors make is showing up "just wanting to contribute." It is important to take the time to observe the team (below) and see how that aligns with your own skills and personality. Know that getting work to do on day one is very rare and those who are highly skilled in a specific technology still will have to take the time to get to know an environment before access is granted. For example, if you're a database expert it is very unlikely you'll be given access to databases (where personal info, passwords, etc) are stored within your first several weeks of volunteering. If you're looking to become an ambassador it is unlikely you'll get marketing materials shipped to you in your first week. It's an unfortunate reality and a necessary evil. The same can be said about any major changes like a complete redesign of a system or a new look and feel for a website. Don't get discouraged. Show up as often as you can and get to know the team. == Observation == It is important to get to know the organization and teams you are looking to work with before you try to join them. Learn what they do, how they do it and try to get to know the people involved. It is extremely unlikely you will be able to actually contribute from day one. Organizations can have hundreds or thousands of people working together, understanding how things work is critical. Don't be shy about asking questions and getting to know people. Plan to spend several days or even weeks attending meetings, emailing on mailing lists and hanging out on IRC before you get to do any actual work. Offer suggestions on topics being discussed and share any experiences (good or bad) you've had that is relevent to the discussion. == Pick what you want to work on == It is your job to decide what you want to work on. Make sure to pick something that is important to you and something you have passion for. It will be repeated several times in this document but don't just show up looking to work on whatever. Get to know the teams and procedures they have in place. Ask questions and really get to know what you're going to be working on _before_ trying to to work on it. === Don't jump into the deep end === When picking something to work on don't be the sole person to take on a huge task as your first contribution. It will almost certainly fail. Also don't pick several things on several teams to work on. Start small, picking at most one or two things and grow from there. The key is growing, don't join trying to become the next Leader of the project. Start small and grow. == First contact == After you've decided what you are looking to do and what team you are looking to do it with, it's time to send an introduction to the list. When sending an introduction (usually by mail list) make sure to include the following information: * Name * Time Zone / Country * Basic skills and experiences * Why you're joining * What you're looking to do (be specific) * How much time you can contribute (usually hours per week) If any of the above questions are not clearly answered, don't send the email yet. You're not ready. Remember, be specific about what type of work you're looking to do. Saying "Whatever needs to get done" isn't helping anyone. Saying "I'd like to help document system A" or "I noticed this webapp is particularly slow sometimes and I'd like to help fix that" is perfect. == Find a mentor or sponsor == This step is both incredibly difficult and important. Finding a proper sponsor will increase your chances of being a successful contrubitor significantly. Sometimes it's completely required. A sponsor will help with training, introductions and teaching new contributors how a team works. Most teams have mailing lists. Email the list, say you're looking for a sponsor and explain what you are wanting to do. If you haven't heard back in a few days, reply saying that you are still looking. KEEP DOING THIS. Most sponsors are people that have been in the project for a long time and are often very busy. They don't mean to be rude and don't want to send the impression they don't want new contributors, it's just that at the moment, some people will assume other people will take care of you and for the moment, so no one does. A common problem and a difficult one to fix. But sticking to it and continuing to ask for help without being annoying (don't send more then every couple of days) will show that you are serious and ready to contribute. = Contributing = Once you've got something to work on, it's time to actually do work. The first several tasks you will work on will likely be small or maybe mundane. Do them and do them well. As with other volunteer organizations there are high turnover rates in the free software universe. Spending days or weeks training someone only for them to vanish is extremely time consuming. Giving out small tasks that have been hanging around helps you take baby steps and learn whether or not the work you're going to be doing is really for you. == Look for work == If you have access to a repository, system or marketing in any way consider yourself part owner. This doesn't mean to go nuts and re-design everything but it does mean that you should take pride in the work you are doing. If you see something not quite right, do research on it and notify the list. Seek work out, keep yourself busy and help others. == Quitting == If volunteering isn't for you first and foremost, do not just vanish. That is the single worst thing a volunteer can do and it is also unfortunately common. Realize that lots of contributors come and go every day. Don't feel embarassed that you cannot or will not contribute further. Being busy with your day job or not having enough free time is a perfectly valid reason for not being able to contribute. Not mixing well with the organization is also possible. When you've decided it's time for you to go or take a break, let your sponsor or the list know and let them know what you were working on. Having people think you are working on something that you are not slows everything down and benefits no one.