User:DMaggot/Mentoring

KDE participates in many mentoring programs like GSoC, OPW and Season of KDE. If you would like me to mentor you for any of these programs, there are a number of things you should know, all of which are listed in this page.

Disclaimer

My thoughts do not reflect those of the KDE project. In fact, the overall experience of the students that have already participated in these mentoring programs with KDE has been very good, and we have lots of mentors, most of which are easier to work with than me. Bottom line, do not be discouraged by what you read here!

Questions

• I am very short of both time and patience. Whenever you ask me a question I will try to answer with a link to a publicly accessible resource you could have found yourself before asking. That indicates that you didn't search enough, and whenever that happens you reduce your chances of having me as a mentor for your project. Resources I will usually point you to are:
  • Floss Manuals' KDE Guide
  • The many wikis in KDE: Userbase, Techbase, Community (this is tricky because we have many wikis, I give you that)
  • Mailing list archives
  • Bug reports
  • Stack Overflow
• Try solving your build issues on IRC. While it is perfectly OK to come across build issues your first time around, your issues are most likely easy to solve provided you have the skills to follow instructions. Shooting an e-mail for every build error you have plagues mailing lists with e-mails most people will consider noise. Adding noise to mailing lists has a number of bad consequences for the community.
• When solving (build) issues, provide full information about your setup right from the start. If you ask for my help to solve a build issue, chances are we will get to a solution together at some point. Once that happens, I will look back at the whole conversation and judge whether we could have found that solution earlier had you provided more information. The longer it takes us to find a solution because of incomplete information you provided, the more you reduce your chances of having me as a mentor.

Contributions

• DO NOT expect me to review a KDE contribution hosted on GitHub. This is a personal preference, and while many other KDE developers will not care much about you forking projects on Github, I will. In fact, I will not review anything outside KDE's software infrastructure. If you need me to review code for your proposal, use the ReviewBoard. If you need a new branch or a whole new Git repository to work in your proposal, file a request for a developer account, but keep in mind I will only support that account if you have already posted to the Review Board.
• If you are new to KDE and want me to mentor an idea I have not signed up for as a mentor, you should start working on that idea well in advance before the official start of the program. If you follow the regular schedule and try to have me mentor your new idea, I will say no. As a concrete example, if you have a novel idea for GSoC, you should be working on that idea by February and trying to get me involved. If you just wait until May, I will say no.
• Code style matters. If your contributions during the mentoring program do not meet the code style of the project, they will be considered incomplete - even if the code itself works - and you will be evaluated accordingly.

Knowledge

• C++ is a difficult language, so I expect you to be able to show examples of your previous work on C++ and I will focus on that rather than what you claim to be able to do.
• I not only expect you to know the language, but also the build system and version control (generally, CMake and Git respectively), but you do not need to be an expert in any of these - that is what these mentoring programs are for.

So Who Then?

After reading all of this it may seem impossible to meet all of these requirements, so let me add an example of a candidate I would have mentored:

Sven Brauch participated in GSoC 2013 in a project titled Collaborative text editor based on KTextEditor and kde-telepathy. By the time GSoC '13 started, Sven had 2.5 years of contributions to KDevelop, another KDE project. Many of us were familiar with Sven's work on the kdev-python extension, and it was only natural to mentor him for a GSoC. Keep in mind that 2.5 years is a very long time: in fact, I would consider a candidate with just a couple of months participating in KDE to be a strong candidate for a mentoring project. And submitting code patches is not the only way to participate, I would also be willing to mentor students that have experience in bug triaging, user support, etc.