Difference between revisions of "GSoC Planning"

From Audacity Wiki
Jump to: navigation, search
(Some updates based on experience.)
(fix couple of hyphens and a typo)
Line 15: Line 15:
 
* Integration projects (projects in which an existing library is integrated) need particular care with regard to tracking student progress.  Such projects tend to be 'chunky'.  Everything arrives at once.  Insist on a CVS or other repository we can track transparently, not a 'remote infrequently synced repository'.
 
* Integration projects (projects in which an existing library is integrated) need particular care with regard to tracking student progress.  Such projects tend to be 'chunky'.  Everything arrives at once.  Insist on a CVS or other repository we can track transparently, not a 'remote infrequently synced repository'.
 
* Find consistent naming for the two pages per project.  ProjectName-Notes and ProjectName-Progress are suggested.  In 2008 we didn't have consistent names.   
 
* Find consistent naming for the two pages per project.  ProjectName-Notes and ProjectName-Progress are suggested.  In 2008 we didn't have consistent names.   
* After GSoC kick-off, do not add new student submitted ideas to the [[GSoC Ideas]] page but let them instead manage their own notes page.  In 2008 it was a little confusing having some edits to the ideas source.
+
* After GSoC kick-off, do not add new student-submitted ideas to the [[GSoC Ideas]] page but let them instead manage their own notes page.  In 2008 it was a little confusing having some edits to the ideas source.
 
* Ditch the 'expression of interest' page.  It didn't serve a useful function.
 
* Ditch the 'expression of interest' page.  It didn't serve a useful function.
  
Line 27: Line 27:
 
==Recurring Planning Needs==
 
==Recurring Planning Needs==
  
* In the run up to GSoC we wanted to get our developer documentation into good shape.  This is particularly important for new features like the plug in interface.  Help with bringing the Doxygen documentation back up to date would be appreciated and is also a good way of learning the code.  We'd also like to go further and have diagrams and more written documentation that shows how things work.   
+
* In the run up to GSoC we wanted to get our developer documentation into good shape.  This is particularly important for new features like the plug-in interface.  Help with bringing the Doxygen documentation back up to date would be appreciated and is also a good way of learning the code.  We'd also like to go further and have diagrams and more written documentation that shows how things work.   
  
 
* We can always do with new ideas on the [[GSoC Ideas|ideas]] page.  Suggestions that have an element of novelty to them, that can be completed in the time frame are particularly welcome.  We feel it's important that projects have both an aspect which is fairly straightforward to complete in the time as well as a stretch goal.  We need to get something complete and usable out of each project, whether it goes superbly or whether there are difficulties.
 
* We can always do with new ideas on the [[GSoC Ideas|ideas]] page.  Suggestions that have an element of novelty to them, that can be completed in the time frame are particularly welcome.  We feel it's important that projects have both an aspect which is fairly straightforward to complete in the time as well as a stretch goal.  We need to get something complete and usable out of each project, whether it goes superbly or whether there are difficulties.
Line 33: Line 33:
 
* We would like someone to help us design a half-page [[GSoC Flyer|flyer for Audacity GSoC]] which we can put on notice boards in computer science labs in universities.  If there are multiple offers to do this, then we'll vote on the flyer to use on the audacity-devel mailing list.
 
* We would like someone to help us design a half-page [[GSoC Flyer|flyer for Audacity GSoC]] which we can put on notice boards in computer science labs in universities.  If there are multiple offers to do this, then we'll vote on the flyer to use on the audacity-devel mailing list.
  
* Some of the projects are likely to be on overlap between Audacity and wxWidgets, Portaudio or Jack.  In those cases, if the project is being administered and mentored by Audacity, it would still be very useful to have a second mentor from the overlap project already lined up to give advice.
+
* Some of the projects are likely to be an overlap between Audacity and wxWidgets, Portaudio or Jack.  In those cases, if the project is being administered and mentored by Audacity, it would still be very useful to have a second mentor from the overlap project already lined up to give advice.
  
  
 
----
 
----
 
[[Category:For Developers]] [[Category:GSoC]]
 
[[Category:For Developers]] [[Category:GSoC]]

Revision as of 23:40, 13 September 2008


This page is to help with planning for Google Summer of Code. It's a 'brainstorming' page at the moment. All subscribers to audacity-devel are very welcome to add comments and suggestions. James 05:26, 27 July 2007 (PDT)

2009

  • Richard: Is it a good time to start on a "what are we looking for in students" page for next year. I think a reasonable number of applicants (especially from outside US/Europe) have mis-judged what we were looking for, and some more concrete points (based on what was said in private comments but in a general form) might help students (and us) next year. A key one is about time commitment, especially for post-grad people who don't really have a summer vac. There are also a lot of new-to-open-source people who don't get the whole fitting in / code re-use / connected open source philosophy, which I've tried to lever a number of people towards, but hasn't always worked.
    • Gale: Could also be included/linked to in the "Hints on writing a good proposal" panel in Writing GSoC Proposals. Information in situ may have more chance of being read than in a link.
    • James: I think personal opinion works well here. So a blog on it, with a link from the wiki? One thing I want to get across to students is that different mentors will have different views, so whilst I'll agree with what Richard says, I'd have a different slant on it and emphasise some other points.
    • Gale: Not sure where the blog would be, but perhaps in the bullet point with the link, one or two more or less consensual points could be given as examples of what we want. Vaughan has noticed some student lack of awareness due to not reading online material.


Carry Forward from 2008

  • All students to get gmail/googlemail accounts. Ensure it's clear that it's our requirement, not googles because this created some confusion last year. Mentors of course should have gmail accounts too, to be listed as mentors - but all likely mentors do now.
  • Integration projects (projects in which an existing library is integrated) need particular care with regard to tracking student progress. Such projects tend to be 'chunky'. Everything arrives at once. Insist on a CVS or other repository we can track transparently, not a 'remote infrequently synced repository'.
  • Find consistent naming for the two pages per project. ProjectName-Notes and ProjectName-Progress are suggested. In 2008 we didn't have consistent names.
  • After GSoC kick-off, do not add new student-submitted ideas to the GSoC Ideas page but let them instead manage their own notes page. In 2008 it was a little confusing having some edits to the ideas source.
  • Ditch the 'expression of interest' page. It didn't serve a useful function.


Review Notes 2008 (Pruned)

  • James: More GSoC Ideas has over ten times fewer views than GSoC Ideas.
    • Gale: Make the link to More GSoC Ideas more prominent, or list a summary of all projects on one page with links to them, marking the provisional ones as such?
    • James: Link to more prominent.


Recurring Planning Needs

  • In the run up to GSoC we wanted to get our developer documentation into good shape. This is particularly important for new features like the plug-in interface. Help with bringing the Doxygen documentation back up to date would be appreciated and is also a good way of learning the code. We'd also like to go further and have diagrams and more written documentation that shows how things work.
  • We can always do with new ideas on the ideas page. Suggestions that have an element of novelty to them, that can be completed in the time frame are particularly welcome. We feel it's important that projects have both an aspect which is fairly straightforward to complete in the time as well as a stretch goal. We need to get something complete and usable out of each project, whether it goes superbly or whether there are difficulties.
  • We would like someone to help us design a half-page flyer for Audacity GSoC which we can put on notice boards in computer science labs in universities. If there are multiple offers to do this, then we'll vote on the flyer to use on the audacity-devel mailing list.
  • Some of the projects are likely to be an overlap between Audacity and wxWidgets, Portaudio or Jack. In those cases, if the project is being administered and mentored by Audacity, it would still be very useful to have a second mentor from the overlap project already lined up to give advice.