There is room to improve

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.

An example

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.

11 thoughts on “There is room to improve”

  1. William Cooper

    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?

    Regards

    William Cooper

    1. Kevin Golding

      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.

      Kevin

    2. 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.

  2. Michael Galassi

    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.

    -michael

    1. There is an article on the web site that covers this
      http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/index.html

      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.

      – bobb

    2. Michael Galassi wrote:
      >
      > 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.

      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.

    3. well
      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

      1. 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.

    4. Giorgos Keramidas

      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 😉

      – Giorgos

  3. 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!

Leave a Comment