Some of my current projects :

• MurrayStokely/IdeasWebApp
• CoreLinuxMagazineInterview
• SummerOfCodeMentorAdvice
• SummerOfCodeStudentChecklist
• SummerOfCodeMentorChecklist

Being a full-time employee at Google, I use my 20% time to help organize FreeBSD's involvement in the Google Summer of Code. For previous year involvement, please see our pages from 2005, 2006, and 2007.

I have helped to mentor the following students in the past :

• DarioFreni
• EmilyBoyd
• TylerBallance

Website Ideas

I have some doc/ related projects pending, I have added them to http://www.FreeBSD.org/docproj/current.html

Over the years we've had several instances when an outsider has wanted to spend a lot of time and money making an improvement to FreeBSD, but was worried that it would not be accepted after all the work is done. After much discussion on the lists, it becomes clear that community has conflicting goals, and the original gung-ho would-be contributor is convinced that his efforts will never be appreciated or accepted, and then goes off and does something else.

For that reason, I think it really behooves us to come up with a concise list of goals that we are looking for in a new website. We can then post these as freebsd.org/docproj/website.html, make a newsflash announcing a call for help, and give both internal and external developers an idea about what we're looking for and what is most likely to be enthusiastically accepted.

High level goals :

* All website content should be kept in CVS so that revision history is easily accessible and changes can be picked up by the different translation teams.

* Any new technologies used on the website must be i18n aware.

* PHP is not currently available on all of our website mirrors around the world. A compelling argument (i.e., much desired enhanced functionality of the website) would have to be made to force this requirement on our mirrors. Similar for other apache modules and the like.

* Where possible, structured documents (SGML/XML) are strongly preferred. Volunteers from the doc@ team can help integrate HTML files into our SGML/XML build structure if a design is chosen to be implemented, so this is not strictly a requirement that the designer needs to worry about.

* Pages should not be heavy on graphics or other content that significantly increase the download time for FreeBSD.org pages.

* The online content on freebsd.org is constantly evolving. No static design (involving images for headers that need to be designed in a graphics application, for example) will ever suffice. When the design is done, it should be possible for a non-design expert to quickly write up a new web page for the site with exactly the same look and feel.

* Work should focus on a redesign of the presentation of our existing content, with minimal new content for now. This will never happen if we take on more work than any company or group of individuals can accomplish with donated time. There is a very large corpus of content in doc/ and www/ and adding additional content can be another task after the redesign is completed.

What we actually need :

Design templates for :

• Front page

• Second level pages - Style 1 : without side navigation bar : SMP Project page, RE Page, etc. - Style 2 : with side navigation bar(s) : Java page, gnome, etc..

• Books, articles, and other technical documentation (we're relatively happy with what we have here already, but better navigation could be added)

• Design templates could be converted by the doc project into XSLT stylesheets so that we can continue dynamically building the website from our SGML/XML sources, so the integration work does not need to be done by a designer.
• As much as possible, content questions should be separate from design questions. We've decided we need a redesign.

Once we have a new layout, we would discuss :

• Do we like the layout?
• Is it usable?
• Does it fit well with the existing body of content we have available, or does it require significant new content contributions as well?
• Does it comply with the specifications above.
• If not, are the places in which it does not comply that are not so important if judged by pros/cons of the layout?