Hi All I didn't get selected as a GSOC intern for the project i applied Scalable XWiki on NoSQL (AppEngine, Cassandra ). But i would still like to work on this project. should i put a mail to the devs list regarding the project.
On Wed, Apr 27, 2011 at 4:47 PM, Sergiu Dumitriu <[email protected]> wrote: > Hello community, Hello Google Summer of Code students, > > First of all, congratulations on your applications and your activity > during the selection period, and welcome in the XWiki development team. > > Before guiding the accepted students to their next steps, we'd like to > thank again all those who showed interest in XWiki for this Summer of > Code. We had a lot of good applications this year, with professional > approaches and interesting ideas, and it was very difficult to choose > only 3. Unfortunately, some very good students, with great potential, > were not accepted. So, to those interested in getting involved anyway, > without Google's implication, I renew the invitation to put your ideas > in practice under the guidance of the community. Even though the money > will be missing, you can still take advantage of the other GSoC > benefits: learning new things, gaining experience, earning recognition, > etc [1]. If you would like to do that, please let us know by replying to > this mail. > > For the accepted students, here are some getting started hints: > > = Community bonding period = > > According to the program timeline [2], the next month (until - May 23rd) > is to be used for community bonding. > > The first thing to do, sometime this week, is to present yourself and > your project on the dev list, so that everyone knows who you are and > what to expect from you (a precondition is to be subscribed to the list, > which you should do ASAP if you haven't already). > > Also, you should continue getting acquainted with the code, the > practices and the developers. Please make sure you all read and > understand the following - very useful - documents: > - [3] http://purl.org/xwiki/community/ > - [4] http://purl.org/xwiki/dev/ > - [5] http://platform.xwiki.org/xwiki/bin/view/Features/ > > = Mentorship = > > We prefer open mentorship. While your assigned mentor is the one > officially in charge with your guidance, almost all interaction should > be done 'in the open' as much as possible, on the IRC channel or on the > mailing list. You should choose the communication medium according to > the importance of the matters to be discussed: naturally, the less > important issues are to be discussed on IRC, while the design decisions, > important progress announcements and testing/feedback requests go on the > list. This way, the community is informed on the evolution of your > project, and other developers can come up anytime with useful ideas and > suggestions. Moreover, if your mentor is hit by a bus (the bus factor > [6]), another developer can take his place with little effort. > > = Communication = > > Sitting alone in your room, working secretly on your project is > definitely a bad approach. However, please keep in mind that too much > communication can also be harmful, as it distracts the others from their > own work. You need to be able to communicate just right: > - provide meaningful information about your progress, > - ask the community's opinion on non-trivial design or implementation > decisions > - avoid waisting a lot of time on a problem, when a more experienced > developer (or a student that fought the same problem) could quickly > provide you an answer; however, do try to find the answer yourself at > first. > > Wrong: "Where do I start? What do I do now? And how do I do that? Is > this good? It doesn't work, help me!" > > Right: "Since a couple of hours ago I get a strange exception when > building my project, and googling for a solution doesn't seem to help. > Looking at the error, I think that there's a wrong setting for the > assembly plugin, but nothing I tried works. Can someone please take a > look?" > > Subscribe to the devs list (if you didn't do this already), and start > monitoring the discussions. It is also recommended to subscribe to the > users list, but not mandatory. The notifications list is a little too > high volume and technical for the moment, but it is a great knowledge > source. > > = Development process = > > The project's lifecycle is NOT design -> implementation -> testing -> > documentation. [7] > > We invite you to adopt a test driven development [8][9][10] approach and > to experience agile development [11]. After the first coding week, you > must have some code that works. It won't do much, of course, but it will > be the seed of your project. Every functionality will be validated by > tests. The code must be properly tested and commented at the time of the > writing (don't think you'll do that afterwards, because in most cases > you won't). > > Since we've recently moved our codebase to GitHub [12], you should > register an account there and fork some xwiki repositories, so that you > can try to build XWiki from sources, and be able to contribute bugfixes. > We'll add you to the xwiki-contrib organization [13], and we'll create > dedicated repositories for each project. We encourage you to do __at > least__ weekly commits (ideally, if you are well organized, you should > be able to commit code that works daily, so try to aim at daily > commits). This way, the code can be properly reviewed, and any problems > can be detected before they grow into something too difficult to fix. > One big code blob committed at the end, no matter how good it may seem, > is a failure at several levels. > > A simple way of having something functional in the first week is to > prepare the maven build for your modules, which will give you the first > unit test for the first class. > > = Next steps, in a nutshell = > > - Get more familiar with the code and development process and try to > master Maven, JUnit, Selenium, component driven development, ... > - Continue fixing a few small issues, chosen so that they are __related > to your project__. You can ask on IRC for help selecting good issues, or > you can pick from the (non-comprehensive) list of easy issues [14] > -- This will help you get more familiar with the code your project needs > to interact with. > - Refine and organize the ideas concerning your project (you can use the > Drafts space [15]), and write several use case scenarios. > - Start writing the first piece of code for your project. > > At the end of the community bonding period, you should have a clear > vision of the project, well documented on the xwiki.org wiki, you should > have the build infrastructure ready, and you should be pretty familiar > with the existing code you will need to interact with. And, of course, > you should be familiar with the community and the way we communicate. > > Good luck, and may we all have a great Summer of Code! > > [1] http://www.catb.org/~esr/writings/cathedral-bazaar/homesteading/ > [2] > > http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/timeline > [3] http://purl.org/xwiki/community/ > [4] http://purl.org/xwiki/dev/ > [5] http://platform.xwiki.org/xwiki/bin/view/Features/ > [6] http://en.wikipedia.org/wiki/Bus_factor > [7] http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ > [8] http://en.wikipedia.org/wiki/Test-driven_development > [9] http://www.amazon.com/dp/0321146530/ > [10] http://www.amazon.com/dp/0201485672/ > [11] http://www.amazon.com/dp/0596527675/ > [12] https://github.com/xwiki/ > [13] https://github.com/xwiki-contrib/ > [14] > > http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10510 > [15] http://dev.xwiki.org/xwiki/bin/view/Drafts/ > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Thanks Pulasthi Supun www.99gears.com _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
