Projects/Promo/Happy newbies: Difference between revisions
No edit summary |
No edit summary |
||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
=What's your advice to people who want to get into KDE development-type stuff but don't know where to start?= | =What's your advice to people who want to get into KDE development-type stuff but don't know where to start?= | ||
(from mpyne's People of KDE interview) | |||
#Figure out if you want to "develop-develop" or if you would be better at non-coding but still important types of tasks. I got my start in KDE doing documentation even though I knew coding at the time. When I decided I wanted to help with JuK the first thing I did was fix the documentation as much as I could, which helped me learn the codebase, that proved useful too. | #Figure out if you want to "develop-develop" or if you would be better at non-coding but still important types of tasks. I got my start in KDE doing documentation even though I knew coding at the time. When I decided I wanted to help with JuK the first thing I did was fix the documentation as much as I could, which helped me learn the codebase, that proved useful too. | ||
#If you do plan to do coding and you don't know programming, start learning now. You can learn KDE and programming in parallel but you can't start on C++ (or Python, etc.) too soon. | #If you do plan to do coding and you don't know programming, start learning now. You can learn KDE and programming in parallel but you can't start on C++ (or Python, etc.) too soon. | ||
#Learn Qt first. | #Learn Qt first. | ||
#Finally, absorb information. :) You can do this by lurking on mailing lists, by hanging out in IRC development channels, and by reading TechBase. You'll find out there's more you need to know than just programming, but many skills will translate well even to non-programming tasks so it doesn't hurt to learn. | #Finally, absorb information. :) You can do this by lurking on mailing lists, by hanging out in IRC development channels, and by reading TechBase. You'll find out there's more you need to know than just programming, but many skills will translate well even to non-programming tasks so it doesn't hurt to learn. | ||
=How to pick a project= | =How to pick a project= | ||
| Line 20: | Line 22: | ||
=Specifics= | =Specifics= | ||
* patches --- who to submit them to so they get read and not lost | * patches --- who to submit them to so they get read and not lost | ||
** | ** if something uses review board, use that, otherwise mailing lists tend to be better than bugzilla | ||
* coding style | * coding style | ||
** Some projects have explicit documentation. Others, just follow the style the maintainer is using. Above all, read the stuff on techbase about general KDE style. | ** Some projects have explicit documentation. Others, just follow the style the maintainer is using. Above all, read the stuff on techbase about general KDE style. | ||
* what to be shy about and not to be shy about (important!) | * what to be shy about and not to be shy about (important!) | ||
** | ** ??? | ||
=lists of things that are newbie friendly that need help= | |||
** kopete | * Projects with intro to do lists | ||
** look in bugzilla wishlists, and look for something neat, ask somebody more senior if that is a good thing to work on (animating the tab icon while the tab is loading seems like a popular thing) | ** kopete: mattr has a list of jobs, see #kopete | ||
** look in bugzilla for easy bugs to fix | ** pim is on #kontact http://techbase.kde.org/Projects/PIM/KMail_Junior_Jobs | ||
* look in bugzilla wishlists, and look for something neat, ask somebody more senior (try irc) if that is a good thing to work on (animating the tab icon while the tab is loading seems like a popular thing) | |||
Bugzilla has JJ, junior jobs. | * look in old suggested summer of code projects, some may still be valid | ||
* look in bugzilla for easy bugs to fix | |||
* For things like khtml, go to #khtml and you are likely to get a tutorial of the codebase, layers, etc. Easy fixes, but you need some guidance. | |||
* Bugzilla has JJ, junior jobs. | |||
* join the community, mailing lists, irc, etc. | * join the community, mailing lists, irc, etc. | ||
Latest revision as of 12:07, 18 July 2012
What's your advice to people who want to get into KDE development-type stuff but don't know where to start?
(from mpyne's People of KDE interview)
- Figure out if you want to "develop-develop" or if you would be better at non-coding but still important types of tasks. I got my start in KDE doing documentation even though I knew coding at the time. When I decided I wanted to help with JuK the first thing I did was fix the documentation as much as I could, which helped me learn the codebase, that proved useful too.
- If you do plan to do coding and you don't know programming, start learning now. You can learn KDE and programming in parallel but you can't start on C++ (or Python, etc.) too soon.
- Learn Qt first.
- Finally, absorb information. :) You can do this by lurking on mailing lists, by hanging out in IRC development channels, and by reading TechBase. You'll find out there's more you need to know than just programming, but many skills will translate well even to non-programming tasks so it doesn't hurt to learn.
How to pick a project
- What app do you use most? Enjoy? Are curious about?
- Not sure? Join BugSquad. :) #kde-bugs
Culture
"Have a thick skin."
- You will find a huge variety of cultures in our community, that means you might come across people that seem quiet, distant or even offensive at times. Remember that in any culture, geeks tend not to have the best social skills.
- Keep trying, even if somebody tells you your contribution is not useful; it will help you improve your skills and you will gain more experience from it.
- Remember, most of us have day jobs so don't shy away if you don't get an answer quickly.
- If you can't find somebody in our community that speaks your language, try getting other people near your area interested in KDE so you can all work together and support each other.
- In general, newbies can and will be nervous. That is ok. If someone seems to be mean to you, don't take it personally. It is only one person in the project, and they may not actually intend to be mean. It might just be their personality, and they might act like that towards everyone. Maybe you misunderstand them. (...how to encourage to ask someone else for a second opinion on personal/social matters?)
Specifics
- patches --- who to submit them to so they get read and not lost
- if something uses review board, use that, otherwise mailing lists tend to be better than bugzilla
- coding style
- Some projects have explicit documentation. Others, just follow the style the maintainer is using. Above all, read the stuff on techbase about general KDE style.
- what to be shy about and not to be shy about (important!)
- ???
lists of things that are newbie friendly that need help
- Projects with intro to do lists
- kopete: mattr has a list of jobs, see #kopete
- pim is on #kontact http://techbase.kde.org/Projects/PIM/KMail_Junior_Jobs
- look in bugzilla wishlists, and look for something neat, ask somebody more senior (try irc) if that is a good thing to work on (animating the tab icon while the tab is loading seems like a popular thing)
- look in old suggested summer of code projects, some may still be valid
- look in bugzilla for easy bugs to fix
- For things like khtml, go to #khtml and you are likely to get a tutorial of the codebase, layers, etc. Easy fixes, but you need some guidance.
- Bugzilla has JJ, junior jobs.
- join the community, mailing lists, irc, etc.