GSoC 2016

The whole GSoC process in nutshell (video, GitHub wiki page):

  1. Browse through our GSoC 2016 Idea & Project list for ideas. If you have found an idea that you like, fill the Student Application Form. If you have your own idea and you do not find it on our list, write your idea in the same format as the others and send it to the syslog-ng mailing list.
  2. You will receive a short task with hard deadline. The syslog-ng team expects high-quality solutions.
  3. The syslog-ng team collects the proposals selects the best ones.
  4. The syslog-ng community votes for the best projects.
  5. Project mentors will assign a student for each project selected by the community.
  6. The project mentors and the students will find a feature owner inside the community.
  7. Feature owners and the syslog-ng team schedule a syslog-ng GSoC release.
    • They will create together a roadmap, a timeline and also a Kanban table for each project.
  8. Students have to keep the Kanban table up to date.
  9. The syslog-ng team builds the syslog-ng GSoC release (with the accepted features).

 

Application period

  1. Read the Getting Started GitBook document about how to work with syslog-ng. If you have any questions or comments about this document, do not hesitate to contact us.
  2. Checkout the syslog-ng repository from GitHub, and build it. If you encounter any difficulties or problems, contact us through the syslog-ng mailing list.
  3. Optional steps (these are really optional, but you will have an advantage in the selection process if you help us):
    1. Pick an easy bug in syslog-ng, and try to solve it.
    2. Contribute something that has value (this means that indentation correction is not what we need 😉 ).
  4. Browse through our GSoC 2016 Idea & Project list for ideas. Select a project that you would like to work on. We recommend to choose a project that you already have some background knowledge for. If you absolutely have no knowledge about syslog-ng, and no knowledge about the subject of the project, we do not recommend applying, because our projects are not easy. Therefore, choose a project that fits your interests and skills best. If you have your own idea and you do not find it on our list, write your idea in the same format as the others and send it to the syslog-ng mailing list.
  5. After you have selected a project, fill the Student Application Form. We can only accept students who have filled this form.
  6. Before submitting your proposal, read our guidelines about creating a proposal for GSoC 2016.
  7. To submit your proposal, create a new Wiki page for it, as described in the GSoC 2016 Proposals document. Do not forget to also record your proposal on the Google Summer of Code page by posting a link to the previously created Wiki page.
  8. After processing the Student Application Forms, the candidates will receive a surveying task related to the chosen project with a strict deadline. If you are a candidate, make sure to complete this task with focus on quality, and on time.
  9. We evaluate the completed tasks and then we receive slots from Google. After this, we announce the winner projects and the names of the assigned students.

 

Coding period

Responsibilities of the participants

  • Mentors
    • Mentors regularly monitor students’ work (whether they need help, whether the project is on track, and so on), at least on a weekly basis. Mentors have the responsiblity to write blog posts about the project during the coding period (one post every two weeks).
  • Students
    • Students have to keep their code in a public GitHub repository. They also have the responsibility to write blog posts about the project during the coding period (one post every two weeks).
    • Students have to keep the Kanban table up-to-date.
    • Students should handle their project as a full-time job, because none of our projects is easy.
    • Students must inform their mentors about their upcoming busy periods (for example exams, holidays) as soon as possible.
    • Students must continuously communicate with their mentors. If they fail to do so without any prior notification, the mentor will consider this as giving up the project after a while.
  • Feature owners
    • Feature owners represent the community during the development phase.
    • Feature owners send feedback to the students.
    • Feature owners write blogpost(s) about the feature.
  • Org admins
    • Org admins will organize events (Gitter, Hangouts, and so on), where they can update the status and check project Kanban tables.
    • Status updates: they keep an eye on the release, update the roadmap if necessary, and share the status with the community.