Hello community, Hello Google Summer of Code students,
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. 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 aspect money will be missing, you can still take advantage of the other GSoC benefits: learning new things, gaining experience, earning recognition, and all the good things that come from participating. If you would like to do that, please let us know by replying to this message.
For the accepted students, here are some getting started hints:
Community bonding period
According to the program timeline, the this month (until - May 31st) is to be used for community bonding.
The first thing to do, sometime this week, is to present yourself and your project on the development forum, so that everyone knows who you are and what to expect from you. Of course, you need a forum account (or you can use your xwiki.org account), so create these ASAP if you haven’t already, and make sure you’re available on the chat, for the better part of the program.
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 on Community, DevGuide and Product Features.
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 Chat room or on the forum. 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/Matrix, while the design decisions, important progress announcements and testing/feedback requests go on the devs forum. 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 gets (hypothetically) “hit by a bus” (the bus factor ) another developer can take his place with little effort.
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?”
Register on to the forum (if you didn’t do this already), and start monitoring the discussions (both dev and users discussions). The notifications email list is a little too high volume and technical for the moment, but it is a great knowledge source.
Also, try to make sure that you’re generally available on chat (IRC/Matrix) in order to have a better view on the daily discussions, get involved and generally be easily reachable, should your mentors or any of the students want to easily get a hold of you. Generally speaking, if you are online (working on your project), you should also be available on the chat, just in case.
The project’s lifecycle is NOT design -> implementation -> testing -> documentation.
We invite you to adopt a test driven development (http://en.wikipedia.org/wiki/Test-driven_development, http://www.amazon.com/dp/0321146530/, http://www.amazon.com/dp/0201485672/) approach and to experience agile development. 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 experience shows that nobody does!).
Since our code is hosted on GitHub, 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, 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, Velocity, etc.
– Read (and update, when needed) the documentation available on xwiki.org and that is relevant to your project.
- Continue fixing a few small issues, chosen so that they are related to your project. You can ask on the chat for help selecting good issues, or you can pick from the (non-comprehensive) list of easy issues.
– Do some more medium complexity Pull Requests, 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), 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. When the Coding Period starts, you should be able to start productively coding at full speed, having already cleared any potential issues that might slow you down. And, of course, you should be familiar with the community and the way we communicate, this is very important!
Last thing, this very important note, on the importance of the Community Bonding Period:
If you do not see regular public interaction from the student, you should strongly encourage it. Public interaction is important – it is a key principle of open source – work happens where everyone can see it. Similarly, all work done by the students should be shared in a publicly available repository.
The past 15 years of GSoC have demonstrated that students who don’t interact early and often are much more likely to fail later. Often they just disappear. We don’t want you to waste your time on students who don’t care about the project/organization and don’t even attempt to show interest during the first few weeks of the program. Small contributions early on are a very positive signal.
Students who do not participate in community bonding may and should be removed from the program.
Remember, communication is key and the real point of this program, so learn to use it properly and reach out whenever needed and appropriate!
Good luck, and may we all have a great Summer of Code!
-The XWiki Development Team