Talk:GSoC News and Tips

Matters of Taste
James 05:02, 5 May 2008 (PDT):
 * I've removed 'simply' and 'handy' which I'm allergic to. In my time I've seen way too much of "It's easy to make your own wombat, simply click on the handy thingamyboo". I prefer "To make your own wombat, click thingamyboo".
 * I'm not sure you'll agree with the new wording in the intro. I like to keep the 'what this is' in the box, and stuff that doesn't have to be read outside.  If you don't like it, change it.  It's probably quicker to work that way, only using talk page to resolve different opinion when we feel the intent of changes is not been understood and talking will stop a lot of back and forth edits.


 * Gale 05May08, 19:09 UTC:
 * I am aware of your allergy and "handy" and "simply" were to be "chatty", which is part of the point here, and I think sometimes you add "un-necessary" words for the same general reason, though not perhaps as part of an instruction :=) Either way, fine to drop "handy" and "simply", and in more formal context, general avoidance of "simply" etc. is long since taken on board.


 * You're right, visually I don't like unformatted text between the Intro template and the TOC. To me it looks bad visually, and I think it confuses and draws attention to itself, even to the person who read the Intro and decided they weren't really interested. I think the better solution is either to put the "optional" part of the intro after the pipe, so it's italicised, or use a hint box for it if it's extensive. Either method "looks" better to me, and I think lets the user who's not interested dismiss them quicker. I'll try one or the other.


 * I've archived your comment about the web app no longer being used along with the text that was in use. Thanks for that.

audacity-devel content
Gale: This is an interesting idea, but if done regularly placing a digest of audacity-devel here will really mess this page up IMO. We don't have the space here to present it readably with bullet points. In any case the "highlights" don't have much to do with GSoC (though I know the point is to remind the students of what is going on in the project as a whole). Instead of this, why not create a separate regular page (carrying on after GSoC) that does just this - what's currently going on with ongoing development of the project? May even produce a few more sign-ups for the list. Then the GSoC news item is the new Wiki page.

PS: I used "Enrollment" as that spelling (US English) is that used on Google's documents.

James: My mistake with Enrollment. Didn't realise it was correct US spelling. James: I added the digest because we need something every week or so on the GSoC list, and of course not a lot specifically GSoCcy is happening during this phase. If you have enough energy to fill the GSoC news page and a digest page, by all means split. I however think we do need to do occasional 'tricks' like this to stop the news being stale. We can always (timewarp) clean up / archive old content as this list gets longer. At the moment it is OK, I think.

Gale 09May08 08:32 UTC: Guessing what another digest of -devel list would look like on top of the previous one, I don't think another will work very well on this page. Am prepared to do another digest on Saturday or Sunday 10th/11th and put it on its own page. That itself can be a news item. Then take it from there. I think it's worth a go, let's users know we aren't just asleep during the hiatuses between releases?

James 03:23, 21 June 2008 (PDT): OK. Now we are seeing how it is working out, and I think it is creating more work for us (or for you) than it should. There's some overlap between GSoC Alphas, Developer News and GSoC News and Tips. We can leave it as is, because it is also work to change it! There would also be problems trying to restructure. GSoC Alphas needs to be strict about reporting on the state of code at that date, so probably couldn't/shouldn't include info about categories having been discussed, though that IS relevant to that section in Developer News. This would make merging more difficult, were we to try it.

So, I say we continue on with the current arrangement. We could consider naming changes, e.g GSoC News and Tips is more 'GSoC key-dates (and tips)'. Developer News is more 'Summarised Audacity-Devel' - probably it wouldn't help. If none of us have a brilliant idea as to how to make it better, best to leave it as is.


 * Gale 21Jun08,16:44 UTC: My 2p: The idea of a "developer news summary" in GSoC News and Tips was a response to a perceived temporary problem, and never belonged there; that page is as you say "tips and key dates". Then I had the idea of generalising the "news summary" and aiming it a little below developer level/use it to highlight the sort of issues we face/make us seem a bit less "hidden in a castle" to the average user. It does not need to be restricted to -devel list, but mostly would cover topics there. It gets 600 or so views per week, maybe more if we linked to it slightly differently so that we did not suggest it was only for developers. Another aim for it is to (possibly) attract more devel list subscribers. It is considerable work for me, but I would not want to drop it (just) yet. Comments? I was very conscious of the overlap when you started the GSoC Alphas, and other than documenting what happened, I'm a little unclear as to its purpose. It reminds us of the timetable and gives us a factual summary (without it I wouldn't have known from its project page that GridSizer was running on two platforms), but to me it's superfluous. Its "notes for students" could have been a tip on GSoC News and Tips which is difficult to keep alive. Otherwise it contains "key dates" (if we want to remind our students of these they could go on the tips page) and developer level comments (could go on individual project progress pages). So I think I'm suggesting axe GSoC Alphas, and if there are things going on with GridSizer that won't be visible to me on -devel, just keep me informed. I'll then keep Developer News going until end of GSoC, which would be a good time to review if my idea of what it might be is worth the continuing effort.
 * James We both created content about the Alpha on the same day. I hadn't seen your version when I wrote mine - sorry.  In fact I first read your version today.  For running GSoC we do need the GSoC Alphas page.  I need to show (just) the progress between versions.  I'll take responsibility for maintaining that page.   If I'm lazy, I may even steal your text and modify it for future Alphas....
 * Gale 22Jun08, 07:47 UTC: OK, if you judge you need an overall progress page, but I think it does make something of a duplication problem, not only with Developer News, but with the individual project pages - I see very little on the alphas page that truly cuts across them globally. I don't think GSoC News and Tips has worked, myself. Maybe next year give it a title like the near-unused GSoC 2008 Timeline (Calendar?) and consider that as a page for key dates, milestones, and overall progress? The only tips we have are really concerned with what you might call "induction" so maybe slant the page that way next time and withdraw it after the first month or so. Anyway, just throwing ideas around.
 * James I agree about future and reasons. I need GSoC Alphas, or currently think I do, partly because students (and to some extent mentors) are more keen to report on latest versions - not what was actually available by the Alpha time.

IRC Security
Gale 22Apr08, 23:10 UTC: Interesting the broadband router did not help, generally though they are considered to be very beneficial as they act as a hardware firewall (and you're better to use one than not). Though a somewhat separate issue (more about preventing eavesdropping), encryption by using an SSL IRC client might possibly be discussed as a topic on the Irc page (by someone who knows about it)...


 * James Thousands of people use IRC without problem. My problems probably arose from using an inherently insecure operating system (Windows 98) with a not up to date IRC client, i.e. known exploits since my last update, on a popular IRC channel.  The warning boxes are getting more and more unreadable, and possibly putting people off using IRC at all.  Google are very keen on people using IRC.  They see it as having a huge positive effect on projects.  I'm keeping away from IRC myself, as long as I'm on any Windows machine that matters to me.  It's probably over reaction, but it feels right to me.
 * My impression is a broadband router makes almost no real difference. Once malware starts to take hold it can download modules and communicate to the main botnet over any channel that's available.  Even spam (random words) can have encoded instructions in it.  It's too peripheral a point to be made here.  There are any number of points of similar importance that could be made.
 * I'd prefer a much shorter warning both here and on the IRC page. "IRC can be a security risk.  If using windows, ensure you have anti-malware software installed and enabled.  Keep your IRC client software up to date with any security patches."  This warning box and the one on the IRC page are good examples of word-creep where a simple point has become ever more complex and unwieldy.  If more text really is needed, why not start a page 'security tips' -  "IRC can be a security risk.  See security-tips"?
 * Gale 23Apr08, 17:31 UTC: I do think reaction to the length is personal =:), but agree that the risk of putting IRC newbies off increases with the length due to the use of the alert box. So I'll prune it on both pages. I think though the creep happened because the wording may have been "slightly" too long/personal to begin with, then you added a comment about broadband routers to the warning box, and then I was concerned that people must not be put off using a broadband router per se. While I agree entirely once the malware takes hold the router makes little difference, in general principle using one is inherently far safer than just using a software firewall. I don't think we have enough expert content to have a "security tips" page, but the link I already added to the irchelp.org security page ought to cover that (and they strongly recommend a hardware firewall such as a router).

After student applications close

 * Gale: Is there any good tip we can post for what happens next after student applications close? Maybe modify the "getting comments on your proposal" section and archive the original here if it was useful?
 * James After new applications close, students can still add comments that are tacked on the end of their application, and so can we. Students should look at lifting their weakest aspect - e.g. if they still have no mid-term spin off, then they really do need to make clear what they plan via the comments.  Students who want to edit the main part of their application can even do so (I believe) after they receive a comment to them from us, so a tip to them is that they can add a comment to say 'I want to update the timeline to include a Seven Keyboard Wurlitzer Organ Effect for the mid term eval', and then we'd reply and they could make that change.
 * James At this point we know how many slots we are likely to get. However Google prefer that we do not announce slot count, and take a very dim view of announcing which students are in and which are out before Google do.  One reason is that this can change right up to the last minute.  Organisations which do announce students (and get it wrong) might not be invited back.
 * Vaughan The process for deciding slot counts is described on the . There's a fair amount of negotiation and winnowing for Google deciding allocations. I think Google has documented the process extensively for mentors and students, so we don't actually need to give more guidelines. And we may not really *have* any news until the announce date.

Content of News and Tips

 * James 27 March 2008: Amount of content present looks well judged, given the limited resources we have to do a newsdesk! About a line or so every two days until things quieten down.

Logo

 * James 27 March 2008: Really like the google logo, but worth checking FAQs to see if we really can use it - I know it's been discussed before. Might be safer to use a summer-of-code google logo instead - which I know we can - or have you already checked?  (I thought google-code was wider than just GSoC).
 * Gale: Google-code is definitely wider than GSoC but I could not find anything in the GSoC FAQs about a logo, except the GSoC logo for 2007. I can't find a GSoC logo for 2008, so followed Vaughan's idea where he used the Google-code logo on the main web site. I did find a project announcing its 2008 mentorship that uses the exact same GSoC image with the year removed. I think that looks pretty dreary myself (summer = black?) but I can use that for want of a better one if you prefer?
 * James: This is from GSoC Announce list. You might want to subscribe. "Behold the 2008 program logo: http:// tinyurl . com/2u7wqu. Possibly use a strip taken from the centre as it is a square 'logo'.
 * Gale: Not a terribly good logo for integrating in web pages is it? ("of" too small). I've done the best I can with it, within the constraints of stopping it overflowing into the news section at small text sizes without introducing too much white space. I can't see just taking "Summer of Code" and then just showing the Southern Hemisphere is an answer? Have subscribed to announce list.

Getting comments on your proposal
Now we are well into the student application period, the best way to get comments on your ideas, so they can be refined into a good proposal, is to post to your. That way, you will get direct mentor feedback from Audacity. If you want to make your ideas public, or perhaps draft them out/make notes to yourself first, you can create a User Page on this Wiki. To create or view your User Page, simply type (without the brackets) '''[ ALT SHIFT. ]''' . Accepted students will have their own project-specific Wiki page to discuss and report progress on their project when the time comes.

Comments and edits via the web app
''In 2008, the below applied for a few weeks after student applications closed. After that, edits to the project detailed description were not possible, even after a mentor comment. Although comments were still possible, they were not being used.''

You can continue to attach comments to your application, and must respond via the web app when you receive email advice that we've posted a public comment to your application. You cannot now edit the "Detailed Description" section of your application., unless we post a public comment. If you need to edit the Detailed Description, you can post your own comment requesting a mentor comment to enable the edit. If you are in doubt, ask for help via IRC (see below).