There is room to improve
Yes, this is another FreeBSD advocacy article. And the theme is simple.
Everyone can contribute.
I’ve said it. Michael Lucas has said it. I have no doubt others have said it. But I’ll say it again. No matter what your skill level is. No matter how experienced you are with FreeBSD. You can contribute. If you haven’t, I urge you to start. It’s never to late.
I’ll give you an example of how easy it is. FreshPorts is a project I’ve been working on for a few years. I needed some help creating some text files. This was a series of copy/pastes from CVS to simple flat text files. About 40 files were needed. I asked for volunteers. Jonathan Sage stepped in and created the files for me. This was great. It allowed me to concentrate on things which Jonathan could not do (such as altering the database to allow me to compare what’s in FreshPorts against /usr/port/INDEX). But it also allowed him to contribute to the project.
This has been a simple example of delegation. It involved two people carrying out quite different tasks. Each according to their ability (with respect to the project in question).
Contribute according to your ability
You may be a programmer and not know anything about coding in C or with FreeBSD. That doesn’t stop you from writing an FAQ. No, not the whole FAQ. Just a single question and the answer. If you see the same question asked time and time again, but it’s not in the FAQ, then write it up and submit it to the documentation team. They will be glad you did. The next time the question is asked, point them at the FAQ. It shortens your answer, and lets people know it’s in the FAQ, thereby, eventually, lessening the traffic on the mailing lists.
Perhaps you don’t know how to program. But you know a few things about FreeBSD. That’s enough to start answering questions on the mailing lists. If you think you know but aren’t sure, look it up. If you still aren’t sure, say so in your answer. The great thing about mailing lists is that your answers will be reviewed by others who do know more than you. That’s good. Yeah yeah, you might give a wrong answer. But let’s put it into perspective. What’s the worst that could happen? Someone corrects you. Big deal. You learn. Don’t worry about anyone messing up their system because you gave a wrong answer. If you say “I’m not sure, but I think…” and someone acts on that answer, and messes up, well, they’ve been dumb, and you’re safe, because you said you were guessing. To be even safer, say “Wait for someone else to confirm, but I think…”.
Go ahead! I dare you to get involved.
Why do I bother mentioning this? Because it’s true. And perhaps you didn’t know about it. You can help out on the mailing lists. It’s easy. Don’t use the excuse “I might give a wrong answer”. So what if you do. Believe me, with mailing lists, if you give a wrong answer, it won’t take long for someone to correct you. If they do, take it with grace. Ignore anyone who tries to insult you or take you down. If you are correcting a wrong answer, you should be polite and explain what part of the answer is wrong, and then provide the correction. There is no need to be rude about it. Rudeness is a sign of someone who lacks self-control, awareness of others, and reflects poorly upon the community. If someone is rude, tell them, then ignore them. They have no business being on the lists if they can’t control their outbursts.
FreeBSD is a large distributed cooperative project. Not everyone on the project shares the same skills. That is good. We don’t want 50 people writing the same driver. We need people who can write code. People who can test code. People who can answer questions. People who can write documentation. People who can read documentation and point out the bits which are confusing. That is very important. The documentation must be clear. If you find something confusing, then someone else probably does too. Therefore it’s important that you point these problems out. Let someone know and it will get fixed.
You don’t need to know the answers to help
When I was working as a consultant (that’s what the university called it) one summer, my job was to sit in a windowless office and help people with computer related questions. I had a large set of manuals and access to other people who knew more. My job was not to know the answers. It was to know where to find the answers. That’s what many new people don’t know yet. They don’t know where to find the information they need. Chances are, you do know. Why don’t you help them? If you keep pointing people to various sections of the online documentation, they will eventually learn where to find the answers.
What’s in it for you?
How does this help FreeBSD? The community has a hierarchy. Those that know help those that don’t know. Your level within this hierarchy varies from topic to topic. You might be able to answer questions about installing, but know nothing about setting up a web server. Fine. Then you should answer the questions that you can answer. That will achieve two things:
- First, it will allow you to answer a question. You help others. Others get help. You learn more about helping. Everyone wins.
- Second, because you are answering the question, it allows someone else to answer another question, for which you didn’t know the answer. That gets more answers in less time. Again, everybody wins.
It’s pretty simple. Not everyone is an expert on everything. But everyone knows a bit about something. Help out where you can. Don’t be discouraged if one person tells you off. Ignore them. Of course, if you get lots and lots of people saying you’re doing something wrong, then perhaps you aren’t fitting in very well and should find another vehicle for contribution. Find your niche. Work it. Contribute.
It is that easy.