(So while we all look sideways and shrug to avoid thinking to hard about the title of this section I shall continue…)
The official period whereby students get to know their mentors, discuss the projects further, integrate with the community and read up on docs etc., ended on the 22nd May and on the 23rd May they started coding.
From the reports, I have been reading that the students submit, our crew* have made a good start to the project, some of them were already integrated into the community they had decided to code for and so had no issues with the ‘honeymoon’ experience.
Building a good superstructure
In previous years the efforts of the GSoC organisers have introduced patterns of behaviour that allow the process to run smoothly but are contained within knowing that pattern and having performed the function beforehand. That is to say that we are reliant on these people being present each year. The methods for success are not written down (in a central location, they may have had personal notes, emails and logs of conversations however) for easy access.
This year rafl made the brave decision to collate information from the previous years and to store that in a central repository. He also decided to write out guidelines for each stage of the process. The basic plan is to have a documented approach that when proven successful can be easily copied and repeated.
When I learned of this I had to give my full support, and as part of the method for marketing in future years took the decision that we store as much of the re-usable material in the same location, also that I might blog/write about this process so there would be a record of the efforts that would aid discussion and improvement.
Calling the troops to order**
Another decision rafl took was to make a clear statement that is stored in the repo, with clear and concise instructions as to the responsibilities of students and mentors. These would not just cover the interaction and reporting between student and mentor but as guidance for all the persons involved. Rafl*** is ensuring that we will have a clear understanding of our duties to each other and attempting to put in place methods by which we can spot if there are problems and hopefully overcome them before they become serious.
As part of this we require that the students make reports that are in the mailing list, rafl also encourages students and mentors to turn those reports into blog posts if the person feels that is what they want to do (which should further help our marketing efforts). you can read those at:
- tadzik: Pod parser for Rakudo: http://ttjjss.wordpress.com/
- andrewalker: Rework Catalyst component setup code: http://perl.andrewalker.net/
- gnusosa: Removing the upgrading necessity of the Dancer script with a module: http://log.gnusosa.net/code/gsoc
- Hugmeir: Making the Perl Core UTF-8 clean:- tbc
- marcg: Standardization of core documentation parsing tools:- tbc
- mo: CPAN search for the modern web – http://blogs.perl.org/users/mo/
*Sorry but ‘team’ sounded incorrect it is an individuals’ challenge, ‘chaps’ is terribly English and implies males (I don’t use it that way, but many people read it thus), ‘gang’ makes me think we should all be taking dance and finger snap lessons in readiness for the Broadway version of Perl: The Musical, so I stayed in ‘da hood’ (which in this case is the terribly English, white, male ‘hood’ of rurally-edged suburban Lancaster).
**Troops, I should have used troops, though that does have an exceedingly militaristic edge (of course).
***Rafl is not the only person responsible for producing the work, but he is coordinating the effort and in many cases the primary catalyst for the events.