Hi Eric! On Monday, 2011-07-11, Eric wrote: > My problem is this though... I don't know what to do with this new > found knowledge of these languages. I just don't know > what to do with it, I don't have any problems that need to be solved > and unfortunately I don't really see myself as familiar enough with the > languages (except MAYBE c++) to start trying to help everyone here at KDE > or even Gnome. I think it is true that it got a lot more difficult to find things to start to work on then it used to be "in the old days". Back then the ecosystem lacked a lot of applications for common tasks or the existing once had an obvious lack of certain functionality. However, I think it is important not to look for something not yet existing when trying to find a problem to solve, but maybe look at things that could be optimized instead. A lot of programs we use every day are improvements over programs that came before, just automating things better or providing certain workflows in a more integrated way. For example lets have a look at the topic of digital photo management. Initially all things were done manually, e.g. loading images from the camera onto the computer, putting them into a meaningful structured storage (e.g. folder named after the location or event where the photos were taken, etc). While all aspects of the common workflows were available already, it made sense to combine certain tasks into single applications to make them more integrated and more automated. Hence several dozends of image managment apps. Now one could reasonably thing that all needs were now covered, however the situation changed slightly and online image galleries/sharing platforms became popular. Again uploading to these could be done already, they are all web sites so uploading can be done with the web browser. However it made sense to make this more comfortable by adding uploading functionality to the image managment programs. Basically all programmers I know personally, including myself [1], have started with something that automated one of their personal tasks better than any solution available at that point. > I'll sometimes be roaming linuxhomepage.com / lxer / > phoronix and see some new patch mentioned, and out of curiosity I'll click > on it and read it, and > I have to say.. alot of the time it looks like gibberish to me. Even > with comments, > I can't make sense of it. Perhaps im simply unlucky and choosing the > more... low-level > patchs to look at, but I got to say, its rather disheartening when I > can't even make sense > of what is going on. A patch is often only understandable in the context it applies to, unless it is a really huge patch which "includes" the context (like all code for a completely new feature). This is even true for developers working on the respective code, which is why there are a lot of tools that let one look at a patch as part of the code it applies to, i.e. merged with the original code but somehow highlighted to see its boundaries. > I know this isn't strictly limited to KDE but I'm sure that my situation is > hardly new to programmer's the world over. > > Any feedback is much appreciated! Aside from doing something that is just fun and does not necessarily solve anything of wide spread importance, one way is to look for items specifically targeted at people who are not yet familiar with a certain code base. In KDE we refer to those task items as junior jobs (junior not in the sense of a younger or less experienced person but in the sense of complimentary to senior in the sense of knowing a lot of details about assumptions or hidden traps in our sometimes dauntingly huge code bases). Junior jobs can sometimes be found on techbase.kde.org or as items marked as such on bugs.kde.org (not necessarily bug fixes but also user wishes or suggested improvements). Aside from our "JJs" there are two common areas of interest where new people start contributing to: games and edu. Games because they are fun (to play and testing your new code means you will "have" to play a lot) and Edu because a lot of people who start contributing are either still in (high) school or (like yourself) have just graduated and can thus relate a lot to the topics at hand (and might know about features of contemporary teaching software which might not yet be available in free software equivalents). I can basically guarantee that there is no sub project in KDE that will reject newcomers just because they are unexperienced. Some groups even have (semi-) official mentors to make the initial steps into contributing more comfortable (e.g. not having to ask question on a mailinglist but being able to contact the mentor privately). Cheers, Kevin [1] I distincly remember an application I spent weeks on coding (as in several hours a day, during holidays) while in high school which's whole purpose was to automate drawing hexagons connected to each other. The "problem" I was "solving" had been this: I had read an article about human habitats on other planets or moons would be more viable if constructed of interconnected modules that fit nicely together to form an extensible structure. Now the best possible base shape for that is a hexagon, since they can be joined tp cover any area without leaving any holes and six corners provide a better structural stability than four corners (and squares are lame :)). Drawing a lot of connected hexagons can be automated a lot even when doing it on paper (basically use a triangular grid), but that still got old pretty fast. Hence the need to a software to do that. In the end I had a program that was doing something I had no real need for, nobody else would ever have a need for, but I had learned a lot about computer graphics :) -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
Attachment:
signature.asc
Description: This is a digitally signed message part.
___________________________________________________ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.