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.
i think that was pretty great to be honest, alot of us fbsd starters dont like to add comments onto big scary mailing lists cause we have people on there who know their stuff and like to point out our mistakes, but hey, at least we’re trying to help?
Everyone starts somewhere though. I know that people like Matt Dillon could tell someone a thousand times more about the workings of the FreeBSD filesystem, but when someone asks how they should partition their drive I can certainly offer an opinion. Between the drives I’ve done myself and the many times I’ve seen such a topic raised on one of the lists I feel confident enough to answer fairly accruately.
The thing is to find things you know and watch out for those questions. Whatever you’re playing with right now will be frsh in your head so when someone asks you may be able to answer quickly and with enough information to help.
The thing with FreeBSD is that there are a lot of very talented people involved in the project. Someone will always be able to do things better than you, but that shouldn’t stop you from helping. If you answer the simple questions it means the big guns have more time to answer the questions we can’t, or write the new bit of code that everyone’s been waiting for.
for my part, I wish there were FAQs like how to migrate from linux or some other OSes, ie, the differences between them: with linux you upgrade the kernel and the distribution stuff separately on someone else’s timetable, while with *BSD, you do the _whole system_ on yours. But how to grok all that and make it work? I still feel like I’m fumbling around when I read the handbook: it talks over my head, or so it feels.
The best way to do this, I guess, would be to build a system from scratch (as in the diary’s approach) but with the added information about translating your expertise to a new world.
I suspect there are many of us out there who have the knowledge and the desire to help but have had no success submitting code, documents, HOWTOs, etc. For example, the one answer to the FAQ that you mention in your article, what do I do with it once written? Let us say that I have a mini-HOWTO written on setting up jails under FreeBSD-STABLE, then what? How about if I’ve written a set of scripts to make mounting ISO images on vn devices more intuitive? I’ve a friend at work who has made several bug fixes to the Gimp and submitted them, they got ignored more than once. He now just patches his local copy and calls it good enough. Can’t say I blame him.
There is an article on the web site that covers this
For your HowTo’s above you would send a pr (problem report)
under the "doc" Category either from the web site http://www.freebsd.org/send-pr.html
or through the command send-pr(1).
Although before that it might be an idea to have a read through
the fdp-primer (FreeBSD Doc Project Primer) http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/.
It may also be an idea to subscribe to the doc mailing list, and perhaps post your article (or a link to it) to -doc or a more
relavant list to get some feedback on it before submitting the PR.
Hope this helps.
Michael Galassi wrote:
> a friend at work who has made several bug fixes to the Gimp
> and submitted them, they got ignored more than once. He now
> just patches his local copy and calls it good enough. Can’t
> say I blame him.
Submitted them where? Let’s assume the freebsd-ports mailing list. If a PR was filed, he should be able to look it up and find out what happened. If the PR is open, you start posting message to the -ports mailing list and CC the maintainer.
It’s rather difficult to comment on your friend’s situation without knowing the big picture.
dont wanna be a wuss but i’ve submited some few bugs/ideas for some few ports and ALWAYS get ignored!
i’ve only written to the maintainer though
If you get no reply from the maintainer, submit a PR with your patches. And keep on freebsd-ports, mentioning that the maintainer has not replied and get someone to commit the PR.
Michael Galassi wrote:
> For example, the one answer to the FAQ that you
> mention in your article, what do I do with it once
> written? Let us say that I have a mini-HOWTO written
> on setting up jails under FreeBSD-STABLE, then what?
Then, if you feel that this should be included in the
documentation set of FreeBSD you submit it to the FDP
(FreeBSD Documentation Project). This is documented in
various places at http://www.FreeBSD.org, like the article on
contributing already mentioned. If all that the article
describes, about bug reports, and using send-pr seems too
much for you, you can even send your documents in plain
ASCII text to freebsd-doc@FreeBSD.org and some doc-hacker
will do what is required to have them added in the collection
of SGML docs.
> How about if I’ve written a set of scripts to make
> mounting ISO images on vn devices more intuitive?
> I’ve a friend at work who has made several bug fixes
> to the Gimp and submitted them, they got ignored more
> than once. He now just patches his local copy and
> calls it good enough. Can’t say I blame him.
Is the bug FreeBSD specific, or is it something that the
Gimp needs changed on all platforms that it runs on? If
the bug shows up only on FreeBSD, then I’m sure the
maintainer of the Gimp port in FreeBSD will gladly merge
the patch to the port if you let him know. Note however,
that if this is a bug that needs to be patched in Gimp’s
source (because it’s not a FreeBSD bug, but some problem
that Gimp has in all the platforms it runs on), you will
kindly be asked to send the changes to the maintainers
of Gimp too. This way, FreeBSD’s version of Gimp will
be as close as possible to the officially released version
of the program, which is a nice thing 😉
I’ve set up a website with some articles about FreeBSD. There’s lots to follow. Just check out http://www.socruel.nu
This is my contribute.
I found this article to be very inspiring!
I appreciate having the use of FreeBSD, and I now feel that I could do something to give back to the community that created it.
Keep up the terrific site!