Chapter 11 introduced you to the various sources of help within the PC-BSD community. New users often start out slowly by reading the various forums and occasionally posting a new topic when they have a question they can't find an answer to. Over time, as you become more familiar with the community and how to do things on your PC-BSD system, it is natural to find yourself getting more involved.
This chapter will introduce a variety of ways that anyone can use to give back to the PC-BSD community. While reading through this chapter, keep in mind the netiquette you learned in Chapter 11.
It is a common misconception to think that you don't have anything to contribute, especially if you are still learning how to use PC-BSD yourself. You don't have to be a "guru" or know how to write source code to get involved and to help others within the PC-BSD community. Your life experience, what you know about PC-BSD so far, and your unique combination of skills and talents are useful to others. A community is made out of people, and every person has something to contribute. The more people that get involved, the more vibrant the community, and the more the software evolves to meet the needs of the people within that community.
This chapter suggests some of the more common ways to contribute back to the PC-BSD community. We suggest ways that are suited to both the novice and more experienced users. We haven't thought of everything, so if you have a good idea not listed here, be sure to bring it up on a FreeBSD forum, mailing list, or IRC channel. Better yet, just do it!
Even if you don't consider yourself to be a technical user, you still have thoughts about what would be useful on your PC-BSD system. Maybe a specific application isn't available as a PBI, or you find that a specific feature is missing or could be improved upon.
When submitting an application or a feature request, keep in mind that implementing your request will require work on the part of another person. This should not deter you, but it should remind you to help make the other person's work as easy as possible. In other words, research your request first and give other users all the information they need to understand your request and possibly implement it.
Chapter 11 introduced you to the PC-BSD forums and how to post to a forum. Two of the forums are useful here: Feature Requests and Package Wishlist (discussed in the following sections).
Before creating a new topic on the Package Wishlist forum, go through the following checklist for the software you want to see made available to PC-BSD users:
Searchpbidir.com:Does a PBI already exist? If so, do you need a newer software version?
SearchFreshPorts.org:Does a FreeBSD package/port already exist? If so, you want to ask if anyone can convert it to a PBI.
Searchforums.pcbsd.org:Has anyone else made a request yet? If so, you should respond to that post after reading any of the previous responses.
If a topic doesn't already exist, make sure that your new topic includes the name of the software in the subject line so other users can find it easily. Your new forum message should include the following information:
- Indicate if a PBI already exists:
If so, include the reasons why you need a newer version. For example, does the new version introduce new functionality that you need, or does the old version have a serious security vulnerability?
- If there is no PBI, indicate if a port/package already exists:
It is easier for someone else to make the PBI from an existing port/package. Your message should also include the URL to the website for the application, a brief description of what the software does, and any reasons why you think a PBI would be useful to you and other PC-BSD users.
If your feature request deals with the operating system, rather than a missing software application, you should create a new topic on the Feature Requests forum instead. Don't forget to searchforums.pcbsd.org first to see whether someone else has already started a topic. If a topic already exists, reply to that topic. If there isn't a similar topic, create a new topic with a descriptive subject line so other users can find your request.
Some things to keep in mind if you make a feature request:
- Don't take it personally if no one responds:
It might just mean that no one else finds that feature useful at this time. Feature implementers might also be busy working on a new release of PC-BSD and don't have time to look at feature requests right now. If the feature is important to you, consider discussing it on the #pcbsd IRC channel.
- It is okay if others disagree:
What is a feature to one person might seem like a waste of time and resources to another. Keep the rules of netiquette in mind if someone disagrees with your request. And don't assume that this means that your feature won't be implemented. Sometimes having multiple points of view helps in the design of a feature that meets the needs of a wider group of users.
- Don't assume a feature is too "small" to ask for:
Useful features that are trivial to implement are often implemented quickly. The developer gets to feel a sense of accomplishment and other users end up benefitting from your original request.
- Don't assume a feature is too "big" to ask for:
Some features take a lot of design work and development time to implement correctly. However, they also offer great satisfaction to the developer who tackles the implementation. These types of requests often get a response of "great idea" with some sort of timeline of when it is realistic to expect the feature to be ready for testing. You can also help to test the feature and how to do so is discussed later in this chapter.
- Not all features get implemented:
Sometimes there are legal or technical restrictions that prevent the feature from being added. Sometimes the feature is a great idea, but no one has the time to develop the implementation at this time.
- Some features do get implemented:
What would be useful to you is often also useful to other PC-BSD users. Often developers think "that's a great idea, why didn't I think of that before?" and are happy to implement the new functionality. And you never know if you never ask.
A software bug[77] occurs when an application acts in an unexpected or incorrect way. Examples include receiving an error message when you launch an application or having an application hang when you access one of its menu items.
Before submitting a bug report, use Google to research the problem first. Bugs are fixed by developers and they need a way to keep track of which bugs have already been reported, which are being worked on, and which have been fixed. Sometimes in order to fix some PC-BSD bugs, something needs to be fixed in the underlying FreeBSD operating system or in the KDE desktop. This means that information about your bug is probably located outside of the PC-BSD forums, and possibly even outside of the PC-BSD community.
In order for developers to fix a bug, they have to be able to re-create it so they can figure out what causes the bug and what exactly needs to be fixed. Occasionally a bug is not a bug at all, but a user error. Don't be embarrassed if this turns out to be the case—in reality, you have still uncovered a documentation or design bug. Obviously, if the interface is not intuitive enough to prevent errors, the design needs to be improved, or some form of documentation needs to be added to the FAQ or knowledge base. If you've managed to come across the error, chances are many other users have as well, and perhaps they did not have the time or know-how to report the error.
There are several ways to report a bug. Which method you choose will depend upon your technical level and the communication methods you are comfortable with. Regardless of the method you use, make sure your message about the bug includes information on how to re-create the bug. If your research shows that other users or developers have discussed the bug and its possible fixes, include those links in your message.
The PC-BSD forums contain three forums that deal with bugs: General Bug Reports, Startup/Installation Bug Reports, and Usage Bug Reports. It is a good idea to skim through these forums first to get a good idea of how others write bug reports and to see which topics belong in which bug forum. You'll note that each forum includes a topic reminding you to search the knowledge base first before posting. Other points to keep in mind:
- Explain how to re-create the problem:
This should be at the beginning of your post because the first thing a developer will do is try to re-create the problem to figure out what is causing it.
- If possible, determine if the problem is with PC-BSD, FreeBSD, or KDE:
Sometimes you can tell from your research; for example, if the bug is being discussed on a KDE mailing list, the problem is with KDE, not PC-BSD. Sometimes it might be difficult to figure out the underlying source of the bug. When in doubt, post on the PC-BSD forum first and be prepared to repost to a FreeBSD or KDE forum if a developer indicates that the bug report belongs there.
Tip
The forum topic "If you see bugs that are KDE or FreeBSD-specific"[78] contains links for posting FreeBSD or KDE bug reports.
If the bug is specific to a PBI, you can post your bug report on the PBI-bugs mailing list. Instructions for this list are at http://lists.pcbsd.org/mailman/listinfo/pbi-bugs.
Another mailing list, designed for developers who fix bugs, is Trac-bugs at http://lists.pcbsd.org/mailman/listinfo/trac-bugs. This is an automated mailing list that sends out an e-mail whenever a bug is reported using the trac[79] bug reporting system. Trac is discussed in more detail in the next section.
Trac is software that allows software projects to track their software bugs. Users can submit bug reports that are automatically given a ticket number and added to the database of known bugs. Developers can report on their progress as they work on fixing the bug. Once the bug is fixed, the ticket is closed. Anyone can search the database to see which bugs have been reported and which have been fixed.
The PC-BSD trac database is located at http://trac.pcbsd.org. Anyone can use the search feature in the upper-right corner to search for a bug or click View Tickets to browse all tickets. You will need to register for an account if you want to report a bug. Figure 12-1 shows the PC-BSD trac website with the dlavigne user logged in.
To submit a feature request or bug report, click the feature requests or report bugs hyperlinks. You can also click New Ticket in the upper-right corner. Any of these options will open the Create New Ticket window, seen in Figure 12-2.
The ticket contains the following:
- Summary:
This is a descriptive subject to assist other users in finding the bug report.
- Description:
Include how to re-create the problem/feature here, as well as any other details needed to assist the developer in fixing the problem.
- Type:
Indicate whether the ticket is a bug report (defect) or feature request (enhancement).
- Milestone:
Select the version of PC-BSD you are using. Developers who are creating new features might pick a version that has not been released yet.
- Version:
Select the version of PC-BSD you are using.
- Cc:
Leave this as-is so a copy of the report is sent to the trac-bugs mailing list.
- Assign to:
Leave this empty because it will be filled in when a developer is assigned to fix the bug.
- Priority:
Indicate whether the bug/feature is of major or minor importance. Typically only developers tag a bug as critical.
- Component:
Read through the list of components and pick the one that most closely matches the part of the operating system that is affected by the bug/feature.
- Keywords:
These will be picked up by the search engine so include two or three words that you would find useful to search for and find your ticket.
- Attached Files:
If possible, include a screenshot or copy/paste of any error messages in a separate file. The description should be a short descriptive paragraph describing the bug/feature—all the necessary details should be in the attached file.
Before submitting the ticket, use the Preview button. Pretend you are someone else reading the ticket—does it contain all the information you would need to understand the problem? When finished your review, click Create Ticket to submit it to the database. It will now show under View Tickets.
The main page of the PC-BSD trac site also contains hyperlinks to the following:
- Roadmap:
You can view the tickets and their progress for the upcoming release of the operating system.
- Source code:
Source code for the operating system. Source code is discussed in more detail in Chapter 14.
The main page also contains links to submitting bug reports for HAL,[80] FreeBSD's version of KDE, KDE, and useful information for developers who want to assist the PC-BSD project.
By the time an operating system is "released" (i.e., a new version becomes available), many developers and users have already tested all the new features to ensure they work as expected. This testing phase is called a beta[81] period. When the software is just created and hasn't been well tested, it is called an alpha period. Obviously, the more people who can test new features as they are created and who can retest bugs after they are fixed, the better the final release. You don't have to be a developer to participate in an alpha or beta period. You just have to be willing to spend some time trying out new features and writing up good reports that explain any errors you come across so they can be fixed by developers.
Tip
If you are a developer, you can submit fixes using the PC-BSD trac system.
Information useful to PC-BSD beta testers is available in the testing mailing list at http://lists.pcbsd.org/mailman/listinfo/testing. Begin by looking at the most recent archives—this will tell you what version is currently being tested and where to download the International Organization for Standardization (ISO) image to the alpha or beta version.
Tip
Beta ISOs tend to be large (at least 2GB), so it is best to have a fairly fast and reliable Internet connection.
Once you have the beta version, install it on a test system or virtual environment and then start to play with it. One approach is to try doing your regular tasks and see if you come across any problems. Another approach is to systematically start going through all the menus to see whether anything is missing or produces an error. As you find errors, post a message to the testing mailing list. Remember to research the error first (to see whether anyone else has already reported it), use a descriptive subject line, explain what you did that caused the error, and describe the error and/or cut and paste the error message.
If you prefer to test PBIs instead of the operating system, there is a "PBIs ready for test" forum at forums.pcbsd.org. You might want to subscribe to this forum to be notified whenever a new PBI is ready to be tested.
Tip
PBIs do not get added to pbidir.com until after they have been tested by users. This helps to ensure that new users won't experience any problems when they install a PBI.
When a PBI developer finishes creating or updating a PBI, a new message is posted to this forum. The message will indicate where you can download a copy of the PBI to test. You can speed up the process of a PBI going from testing to final availability by volunteering to test the PBI. Install the PBI, try accessing all its menus, and perform some of its functions. If you come across any problems, reply to the original post. If the PBI works flawlessly for you, still reply to the post and indicate so in your message.
If you speak and write a language other than English, consider joining the PC-BSD translation team. This team's efforts help to open up PC-BSD to a whole new group of users who otherwise would not be able to access the operating system because they understand a language other than English. The gateway containing links useful to PC-BSD translators is located at http://translations.pcbsd.org. Members of the translation team work on the following:
- Localization:
The process of translating an operating system's menus and messages into another language.
- Document translation:
Translation of existing documents, such as the PC-BSD User Guide, from English to another language.
These tasks are discussed in the following sections.
The PC-BSD translation community uses the Pootle[82] application to manage translations. Pootle is short for PO-based Online Translation/Localization Engine because it uses translation PO files that end in the .po extension. The syntax for .po files can take some time to learn—fortunately, Pootle provides an easy-to-use, browser-based editor that allows you to concentrate on translating rather than spending time learning file syntax.
The PC-BSD Pootle installation, seen in Figure 12-3, is located at http://Pootle2.pcbsd.org.
Each language that is being translated has its own hyperlink in the Languages section.
Tip
If the language you want to translate is not listed, send an e-mail to the PC-BSD translations mailing list requesting that the language be added.
If you click a language, you will see the statistics for that language. Figure 12-4 shows the resulting screenshot for clicking the French language and then the pcbsd folder.
The statistics contain the following for each translated menu:
- Name:
The name of the PC-BSD specific menu to be translated
Tip
Menus that come with KDE are translated by the KDE translation team. See the KDE Translation HOWTO[83] for more information about joining this team.
- Progress:
Shows a bar graph representing the percentage of words that have been translated within a menu
- Summary:
Indicates which menus are complete and how many words need attention in incomplete menus
- Total Words:
Shows the number of translatable words within a menu
In order to translate a menu, you need to first register an account and then log in using the links at the top of the page. The first time you log in, you will be prompted to change options where you can set up your user interface language, the number of rows you want to see in translate and view modes, and the languages you want to translate. The language(s) you select will be added to your home page so you can quickly access your translation project(s).
Once you are logged in, you can begin to translate files. Figure 12-5 shows the interface seen by clicking the CrashHandler.po file in the French
Each possible block of words to be translated appears in Pootle's translation editor. If you click the number next to a block of text, an Edit link will appear. In this example, the number 5 has been clicked to open the editor for this block of menu text. The translator can now type in the translation and then press Submit to save the translated text.
Note
The fuzzy checkbox indicates that another translator should still verify the accuracy of the translation. It is a good idea to keep this box checked when adding a translation.
While Pootle is used for localization of PC-BSD menus, translating existing documentation is discussed on the Translations forums at forums.pcbsd.org. Check this forum first to see which documents are currently being translated. If you want to start work on a document that isn't currently being translated, start a new topic on this forum.
If English is your native language, you can also contribute new documentation. Here are some suggestions to get you started:
- Add a new topic to the Tips & Tricks forum:
Have you done something cool with your PC-BSD system that isn't listed in this forum? Or have you found a neat trick that other users might find useful? Start a new topic describing your tip or trick.
- Add a new topic to the Guides forum:
Have you discovered how to perform a task that isn't part of the PC-BSD Users Handbook? Clear instructions on how to perform the task would make a great new topic for this forum.
- Join the docs mailing list:
Have some good ideas about documentation? The people on this mailing list are also interested in documentation.
- Start a blog about PC-BSD:
Looking for a good blog idea? Consider blogging about your experience with PC-BSD and the things you learn along the way.
- Already write for a column or magazine?
If so, see if they are interested in publishing an article about PC-BSD or describing how to do something in PC-BSD.
Tip
There is a magazine specific to BSD[84] which is always looking for writers.
PC-BSD provides several venues for contributing different types of media that other users might find cool or useful. You can do the following:
- Submit pictures to the PC-BSD Community Pictures forum:
Have pictures from a PC-BSD conference booth or of users using PC-BSD? Start a new topic and tell others where they can find the pictures.
- Submit screenshots to the PC-BSD Screenshots forum:
Let others see screenshots of your custom desktop or of PC-BSD running a cool application.
- Upload videos:
The PC-BSD users Ning group[85] has an area where you can upload videos of PC-BSD presentations, interviews, and how-tos. You have to sign up to join the community first.
If you have other art or design ideas, bring them up in a suitable forum. For example, you could offer to create PC-BSD brochures to hand out at conferences, create designs for stickers, or discuss T-shirt design ideas. The possibilities are endless! If it's cool to you, chances are it will be cool to other PC-BSD users as well.
Until you've had an opportunity to attend a BSD or free software conference[86] (like a LinuxFest), you have no idea how valuable and personally satisfying it is to meet other users who are also interested in the PC-BSD operating system. Often you will have the chance to meet people that you have chatted with on IRC or whose forum posts you have read. You might also get to meet some of the people who develop PC-BSD, write its documentation, or work on a translation team. But don't just take our word for it—if you have a chance to attend a conference in your area or in a city you are able to travel to, attend the conference and see for yourself.
If this is your first conference, don't worry if the scheduled talks sound too advanced. You will still get something interesting out of each talk, even if you don't understand everything the speaker is talking about. The real value of a conference is the "in between talks" time. This is where you get to chit chat with other attendees, find out what they are doing, and meet new friends. Here are some tips to keep in mind when attending a conference:
- Bring your business cards and keep a pen handy:
If you don't have any and can't afford to buy some, create your own cards containing your name and e-mail address using Open Office[87] and print them onto business card paper that is available from most office supply stores. Swapping business cards is a great way to have the contact details for the new people you will meet. When someone hands you a card, take a moment to write a note on the back so you remember who they are when you get back home.
- Don't be shy:
If it's your first conference, you probably don't know anyone—yet. That will change quickly once you start talking to people. If you have to, muster up the courage to introduce yourself to a few people. BSD users tend to be a friendly bunch, so it shouldn't take too many introductions to get the ball rolling. If you have a cool T-shirt or hardware device, bring it with you; people will come over and introduce themselves to you!
- Don't dismiss the conference if you don't have the money to pay:
While many conferences are free or have a minimal registration fee, others might be out of your price range or you might not have the money to travel to the conference location. See the next two sections if either applies to you.
Being a speaker at a conference is a great way to attend a conference. You get to tell other people about the interesting things you are doing, and other attendees can benefit from your experience. Having a PC-BSD talk at a non-BSD conference is also a good way to spread the word about PC-BSD and to give users of other operating systems an opportunity to learn more about PC-BSD.
Every conference has a Call for Papers (CFP) where anyone is invited to submit an idea for a talk. Check the conference website a few months before the conference date to find out the guidelines and submission due date for the CFP. Read the guidelines and ask yourself if any of the suggested topics apply to what you are doing with PC-BSD. Depending upon the focus of the conference, many CFPs are looking for nondeveloper talks where those with other skills can discuss what they are doing and how others can get involved. Examples of possible talk ideas include the following:
- Translations:
What is it like to be a member of a translation team? How do you get started in translating documentation? How is Pootle used to assist a translation team?
- Using PC-BSD:
As an end user in a corporate environment, at a school or volunteer organization, useful tips and tricks, migrating from other operating systems, things that are different from Windows or Linux or Mac, and so on.
- Running XYZ application on PC-BSD:
Describe how you install and use an application such as a database, gaming system, server software, or Windows application on PC-BSD.
- PC-BSD for FreeBSD, Windows, Linux, or Mac users:
If you have experience with another operating system, explain how PC-BSD differs and any tricks you had to learn when you started using PC-BSD.
When submitting a talk proposal, double-check that your submission follows the submission guidelines. Most conferences will pay a speaker's registration fee but you should check to see if the conference also assists in travel costs or if speakers are responsible for their own travel.
If your talk gets accepted, spend some time creating and practicing your slides. Ask yourself: "If I were listening to this talk, what would I like to learn?" Find out how long the talk is expected to last; most talks last 40 minutes with 10 minutes afterward for questions. Practice your timing—if you have too many slides, you will be rushing at the end or won't have enough time left over for questions. If you don't have enough content or rush through your talk, you will be done in 15 minutes and will be left wondering what to do with the rest of the time. If possible, practice in front of friends or family members and have them tell you if you are talking too fast, mumbling, or are making distracting gestures or sounds.
Attendees will be interested in what you have to say and will want to know where to get a copy of your slides. If possible, upload your slides to your website, blog, or a slide sharing website such as SlideShare[88] before the conference. Include your contact e-mail address and the URL to your slides in the last slide and leave that slide up as you answer questions at the end of your talk.
If you are too shy to be a conference speaker, have trouble introducing yourself to people at conferences, or don't have the money to pay for the conference registration fee, an excellent idea is to volunteer to help out at the conference. Every conference needs volunteers to perform such activities as setting up the wireless network, helping at the registration desk, stuffing conference bags, acting as lunch monitor, and providing attendees with directions. Being a volunteer is a low-key, no-pressure way to meet other people because they will be coming to you for help.
Volunteering to organize and help out at a PC-BSD booth is another way to meet people while spreading the word about PC-BSD. This is especially useful at non-BSD conferences such as LinuxFests. Most Linux users have already heard of or have used BSD and are usually interested in talking about or trying out PC-BSD. If you are organizing a PC-BSD booth, contact @bsdevents on Twitter if you need help getting swag or other volunteers for the booth. @bsdevents will also help spread the word about your booth.
This chapter offered many practical ideas for becoming more involved within the PC-BSD community. I hope that you will try out the ideas that interest you and that you have fun doing so.
The next section of this book deals with ways advanced users can get the most out of their PC-BSD system.
[77] See http://en.wikipedia.org/wiki/Software bug for a more detailed description.
[78] http://forums.pcbsd.org/viewtopic.php?f=7&t=3043&start=0
[79] http://trac.edgewall.org/
[80] http://en.wikipedia.org/wiki/HAL_%28software%29
[81] http://en.wikipedia.org/wiki/Software_beta
[82] http://en.wikipedia.org/wiki/Pootle
[83] http://l10n.kde.org/docs/translation-howto/
[84] See www.bsdmag.org for more information about BSD Magazine.
[85] http://pcbsdusers.ning.com
[86] @bsdevents on Twitter posts the times and locations of upcoming conferences that will have BSD talks or booths.
[87] www.linuxjournal.com/node/1000428 has a nice how-to for creating business cards.
[88] http://www.slideshare.net/