Re: [xwiki-devs] [GSOC] Welcoming this year's GSoC student

On 23 Apr 2016, at 09:40, Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com> wrote: Hi Fitz, Welcome to the community! Have fun! Thanks, Marius On Sat, Apr 23, 2016 at 12:10 AM, Eduard Moraru <enygma2002(a)gmail.com> wrote: > Hello community, Hello Google Summer of Code students and applicants, > > First of all, we would like to thank all of this year's GSoC student > applicants for their interest in XWiki. Even if this year we have been > assigned and selected only 1 slot for the program, we would still help and > encourage any student interested to do a project without Google's > implication and enjoy all the benefits of the program, except for the > Google sponsored money of course. If you would like to do that, please let > us know by replying to this mail. You are always welcomed to our community. > > Having said that, we would like to acknowledge and welcome Fitz as this > year's Google Summer of Code student inside the XWiki development team! > > We know you have already started looking into the details of your project > (which is gear!). Here are some general getting started hints for the next > steps of the program: > > = Community bonding period = > > According to the program timeline [2], the next month (until - May 22nd) is > to be used for community bonding. > > You have already introduced yourself to the community, but keep > communicating and exploring. > > Also, you should continue getting acquainted with the project, 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 any time 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 wasting 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?" > > Start monitoring the devs mailing list 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. > > 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 our code is now hosted on 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! > > -The XWiki Development Team > > ---------- > [1] https://developers.google.com/open-source/gsoc/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 > [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&request… > [15] http://dev.xwiki.org/xwiki/bin/view/Drafts/