(Students please have a look at gsoc)

This page is for organizing our participation at the Google Summer of Code 2012.

Quoting http://www.booki.cc/gsoc-mentoring/_v/1.0/what-is-gsoc/:

Mentors are people from the community who volunteer to work with a student. Mentors provide guidance such as pointers to useful documentation, code reviews, etc. In addition to providing students with feedback and pointers, a mentor acts as an ambassador to help student contributors integrate into their project's community. Some organizations choose to assign more than one mentor to each of their students. Many members of the community provide guidance to their project's GSoC students without mentoring in an “official” capacity, much as they would answer anyone's questions on the project's mailing list or IRC channel.

The Summer of Code Mentoring HOWTO of a GNOME developer and the official GSoC Mentoring guide are really useful resources about what you can expect and what mentors should (and should not) do.

Mentors should

• Have enough time (the FAQ says about 5 hours/student and week)
• Be reachable. Students may work full time so you should be reachable quickly when there are problems and a student can't continue.
• Be part of the DokuWiki (development) community. You should follow the development and the discussions on the mailinglist, know at least the parts of DokuWiki the ideas you want to be mentor for affect and have a general overview of the rest (e.g. you don't need to know the internals of the parser or renderer when you want to be mentor for the meta-API).
• Be DokuWiki or DokuWiki plugin developer. Your contributions should show that you know what you are doing.

Feel free to add yourself as mentor also for ideas where a mentor is already listed. Then we can balance the load of the different mentors when it is decided which ideas will actually be implemented so not one mentor has 5 students and another mentor has not a single student. There can also be more than one mentor per student.

If you don't like being mentor for any existing idea and don't have own ideas you can still be mentor for new ideas students submit. Just join the discussion on the mailinglist and contact Michael Hamann after the student application period so you can be added as mentor in the GSOC system and review applications.

After the application period we will have to review and rank all applications in the GSOC system. There we need to assign the final mentors for each task.

Some thoughts from 2011

• Improve the internal selection of applications process, suggested rating system
  1. Written their name
  2. Something in the proposal
  3. Interesting
  4. I'd give some time to mentor
  5. I'd be happy to mentor this
• Add 2-3 public demo's during the summer
• Formalize mentors meeting before midterm and final evaluation → set dates
• Invite (mail) students to other coding/hackfest/bug weekend shortly after pencils down. Inspire to further engagement as discussed on mentor summit.

Some examples of how to (not) do it http://puredata.info/dev/recycle_bin/summer-of-code_old/GoogleSummerOfCodeIdeas/.

Application for mentoring organizations starts at February 27 and goes till March 9 2012. Project administrator for Google Summer of Code will be michitux.

• For a list of possible projects, see ideas, the list of ideas for GSOC is at ideas (yes, it might be some duplication, but I think it should really be on one page and it gives us the possibility to not to include all ideas in the list for GSOC).
• Select mentors
• Write an application, a try to answer these questions:
  1. Describe your organization.
     • DokuWiki is a standards compliant, simple to use Wiki, mainly aimed at creating documentation of any kind. It is targeted at developer teams, workgroups and small companies. It has a simple but powerful syntax which makes sure the datafiles remain readable outside the Wiki and eases the creation of structured texts. All data is stored in plain text files – no database is required. A powerful plugin system makes the implementation of additional features like blogging possible while the core code still follows the KISS principle. DokuWiki is used by many individuals, groups, universities, government institutions and companies not just for documentation but also for public company websites, blogs, large community wikis like the French Ubuntu users and a lot more.
  2. Why is your organization applying to participate in Google Summer of Code 2012? What do you hope to gain by participating?
     • Lessons learned from our participation in 2011 showed that during GSoC we got both bigger coding tasks completed and the teamwork within core developers were enhanced. We would also like to to attract new developers with the help of GSoC that implement new features during GSoC but will also continue to contribute to DokuWiki in the long term.
  3. Did your organization participate in past Google Summer of Codes? If so, please summarize your involvement and the successes and challenges of your participation.
     • Yes, we participated in 2011 for the first time. We mentored two students we selected out of 50 applications, both completed the program successfully. One of the challenges we faced was to maintain the contact between the mentors during the coding period in order to stay informed about the progress of the students. But the outcome were better communication between core developers being aware of the need to set aside time for this also after the summer. One of the projects (a new media manage including media revision support) is already part of the current stable release, the other project, a new extension manager is maintained as a standalone plugin currently and is planned to be bundled in one of the coming releases. While mentoring has taken a lot of time from regular development, fairly large features have been completed in time for our release schedule. This would not have been the case without GSoC.
  4. If your organization has not previously participated in Google Summer of Code, have you applied in the past? If so, for what year(s)?
     • -
  5. What license(s) does your project use?
     • GPL version 2.
  6. What is the URL for your Ideas page?
     • ideas
  7. What is the main development mailing list for your organization?
     • Our general (and development) mailing list is http://www.freelists.org/list/dokuwiki - have a look at mailinglist for our mailing list rules.
  8. What is the main IRC channel for your organization?
     • irc://irc.freenode.net/dokuwiki
  9. Does your organization have an application template you would like to see students use? If so, please provide it now.
     • Yes, see the_application (full template included in the actual application)
  10. Who will be your backup organization administrator?
      • Andreas Gohr
  11. What criteria did you use to select these individuals as mentors? Please be as specific as possible.
      • Our mentors are active contributors and know the DokuWiki code. All of them have direct commit access to our main repository and are also active members of the DokuWiki community. We have met each other in person at Hackfests.
  12. What is your plan for dealing with disappearing students?
      • Try to contact them (and collect contact information like the phone number at the latest when they are accepted)
      • Make sure they provide their code after each (even small) change (in their own fork at GitHub or in our repository) so at least we won't loose the code
      • If they don't reappear or reappear and can't catch up let them fail in the next review (and let them know they will fail in the review of course)
      • If this happens already during the community bonding period contact Google directly
  13. What is your plan for dealing with disappearing mentors?
      • Try to contact them, e.g. by phone, and replace them ASAP.
  14. What steps will you take to encourage students to interact with your project's community before, during and after the program?
      • Require students to subscribe to the mailinglist
      • Introduce them to the mailinglist
      • Encourage them to ask questions on the mailinglist and in the IRC channel rather than via private chat/mail - of course mentors will be present there and will make sure the questions are answered
      • Require students to present their concept and intermediate stages of their work on the mailinglist
      • Encourage them to fix and commit a least one minor bug from our bugtracker
  15. What will you do to ensure that your accepted students stick with the project after Google Summer of Code concludes? (This question hasn't been part of the actual application)
      • Encourage them to do so
      • Students of course keep the copyright of their code so they become part of the project rather than just their code
      • Ensure that the code the students produce can actually be included in the project during the development process so that students won't be frustrated because their code can't be used
        • Depending on the nature of the changes and how much review/changes the code from a student needs students can also directly work in the main repository so they become part of the normal development process already during their GSOC work
      • Give students commit access to the main repository so they can easily contribute changes if the changes they submit show that they are able to work directly in the main repository
      • Actively invite them to join a bug hunting weekend or any other project event directly after GSoC