XWiki Guidelines for GSOC

Last modified by Simon Urli on 2023/10/10 12:05

Getting started with the XWiki community

The general starting point for anyone new to the XWiki community and interested in helping out would be the page on Contributing.

It can be a bit overwhelming at first when going through all the online documentation for developers available at http://dev.xwiki.org

It also matters what type of project you are planning to do. Usually, you don't need to know how to build XWiki itself. What is more important is to understand how to build applications/extensions on top of XWiki. For that, make sure to check out the guide on Getting started with XWiki for extension developers.

Of course, for any specific questions feel free to ask.

To learn about how XWiki is developed (tools, practices, SCM organization, etc), check the dev wiki.

For understanding how XWiki works, check the Architecture.

Increasing your chances of being accepted

  • Properly introduce yourself to the community (forum and/or chat). After that, you should be active throughout the application period, using the time to better understand the project, its requirements, helping you to better write your proposal. It's very unlikely that you will understand all the details of the project just by reading its description and not clarifying the project's details before you submit your application is a red flag for problems in communication which highly decreases your chances of being selected.
  • Before the contributor application period completes, if you're planning to or applying at XWiki, you must show us that you are able to code. You have 2 options here:
    • Some proposed projects contain a list of tasks in their description. These tasks serve as a starting point for understanding and implementing the actual project, so any candidate applying must first prove (as part of their application) that they have completed these basic steps in order to be considered as potential candidates.
    • Each GSoC candidate applying may pick (in addition to the project tasks or in case the project does not feature any tasks) one or several existing JIRA issues and send pull requests with the fixes that need to get reviewed and accepted before the application deadline is up. It can be anything (bug fixes or improvements) but it needs to be of a moderate complexity, so either one more complex issue or a mix of several less complex ones.
    • NOTE: Applications without any completed relevant tasks (if any were available for the project) and with no accepted pull requests will have a very low chance of being selected.
  • Make the proposal as detailed and thought-out as possible. Show us that you understand your project, what needs to be done and what you plan to do about it (including a timeline with milestones that you plan to follow). A candidate who writes a proposal with a few lines that are just a rewrite or the project description from the proposal list won't get good points.

Suggested way of working for accepted GSoC Contributors

First and foremost, working on XWiki needs to be fun and a good learning process! However, the XWiki project is already following some development rules that we're asking GSoC Candidates to follow too. This is for the good of the XWiki project but more importantly it's a good way to learn how an open source community works. Also, if these practices are followed, it will be much easier to integrate the resulting work into XWiki's official releases.

So here are some practices we'd like GSoC Contributors to follow (please comment on the forum (dev category) if you'd like to change some of them or propose other things):

  • GSoC Contributors have time allocated to familiarize with the XWiki community and development process. As such, we require that each GSoC Contributor continues fixing existing JIRA issues and creating Pull Requests during the Community Bonding Period (always check the timeline). This is a critical integration step to ensure all GSoC students understand how XWiki works, how to ask questions and to communicate properly with the community and, ultimately, get to know each other.
  • GSoC Contributors should be considered like any other XWiki contributor which means they should respect the same Community rules as the Committers on XWiki core. Note that a GSoC Contributor can become a Committer in the same manner any other XWiki contributor can become one. For example this means:
    • using the XWiki coding conventions;
    • using the defined communication channels: Matrix and forum;
    • producing at least 1 commit per week (the more, the better), starting with the 1st week of the Coding Period. Nobody wants to see or review a code dump after 1 month of work. Ideally, a GSoC Contributor should commit once per day, any small progress or change. If you want to impress us, getting to multiple (relevant, of course) commits per day can do the job.
    • etc.
  • GSoC Contributors should post a quick introduction on the forum (dev category) to explain who they are and what they're going to work on.
  • GSoC Contributors must periodically update their progress report for the project they have been assigned to.
  • GSoC Contributors should create a Design page where they document technical aspects of the feature they are working on: architecture, use cases, problems, various solutions with pros and cons, etc. This page should be written as an XWiki community member and not a GSoC Contributors (there is the progress report for that), ensuring that the page will remain relevant even after the GSoC period end.
  • GSoC Contributors should always go to the forum (dev category) when communicating about their project. They must resist the temptation of talking directly to their mentors. Instead, they must use the public XWiki Matrix channel if they need to talk to them. The goal is that everyone in the XWiki community helps them, answers their questions but also knows what they are doing. This will make the integration of their work back into XWiki easier later on. This is very important and a criteria of success for the Contributors. This is about learning how open source works... Note that GSoC Contributors can also mention their mentors in the forum if they want, to get their attention.
  • GSoC Contributors should not block on anything for a long period of time (i.e. more than a couple of days). They should ask plenty of questions on the forum ("Discuss" category for questions about using XWiki and "Dev" category for questions about GSOC development) but not without putting in some effort to figure it out by themselves first. There is a balance between being autonomous and asking too many questions. Understanding how this works is also part of both the Community Bonding and the entire GSoC experience as well.
  • GSoC Contributors should be in contact with the community as much as possible, following the forum (and answering questions, when they know what to say), stay on the Matrix channel, give regular status updates on their project. This does not mean that a GSoC Contributors are not allowed to take a break, of course, but that, while working, a GSoC Contributor should be integrated as much as possible with the community.
  • When taking a vacation/break, GSoC Contributors have to notify the mentor(s); a mysterious disappearance could lead to a negative feedback afterwards or even being failed.
  • GSoC Contributors will request and be given access to Contrib, where they'll create their project (a repository inside xwiki-contrib) during the Community Bonding period, when they learn the community and process, and when they set up their tools. They must start pushing commits from the first week of the Coding Period.
    • For projects which need to modify some existing code, JIRA issues will need to be created and Pull Requests to be used. It's important that Pull Requests be of good quality and small in order to be evaluated and applied quickly. Once a project reaches a good level of maturity (meaning it works and the code is of good quality, documented, etc.) we could even include them in an XWiki flavor (even the main XWiki flavor if applicable).
    • At the very least, the project will be published and available as an extension published on extensions.xwiki.org and will be installable by anyone having an XWiki instance.
  • After creating their repository, the should proceed to create a build capable to producing the built artifact of their project. Generally, this means producing an XWiki extension (XAR and/or JAR). Only after the minimal (empty) build is created, should they proceed to adding functionality/code that builds their project. Approaching the project in this order ensures that you have something buildable and testable at every step of the program. Leaving the packaging and build as the last step before an evaluation is considered a failure on the planning and technical communication aspects.
  • Before each coding period ends, each GSoC Contributor must release a functioning, easily installable and testable version of their work so far. It is perfectly fine that the entire project is not yet complete (nobody expects that until the final evaluation), but any mentor, org admin or even regular curious member of the community needs to be able to easily obtain, install and test the work done so far by the GSoC Contributor. Things can break, placeholders/stubs can be used to fill in features that will be developed in the next coding period, but an evaluator should be able to see something that works partially (for an UI project) or somehow interact with the partial work (for backend projects). In the Software Development world, we work in iterations and GSoC Contributors need to be able to do the same. Failure to release before the evaluation deadline can severily impact the GSoC Contributor's chances of progressing to the next step of the program.

Remember that this is not a summer job, or a Rent-a-coder like project, but a rewarded successful integration in an free software/open source community. If all you are interested in is the money, then better look for a real job, as Free Software requires passionate people; an ideal candidate is more interested in the t-shirt.

Good generic advices:

Conditions for success

GSoC Contributors will need to meet these criteria for success:

  1. Must have something that works and is in some finished state
  2. Must be integrated or close to be integrated in XWiki without too much effort
  3. Must have interacted correctly and continuously with the community
  4. The work must have been enough. It's supposed to be either a 175 hours or 350 hours effort, depending on the project size, and spanning over time period agreed with the mentor somewhere between 12-22 weeks.

Note that the real important part is 3) since this is a criteria for success for 1), 2) and 4).

Tags:
   

Get Connected