Google suggests that the idea page is an important part of their selection criteria for mentoring organizations.
Quoting from the "Notes on Organizations Selection Criteria" http://groups.google.com/group/google-summer-of-code-announce/web/notes-on-organization-selection-criteria <quote> 2) Do the projects on your ideas list look feasible for student developers? Is your ideas list thorough and well-organized? Your ideas list is the first place that student participants are going to look to get information on participating in GSoC, so putting a lot of effort into this list is a good thing(tm). One thing we noticed and really appreciated this year was how some organizations classified their ideas by easy, medium and difficult, and specifically listed the skills and background required to complete a given task. It might also be cool to expand on each idea with some places to get started research-wise (pointers to documentation or specific bugs), as well as the impact finishing a given idea will have for the organization. </quote> You may want to look at that entire page. I think we need to do some dress-up of the idea page and suggest the following: * If it was your idea, add your name as sort of the owner / primary contact on the idea, even if you are not willing to mentor. I'll post again pointing to guidelines and so forth on mentoring--in general, in addition to mentoring a student, you will need to provide written evalutation(s?) of his performance. If you are willing to mentor for that idea, say so. (I don't think the owner or originator of an idea should be or is necessarily the best person to mentor a project. He (the originator of the idea) may be an important person for a student to contact for clarifications related to the intent of the idea.) * Make the entry on the main wiki page reasonably short (1 to 3 paragraphs). Move stuff beyond that either to the talk (discussion) page or a completely new wiki page. We should (imho) work towards organizing the talk page so it has the same headings (wording and sequence) as the main wiki page, although, of course, additional subheadings can and should be used as appropriate to keep it easy-to-read. * Try to follow the suggestions in the quote above. Maybe I should bring this up somewhere else, but I have two concerns about the Unicode project: * Is that anywhere close to small enough that it can make a reasonable GSoC project? And, you ask, how big can that be? Good question, I think I saw some guidelines somewhere, I'll look for those again. I guess we could get lucky and find a student who is familiar with both Unicode and the NEdit code base, and there is nothing wrong with saying we need someone like that for this project--but, automatically, I'd then characterize it as a difficult or very difficult project (simply on the basis that it will be difficult to find a student with that knowledge). If it is too big for a single GSoC project, can you identify smaller sub-projects which might be a reasonable scope of work, yet still help us move toward the goal of Unicode? * I think I'll save my 2nd concern for another post. I don't know how familiar everyone is with wikis, and I'm not very familiar with the wiki engine used on Niki (it appears to be the same one that Wikipedia uses)--does it have a lock mechanism or similar to avoid editing conflicts (or is it, for example, one of the "last to save, wins" wikis--I guess I'll find out). If you find yourself locked out of a wiki page or are concerned that it is a last-to-save, wins wiki, maybe you want to copy and paste from the wiki page, do your editing, and then, if necessary, we'll coordinate an effort to get all the pages back to the wiki page(s). Finally, I'm sure I keep sounding hesitant, but I get the feeling that other organizations started on their preparations for this year's GSoC much earlier than we, and we might consider not submitting an application this year, but instead prepare better for next year. Randy Kramer -- NEdit Develop mailing list - [email protected] http://www.nedit.org/mailman/listinfo/develop
