As always, BSDCan is a jam-packed week full of opportunities to network and work with other FreeBSD committers and users in person.
© Ollivier Robert
For some of us, the week began on Monday when most of the FreeBSD Foundation board of directors met for two days to discuss how the Foundation serves the FreeBSD Project and where we can improve our efforts in advocating FreeBSD, sponsor projects that move the Project forward, and reach out to companies about their use of FreeBSD. The Foundation also met with most members of the FreeBSD core team to listen to their perspective on how the Foundation is supporting the Project and ways to improve the sponsored projects process so that FreeBSD continues to move forward and innovate.
Next, came two days for the Developer Summit. This began with a session on brain storming the features likely to appear in 11.0. It then broke into working groups which focus on a particular topic such as ports, virtualization, ZFS, and DNS. I helped to co-chair the working group on improving the translation process for documentation.
On Friday, the two-day conference proper began. Since I was on registration table duty, I’ll be catching up on the presentations via the slides (most should be available in the schedule at the BSDCan website) and the videos once they become available online.
On Sunday, the BSD Certification Group launched the first beta of the lab portion of the BSDP certification exam. The lab runs on PC-BSD and provides qemu virtualized environments of FreeBSD, OpenBSD, NetBSD, and DragonFly BSD. Examinees are provided with a series of tasks to complete on their BSD of choice within a 3 hour time limit. One of the FreeNAS developers, who is also BSDA certified, participated in the beta.
On Wednesday through Saturday evenings I participated in the doc sprint lounge. The lounge was very successful this year, with several dozen attendees filtering in after dinner and staying until the janitor kicked us out. Several new users were trained in how to use the FreeBSD documentation tools and successfully submitted patches and watched as they were committed. What usually takes several days or weeks to explain over IRC or email can be explained in an hour or so in person as a committer can see what a new person struggles with (and improve the process or its documentation) and the new person can watch how to do something. It also introduces the new person to the committers so that it is easier to ask for help in the future. The committers also committed a few major chapter updates to the Handbook.
Dru Lavigne
Technical Documentation Specialist
