User:Anna.sobiepanek/FSOSS 09
Introduction
October 24, 2009 - October 30, 2009 was Toronto Open Source Week, a celebration of Open Source Technology. As part of the celebration, Seneca College hosted the annual Free Software and Open Source Symposium. FSOSS allows members of the Open Source community to come together and share their ideas. More importantly, it allows newcomers to get involved.
Check out the workshops.
Check out the list of presentations.
Fame, Fortune, and Technical Writing by: Dru Lavigne
Dru Lavigne is the Editor-in-Chief of the Open Source Business Resource. She has also written a number of books for O'Reilly. Read more about her
Dru Lavigne talked about making technical writing a career. She pointed out that this is a great time to become a technical writer, as there is 0 barriers to entry. Nowadays you can publish yourself on the web easily, and most often for free. After all, there is always room for more documentation. Dru stated that if you are good, you will get noticed, and you will get paid. But in order to get notices, you have to write and do so daily. When people search for you using a search engine, they should be able to find good examples of your work as well as your followers. Also, you should get involved and collaborate with the community. This includes editors, proof readers, and editors.
Dru Lavigne broke down her talk into Recognition, Inspiration, Publishing, and Earning Money. Here is what she had to say:
Recognition In order to get recognized you have to get your work and name out there through; blogs, book reviews, articles, and How To's. Don't wait until your work is perfect before publishing it on the web, if you do the topic might not be interesting or popular anymore. If you want to be a perfectionist, focus your efforts on making sure your grammar and spelling is flawless, even in your personal blog's. Most importantly, do your research. The information you post must be credible.
Inspiration Write about whatever interests you. There are many things that Open Source projects need like; documentation team members and leaders, man pages, tutorial, and guides for newcomers. You can also write articles and news in mainstream publications, write papers, brochures, and critique artwork or web content. Sometimes you have to change-it-up to get creativity flowing.
Publishing So you want to get published? Publishers want to see that you have a big following, an audience. They also want to know that your expertise is currently 'hot' or popular. Most importantly, they want a well thought out proposal. Write your proposal as if you were gonna start writing your book tomorrow.
Some interesting stuff:
- for technical books 10,000 copies sold makes it a "best seller"
- taking 3 months(50 hrs/week) to write a book is considered fast
- a very small # of books get promoted by mainstream publishers and small publishers have less resources for promotion
Earn Money You have to know what your goal is. Is your writing a hobby, a career, or a means to an end. You should re-evaluate your volunteer to paid ratio every 6-12 months. If you want yo make money, you should probably cut down on the volunteer work. If you are entering the field expect to pay you'r dues. This means that you will need to start by writing free reviews.
Dru Lavigne also talked about helping your fellow writers. You can do this by introducing them to editors and publishers. You can invite them to co-write an article or book with you, and even invite them to speak at conferences. I found this talk very interesting, I always tried to minimize my web presence with the mentality that employers don't like seeing drunken facebook photos. I never thought about the amount of free advertising you can get by publishing stuff on the web. It's like volunteering from home.
Ranking the Bugs: Predicting Which Bugs Will Get Fixed by: Diederik van Liere
Diederik is a Post-doc Researcher at the Rotman School of Management (U of T). Diederik has a PhD from RSM Erasmus University which is in the Netherlands.
Diederik's talk was about reporting Bugs at Bugsilla and the process that follows. Obviously, the first step is reporting a Bug. But what happens after the bug gets reported? Here is the process:
- Every bug that is reported has to be verified. The average time to verify a bug is 3.6 days.
- People leave messages outlining the possible solution for the bug
- The bug gets fixed. Average time to fix a bug is 6.7 days. Mozilla employee's bugs are fixed faster than those of community members.
When you file a bug you need to make sure that your bug report contains all of the important information. The quality of bug reports ranges from 0 to 4, 4 being excellent. This number can be calculated by the sum of the presence of the following items; steps to take to reproduce the bug, a stack trace, a screen shot, and version information. So if your bug report only has the steps to take to reproduce the bug and version information it would get a rating of 2. Higher rating of your bug report, leads to shorter verification time.
The time it will take to fix the bug is dependent on the developers; productivity, efficiency, and skill set. Your bug report can be flawless but if the developer doesn't have the skills necessary to fix the problem, he will need to spend some time researching.
Diederik stated that he considers anyone that posted at least one bug to Bugzilla a community member.