No matter what your existing knowledge is, there are always ways to further improve SDAPS. See below for some suggestions of what can be done.

Don’t hesitate to write an e-mail or drop by on IRC if you are thinking about contributing!


For real time communication you can join our IRC in #sdaps on (webchat, matrix). Please keep in mind that while IRC is a real time communication system, people may not be around or simply might not have any time to reply immediately.

In general it is a good idea to simply post your request and wait patiently until you get a reply. You can also try to come back at a different time of day as the people who can reply might be living in a different timezone.

Mailing List

If you are interested in SDAPS development or usage it is a good idea to join the mailing list. Here you can get help with issues you might be having, discuss improvements to the core software and help with further developments or documentation.


Generally donating your time to improve SDAPS would be preferred, but not everyone has the time to spare for the project. If you would like to donate money then you can do so by sending it to the lead developer Benjamin Berg via paypal.


The documentation always needs some improvements. SDAPS has quite a lot of features and not even all of them are documented on this website. Others might be mentioned, but proper documentation is missing describing the feature and the ways that it can be used. You could for example create a small example of the way that you used SDAPS. Or even start to write a fully fledged introduction to SDAPS, what it can be used for and explanations of how the different features of SDAPS can be used to achieve them. Be creative, maybe you have an idea what kind of document would have helped you to get you started more quickly.


Translation Status

For ease of translations SDAPS is hosted on If you register there you can directly modify the translations for SDAPS and they will appear in the next release.

It is likely that the language is not yet listed in weblate. If that is the case you should notify us about it and it will be added. You can open an issue or write an email to the mailinglist or directly to

Note that there are two subprojects that should be translated

  • master: This is the main part of SDAPS and is licensed under the terms of the GPL version 3 or any later version.
  • tex: These are translations for the LaTeX classes. These are licensed under the terms of the LPPL version 1.3c or any later version.

Contributing to the translations means that you release your contributions under the same terms.

Many thanks to the weblate project for developing this tool and providing it to other open source projects at no charge.

Extending/Scripting SDAPS

Maybe you want to use SDAPS in a way that it is not quite ready to handle? If you know python you can add the new feature directly into SDAPS. Or you can create some scripts to make SDAPS even easier to use.

There are some ideas on the wiki on the Future page. However, no matter what your plans are, contributions are always welcome!

Code Contribution and Bugfixes

Found an issue in SDAPS? You can report it in the issue tracker, and if you are up to the task even fix it yourself!

Google Summer of Code (2016)

Instructions for students

Students wishing to participate in Summer of Code must realise this is more than a mere formality. You will be required to produce code for SDAPS in 3 months. You will also take some resources from SDAPS developers, who will dedicate a portion of their time to mentoring you. Therefore, we’d like to have candidates who are committed to helping SDAPS.

You don’t have to be a proven developer–in fact, this whole program is meant to facilitate joining the SDAPS and other Open Source communities. However, experience in coding (in Python) is welcome.

You should start familiarising yourself with the components that you plan on working on before the start date. SDAPS developers are available on the mailing list and on IRC for help. Note that the timeline from Google reserves a lot of time for bonding periods: use those periods wisely.

General instructions

First of all, please read the GSoC FAQ. Pay special attention to the Eligibility section of the FAQ.

  • Read Google’s instructions for participating
  • Take a look at the list of ideas
  • Come up with project that you’re interested in
  • Make a small contribution
  • Write a first draft proposal and get someone to review it for you
  • Submit it using Google’s web interface

Coming up with an interesting idea is probably the most difficult part of all. It should be something interesting for SDAPS, for Open Source in general, and for you. And it also has to be something that you can realistically achieve in the time available to you.

You can optionally join the mailing list or the IRC channel, this way you can make acquaintance with developers and your potential mentor, as well as start learning the codebase. We recommend strongly doing that and we will look favourably on applications from students who have started to act like Open Source developers.

Student proposal guidelines

A project proposal is what you will be judged upon. So, as a general recommendation, write a clear proposal on what you plan to do, what your project is and what it is not, etc. Several websites now contain hints and other useful information on writing up such proposals.

SDAPS does not require a specific format or specific list of information, but here are some specific points that you should address in your application:

  • Who are you? What are you studying?
  • What exactly do you intend to do? What will not be done?
  • Why are you the right person for this task?
  • To what extent are you familiar with the software you’re proposing to work with? Have you used it? Have you read the source? Have you modified the source?
  • How many hours are you going to work on this a week? 10? 20? 30? 40?
  • Do you have other commitments that we should know about? If so, please suggest a way to compensate if it will take much time away from Summer of Code.
  • Are you comfortable working independently under a supervisor or mentor who is several thousand miles away, not to mention 12 time zones away? How will you work with your mentor to track your work? Have you worked in this style before?
  • If your native language is not English, are you comfortable working closely with a supervisor whose native language is English? What is your native language, as that may help us find a mentor who has the same native language?
  • Where do you live, and can we assign a mentor who is local to you so you can meet in a coffee shop for lunch?

After you have written your proposal, you should get it reviewed. Do not rely on the SDAPS mentors to do it for you via the web interface: they will only send back a proposal if they find it lacking. Instead, ask a colleague or a developer to do it for you.


Submit your proposal early: early submissions get more attention from developers for the simple fact that they have more time to dedicate to reading them. The more people see it, the more it’ll get known. Do not leave it all to the last minute: while it is Google that is operating the webserver, it would be wise to expect a last-minute overload on the server. So, make sure you send your application before the final rush. Also, note that the applications submitted very late will get the least attention from mentors, so you may get a low vote because of that. Keep it simple: we don’t need a 10-page essay on the project and on you (Google won’t even let you submit a text that long). You just need to be concise and precise.

Know what you are talking about: the last thing we need is for students to submit ideas that cannot be accomplished realistically or ideas that aren’t even remotely related to SDAPS. If your idea is unusual, be sure to explain why you think it is a good improvement to SDAPS.

Aim wide: submit more than one proposal. We also recommend submitting to more than one organisation too. This will increase your chances of being chosen.

License: This chapter is licensed under the Creative Commons License SA 4.0 and is based on the KDE application instructions because they’re pretty epic.

Project Ideas

Handwriting Recognition

Mentors: Benjamin Berg (SDAPS, integration), Jeremie/Adam? (recognition, neural networks) In recent years there have been great improvements in deep learning and neural networks. With these new developments and emergence of multiple frameworks to develop deep learning software it is possible to tackle the issue if handwriting recognition from paper forms in new and exciting ways. Previous attempts were focused on simpler frameworks like Gamera (see issue 15). In this project we would like to move beyond frameworks like Gamera and instead use neural networks in conjunction with deep learning to solve the issue. With this technology a larger neural network should be able to first find the characters in the input image and then output the plain text belonging to the whole image. The project is split into two parts which are equally important,

  1. research deep learning frameworks and build a working handwriting recognition and #. integration into the core of SDAPS.

Because of scope of the project it would be of advantage if a student applying can demonstrate some basic knowledge about machine learning and or hands on development of free/python based software.

Web fronted for SDAPS

Mentors: Benjamin Berg For a quite a while now a basic [web fronted for SDAPS] ( does exist (demo the demo is quite often down due to bugs, ping on IRC if it is and you want to try it), however this never got past the proof of concept state.

The goal of this project is to create a usable web fronted for SDAPS. As such it will require working on both the new web frontend and the core of SDAPS (for example SQLite based storage).