[xwiki-devs] [GSOC] Welcoming this year's GSoC student
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&requestId=10... [15] http://dev.xwiki.org/xwiki/bin/view/Drafts/
Hi Dear devs, 2016-04-23 5:10 GMT+08:00 Eduard Moraru <[email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>>:
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!
This is too good to be true. I’m really delighted. Thank you so much for giving me this opportunity and helping me to improve myself and grow up. Hope to contribute to our community as much as I can.
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.
Yes, to keep communicating is very important, which can help me to quickly locate and solve the problem. When I have a problem, I will first find the solution by myself. If there is any doubt and confusion after googling and trying, I will ask for help on the IRC channel or on the mailing list according to the importance of the matters. Thank you for your reminder. I will keep in mind. = 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.
It will be a great help to me for developing the project. And I will follow the above rules, adopting a test driven development and agile development, making clear comments and documents and tring to commit code daily as much as I can. I think this will play a very good role in the development of my career.
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&requestId=10... [15] http://dev.xwiki.org/xwiki/bin/view/Drafts/ _______________________________________________ devs mailing list [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');> http://lists.xwiki.org/mailman/listinfo/devs
I really appreciate that you give me so many useful tips I can learn. I will be familiar with these rules as soon as possible, and start developing my project in a good manner. Thank you once again. Expect to make a greater contribution. Best Regards, Fitz Lee
Hi Fitz, Welcome to the community! Hope you will have a great time :) Thanks, Caty On Sat, Apr 23, 2016 at 5:44 AM, Fitz Lee <[email protected]> wrote:
Hi Dear devs,
2016-04-23 5:10 GMT+08:00 Eduard Moraru <[email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>>:
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!
This is too good to be true. I’m really delighted. Thank you so much for giving me this opportunity and helping me to improve myself and grow up. Hope to contribute to our community as much as I can.
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.
Yes, to keep communicating is very important, which can help me to quickly locate and solve the problem. When I have a problem, I will first find the solution by myself. If there is any doubt and confusion after googling and trying, I will ask for help on the IRC channel or on the mailing list according to the importance of the matters. Thank you for your reminder. I will keep in mind.
= 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.
It will be a great help to me for developing the project. And I will follow the above rules, adopting a test driven development and agile development, making clear comments and documents and tring to commit code daily as much as I can. I think this will play a very good role in the development of my career.
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&requestId=10...
[15] http://dev.xwiki.org/xwiki/bin/view/Drafts/ _______________________________________________ devs mailing list [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');> http://lists.xwiki.org/mailman/listinfo/devs
I really appreciate that you give me so many useful tips I can learn. I will be familiar with these rules as soon as possible, and start developing my project in a good manner. Thank you once again. Expect to make a greater contribution.
Best Regards, Fitz Lee _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Fitz, Finally I can welcome you officially :)
From what I have seen so far it will be a great project !
On Sat, Apr 23, 2016 at 7:47 AM, Ecaterina Moraru (Valica) <[email protected]> wrote:
Hi Fitz,
Welcome to the community! Hope you will have a great time :)
Thanks, Caty
On Sat, Apr 23, 2016 at 5:44 AM, Fitz Lee <[email protected]> wrote:
Hi Dear devs,
2016-04-23 5:10 GMT+08:00 Eduard Moraru <[email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>>:
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!
This is too good to be true. I’m really delighted. Thank you so much for giving me this opportunity and helping me to improve myself and grow up. Hope to contribute to our community as much as I can.
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.
Yes, to keep communicating is very important, which can help me to quickly locate and solve the problem. When I have a problem, I will first find the solution by myself. If there is any doubt and confusion after googling and trying, I will ask for help on the IRC channel or on the mailing list according to the importance of the matters. Thank you for your reminder. I will keep in mind.
= 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.
It will be a great help to me for developing the project. And I will follow the above rules, adopting a test driven development and agile development, making clear comments and documents and tring to commit code daily as much as I can. I think this will play a very good role in the development of my career.
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&requestId=10...
[15] http://dev.xwiki.org/xwiki/bin/view/Drafts/ _______________________________________________ devs mailing list [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');> http://lists.xwiki.org/mailman/listinfo/devs
I really appreciate that you give me so many useful tips I can learn. I will be familiar with these rules as soon as possible, and start developing my project in a good manner. Thank you once again. Expect to make a greater contribution.
Best Regards, Fitz Lee _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi Fitz, Welcome to the community! Have fun! Thanks, Marius On Sat, Apr 23, 2016 at 12:10 AM, Eduard Moraru <[email protected]> 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&requestId=10... [15] http://dev.xwiki.org/xwiki/bin/view/Drafts/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Yes that’s great! Welcome aboard Fitz :) -Vincent
On 23 Apr 2016, at 09:40, Marius Dumitru Florea <[email protected]> wrote:
Hi Fitz,
Welcome to the community! Have fun!
Thanks, Marius
On Sat, Apr 23, 2016 at 12:10 AM, Eduard Moraru <[email protected]> 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&requestId=10... [15] http://dev.xwiki.org/xwiki/bin/view/Drafts/
Hi Our dear Community, Thank you all so much for encouraging me ! I will continue to work hard. :) Thanks, Fitz 2016-04-25 15:06 GMT+08:00 Vincent Massol <[email protected]>:
Yes that’s great! Welcome aboard Fitz :) -Vincent
On 23 Apr 2016, at 09:40, Marius Dumitru Florea < [email protected]> wrote:
Hi Fitz,
Welcome to the community! Have fun!
Thanks, Marius
On Sat, Apr 23, 2016 at 12:10 AM, Eduard Moraru <[email protected]> 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&requestId=10...
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (6)
-
Ecaterina Moraru (Valica) -
Eduard Moraru -
Fitz Lee -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol