Projects/Promo/Happy newbies: Difference between revisions

    From KDE TechBase
    (We'll start with an excerpt from mpyne's People of KDE interview)
     
    (things that come to mind)
    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?=
    #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.
    (---mpyne)


    (mpyne)
    * patches --- who to submit them to so they get read and not lost 
    ** i.e. bugzilla vs. mailing lists. which?
    * 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!)
    ** I have no clue.
    * lists of things that are newbie friendly that need help
    ** kopete needs developers, and mattr has a list of jobs, according to the topic of #kopete
    ** 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)
    ** look in bugzilla for easy bugs to fix, good for things like #khtml perhaps
    Bugzilla has JJ, junior jobs.
    * join the community, mailing lists, irc, etc.

    Revision as of 01:49, 25 February 2009

    What's your advice to people who want to get into KDE development-type stuff but don't know where to start?

    1. 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.
    2. 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.
    3. Learn Qt first.
    4. 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.

    (---mpyne)

    • patches --- who to submit them to so they get read and not lost
      • i.e. bugzilla vs. mailing lists. which?
    • 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!)
      • I have no clue.
    • lists of things that are newbie friendly that need help
      • kopete needs developers, and mattr has a list of jobs, according to the topic of #kopete
      • 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)
      • look in bugzilla for easy bugs to fix, good for things like #khtml perhaps

    Bugzilla has JJ, junior jobs.

    • join the community, mailing lists, irc, etc.