Program Schedule and Deadline Dates
- March 5: Mentoring organizations can begin submitting applications to Google
- March 12: Mentoring organization application deadline
- March 13: Google program administrators review organization applications
- March 14: List of accepted mentoring organizations published on code.google.com; student application period opens
- March 23: Student application deadline
- Interim Period: Mentoring organizations review and rank student
proposals; where necessary, mentoring organizations may request further
proposal detail from the student applicant
- April 2: List of accepted student applications published on code.google.com
- Interim Period: Students learn more about/integrate with their project communities
- May 28: Students begin coding for their Google Summer of Code projects;
Google begins issuing initial student payments
- Interim Period: Mentors give students a helping hand and guidance on
- July 9: Students upload code to the Google Summer of Code project
repository; mentors begin mid-term evaluations
- July 16: Mid-term evaluation deadline; Google begins issuing mid-term
- August 20: Students upload code to the Google Summer of Code project
repository; mentors begin final evaluations; students begin final program
- August 31: Final evaluation deadline; Google begins issuing student and
mentoring organization payments
This schedule is subject to change and taken directly from Google. For the latest schedule please see Google SOC 2007 Wiki
PN Project Goals
The general goals of Google are recognized and extended with our own goals. In short, we want to improve the innovation within the project by offering students the opportunity to propose PostNuke related topics. We aim to offer students an inspiring environment to do research, access to field experts, the ability to create proof-of-concepts and the opportunity to create working functional tools that can be used with PostNuke.
There is a limited list of program goals defined below. Please keep in mind this is an initial list of subjects we would like to shoot for and the final projects are open for discussion. It's important to understand we need guidelines for project proposal evaluation otherwise we'll end up with all nice initiatives, but no choice between the individual project.
The following are a few examples of the types of projects we'd like to see during the SOC 2007.
Here are a few suggested project examples:
- Version management of content. Add features to PN, either via hooks or extensions to DBUtil, to allow control of versions of content items. Additionally add workflow processes via the existing workflow module
- Translation management. Currently a translation of a content item is an entirely different and un-related item. A project to introduce a method of translating content while keeping the the relationship to the original item (and hence related content e.g. comments, ratings etc.).
- Loudblog rewrite based on PostNuke's API
- A second project could be the implementation of a better language system + the import of the old system.
- OpenID Implementation
- Universally implemented content versioning such that it's possible to revert back to old versions of specific content items. DBUtil contains a feature called object-logging which basically gives you the ability to log all changes to objects as they are altered (and even revert back to old versions of an obejct), but a proper GUI with some nice administrative features would be nice.
- Integration of the categories system with the nested-set algorithm. The current implementation is path-based which works and carries with it some proper semantic information, but for performance reasons integrating the nested-set algorithm would probably be a good idea.
- Implementation of additional features to the category system on the GUI side. This could be advanced AJAX controls, a better user-side editing system, etc.
- Integration with Lucene and other search engines ideally through a generic search-engine interface which can then be extended to other backend systems.
- A proper universal web services interface for PN.
- A proper test suite including a performance testing framework.
- A proper data import/export system with the ability to generate multiple data formats (CSV, XML, etc.) including a proper control GUI.
There will be two program guides (admins) that will provide all mentors and students with help and guidance throughout the project. The structure will be flat so there won't be a lot of red tape in the process. The mentors are expected to work closely with each student to accomplish each project's goal and objectives.
For each accepted project into the SOC program there will at least one mentor and one student. Along with the one-to-one support the student will have access to the developers list so they have access to the entire team to bounce ideas off of in the process.
Overview of Mentor Selection Process
The general "criteria" for mentors are:
- Mentor is familiar with the PostNuke project and API.
- Mentor is expected to work well with others.
- Mentor should have knowledge about the topic he/she is going to mentor.
- The mentor is responsible for working directly with the student.
Note, before volunteering you should be aware there is a time commitment. We estimate it will take at the minimum 3 to 5 hours per week of your time over a 3 month period. Mentors should also expect to encounter cultural and time zone differences making this a challenging experience on many different levels especially since this will be a virtual mentor/student experience.
Commitment to the goals/objectives of your project, your time, mutual respect, and open communication.
Remember when you were a student -- you were there to learn. This is the same thing -- students are here to learn and may not be experienced in working on a team, and will less likely have experience working with someone virtually so as a mentor you're expected to introduce the student to the protocals of this environment.
Students, remember, no question is stupid, don't expect to know everything, and if in doubt ask! Communication is key in a virtual environment and never take anything for granted especially in text based communication since things can often be mis-read or interpreted.
If you are chosen a mentor then what do you get? You get to contribute to a great project, experience working on a virtual team with an international team of great/inspiring people.
This is most likely the most important part of the process -- communication is key especially in a virtual environment. And communicating/sharing will be important to the success of each project. So students are expected to put together a weekly report -- it doesn't have to be anything fancy -- just an email updating your mentor about your progress and any problems you working on or having. Mentors are expected to take the lead in solving any problems that might arise with timing, language or cultural barriers. Note, the default language for the program is English so all mentors and students are expected to be able to communicate clearly and effectively in English. When disagreements or conflicts arise within a project team members are encouraged to resolve disputes amongst themselves. If they can't resolve it between themselves then you can ask a program mgr to get involved to mediate the dispute.
Project Tools & Support
You will have access to the following software tools:
- The PostNuke NOC (Network Operating Center) where all project related
resources will be housed
- Google Project Page (including wiki)
- Mentor Application from Google
- Developers Mailing List
Google provides some time to allow the student to familiarize themselves with the project and tasks. During this time the mentor can prepare the stucture and any documents that will help the student in the goals and objectives of the project.
Some examples include:
- Action/Tasks planning so the student will have a clear idea of milstones
for the project.
- Provide the student with your communication expectations - i.e., how can
the student communicate with you, skype, instant messenger, email etc.
- Review time committments and goals/objectives for the project.
- Model good behavior -- take the lead when you see the student needs the
extra encouragement and guidance.