User:DMaggot/Mentoring: Difference between revisions
(Adding initial version, I still have to check the wording) |
(Adding notes about knowledge) |
||
| Line 17: | Line 17: | ||
* 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. | * 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. | * '''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 === | |||
* '''I am assuming you do not know C++''' - or at least not under my standards. But don't worry, I myself do not know C++ under my own standards. So if you apply saying you know C++ (and especially if you say you know C++ and half a dozen other languages) that does not tell me anything about your knowledge of C++. If the project you are applying to requires knowledge of C++, the only things that will matter are patches for the project, or C++ code hosted publicly. Keep in mind [http://lbrandy.com/blog/2010/03/never-trust-a-programmer-who-says-he-knows-c/ C++ is a difficult language] so don't worry about meeting my standards or feeling you have much to learn, we all 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. | |||
Revision as of 18:30, 12 February 2014
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
- I am assuming you do not know C++ - or at least not under my standards. But don't worry, I myself do not know C++ under my own standards. So if you apply saying you know C++ (and especially if you say you know C++ and half a dozen other languages) that does not tell me anything about your knowledge of C++. If the project you are applying to requires knowledge of C++, the only things that will matter are patches for the project, or C++ code hosted publicly. Keep in mind C++ is a difficult language so don't worry about meeting my standards or feeling you have much to learn, we all 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.