Google Code-In began today, November 26th 2012, precisely at 17:00 UTC.
The KDE Community is proud to take part once again in this great program. Find out more about Google Code-In and the other accepted organizations in the announcement.
On the KDE side, tasks have been collected, mentors are signed up, and we are ready to go!
For any question or problem mentors and students are welcome to ask in #kde-soc on irc.freenode.net.
Good luck and most importantly, have fun!
Google Code-in is in some ways the pre-university counterpart of Google Summer of Code, and KDE has has been a very successful mentoring organization since its first edition in 2010. Needless to say, we are applying to be a mentoring organization again this year.
If you are a prospective Code-in student, stay tuned – mentoring organizations have not been selected so we have no news for you yet. If we get accepted, we’ll be delighted to mentor you.
If you are a prospective Code-in mentor, please read on
The KDE student programs team has already applied on behalf of KDE, but to be successful we now need to add as many tasks as we can think of to the Google Code-in 2012 Ideas page in the KDE community wiki.
Most importantly, please only add tasks you are willing and available to mentor. Mentoring Google Code-in students is a very rewarding activity, but it takes a fair bit of patience and dedication.
A few things to keep in mind.
- Google Code-in is not just about code. We also need other tasks (likely even more than coding tasks).
- We need at least 5 tasks in each category to qualify.
- A task should take a normal KDE contributor about 2 hours. This is a guideline for you, to give you some idea of how much work a task should be. The actual time needed for students to complete a task can vary greatly. If you have doubts/questions feel free to ask the student programs team (teo- or Nightrose on #kde-soc).
- Unlike the previous years, there are no translation tasks.
- There is no distinction between easy/normal/hard tasks – while difficulty will of course vary between tasks, all tasks are treated the same.
- The mentoring organization gets to choose 2 grand-prize winners among our best students. This means students are much more likely to stick with one org throughout the Code-in season than in previous editions.
- The students don’t get money for each task. They get a Code-in t-shirt after clearing at least three tasks, and they compete for the grand prizes.
- Google expects a turnaround time on tasks of less than 36 hours, but we should try to get to less than 24 hours if at all possible.
- Check the timeline. If you are not available to approve and review tasks for some of that time please add that to the task description.
Our tasks list must be finished by November 5th, but please submit your tasks as early as possible.
Last weekend, after countless emails and weeks of digging through a huge Google spreadsheet, I have finalized Season of KDE selections. The KDE student programs team is confident that we have made the best possible choices and matched as many students as possible with competent mentors.
KDE student programs by the numbers
Congratulations and a big welcome to all the students who have been accepted for Season of KDE 2012!
This year we had almost 70 applicants. We found a mentor for 29 of them, and they will spend their summer hacking on KDE. Unfortunately, mentor availability was tight, so we had to say no to quite a few excellent submissions.
I’m not complaining though, this year KDE got more Google Summer of Code students than ever before, and more Season of KDE students than ever before (total headcount: 89). It’s going to be an awesome summer!
Help wanted: web application developers and artists
It is clear that KDE student programs as a whole are growing, and we have reached the point where a single Google spreadsheet as a tool for all administrative tasks concerning Season of KDE simply does not scale. The sheer amount of submissions (and therefore, data), combined with the size of the KDE community (and therefore, mentors to contact) has resulted in the Season of KDE 2012 selection period taking more than a month!
The current “spreadsheet+bunch of emails” workflow is definitely unsustainable, and the KDE student programs team agrees that a web application like Melange would help tremendously in managing Season of KDE more efficiently. Melange would probably be overkill though, and we have not managed to find any existing solution that would fit our requirements. Those requirements are quite simple: a web application with simple CRUD database operations that would allow the following:
- 3 categories of users, students, mentors and administrators can sign up, ideally through identity.kde.org;
- students can submit one or more applications for a currently active student program (e.g. Season of KDE);
- mentors can view submissions and declare their will to mentor one or more students;
- administrators can assign student-mentor matches, manage deadlines and properties of a student (active/inactive, shirt sent/not sent, etc.);
- mentors can pass or fail students with a simple yes/no switch (no need for questionnaires like in Melange).
Lydia Pintscher has drawn up a nice representation of the workflow we would like to have:
Sayak Banerjee has already started working on it, so we are hoping it could be ready for next year’s Season of KDE. If you wish to help, feel free to contact sayakb on #kde-www on Freenode.
We could also use a nice logo for Season of KDE, if you have drawing skills and would like to help contact the KDE student programs team at firstname.lastname@example.org.
The UNIX terminal UI has stood the test of time. Tools change, new tools crop up, certain tools are used commonly and others less so. I don’t see the familiar UNIX terminal concept becoming obsolete any time soon. The extensibility and sheer power that comes with it is the best thing since sliced bread.
Now, I like colors and pretty pictures. More specifically, I find it much easier to recognize a piece of information if it is colored in a meaningful way, this is the whole reasoning behind syntax highlighting in IDEs. Luckily some other people like colors and pretty pictures too, and with the power of Free Software they have come up with various ways to add some color to common UNIX-compatible shell tools.
Some of these are just wrapper scripts for existing tools, and some are entire rewrites with lots of added functionality. Some distributions already provide a somewhat colored environment. Some of them contribute to making my shell a much more colorful place.
cw is a color wrapper for common UNIX commands. According to the project’s website, “it is designed to simulate the environment of the commands being executed, so that if a person types ‘du’, ‘df’, ‘ping’, etc. in their shell it will automatically color the output in real-time according to a definition file containing the color format desired.”
cw wrapper scripts do not modify the functionality of the tools involved, they just add colors, so they are a good choice even if you alias some of them to other, more sophisticated tools. Some of the added colors are just eye candy, and some of them are actually very useful.
htop is an interactive process viewer for Linux. It is not just a wrapper for top, this is a completely rewritten and much more featureful program. I alias it in my .bashrc in place of top.
I have tried at least three colored replacements and/or wrappers for df, and dfc is the one I like best. I keep it aliased in place of df.
cdu stands for “color du” and it is a Perl wrapper for du. I keep it aliased in place of du.
ls++ is a tool I’m currently still testing. It is a wrapper for plain old ls, it uses common color schemes for file types (as used by the –color parameter of GNU ls) and mangles the output a bit to make it more relevant. I like how it shows permissions and dates.
For many prominent toolchain elements there is a colorized variant or wrapper, such as colordiff, colorgcc, colorsvn, colormake and others. Some of them actually already produce very good colored output with the right options (without wrappers), like grep or tree, and are easily aliased in .bashrc to always show colored output.
Combine all that with a nice LS_COLORS in .bashrc courtesy of dircolors and a nice colored prompt and your shell will make you puke rainbows in no time
Lastly, as a bit of bonus content for Archlinux users I’d like to mention pacman-color and yaourt, they make pacman so awesome it’s not even funny.
I have put together a checklist of tasks and suggestions I advise you to follow during the community bonding phase. While you are not required to code until May 21 (end of the community bonding period), you are expected to get ready and be in good standing with your community. By now I suppose you have already contacted your mentor.
What follows also applies to Season of KDE students.
(1) Join the relevant communication channels.
KDE contributors do not just silently churn out code, they like to hang out a lot, exchange ideas and opinions. But since KDE pretty huge, different subprojects have their own communication channels. You should definitely join your subproject’s development mailing list (e.g. email@example.com for Amarok, firstname.lastname@example.org for digiKam, etc.) as an absolute minimum. I also strongly advise you to join your subproject’s IRC channel on irc.freenode.net, as many development discussions happen there (e.g. #kdevelop for KDevelop, #plasma for Plasma, etc.). You should also join #kde-devel and #kde-soc on irc.freenode.net. Your mentor will instruct you if there are other communication channels you should be aware of.
(2) Get acquainted with KDE’s infrastructure.
You should get a KDE Identity account and fill out your profile. This account works with most of the services provided by KDE, such as review board, wikis (Community and Techbase) and forums. You need to sign up separately for KDE’s issue tracker. You must then also apply for a contributor account to be able to commit code, please follow these instructions to do so.
(3) Get ready to blog.
Writing a blog is a great way to introduce yourself to the community and keep everybody informed on your progress. If you do not have a blog yet, consider starting one and having it aggregated on Planet KDE. I personally recommend WordPress which is also Free Software but you can use whatever platform you like. It is not mandatory but I think it’s a nice way to motivate yourself and bond with the community. Do not feel pressured to do it, but a few articles when you reach certain milestones in your project could be very nice.
(4) Learn the ways of the community.
Free Software communities work in certain specific ways which are sometimes very different from what a new Google Summer of Code student might be used to. To help you get up to speed quickly, Donnie Berkholz, Lydia Pintscher and Kevin Smith, Google Summer of Code administrators for Gentoo & X.Org, KDE and XMPP Standards Foundation respectively put together a very good article on the DOs and DON’Ts of Google Summer of Code for students. If you are new to KDE I consider this article a required reading assignment before starting your work. It is short, easy to read and to the point, and every word of it applies to your situation as Google Summer of Code students at KDE. For more information on getting involved with KDE specifically, I highly recommend the Free manual KDE Dev Guide, a step by step introduction to KDE for new contributors. A much more complete resource on getting involved with Free Software is Open Advice, a Free knowledge collection from a variety of prominent Free Software contributors.
(5) Talk it through.
You are not required to code for almost a month until the coding period begins, but work on your project starts now. Plan ahead. Do analysis and design. Make sure that if there’s any potential obstacle in your project, it comes up as soon as possible. Set aside a few hours and schedule meetings with your mentor to discuss the fine details of your project and iron out the kinks. It’s best if such discussions are held in the subproject’s IRC channel to allow all the interested parties in the community to contribute. Be ready to submit regular updates to your mentor once you start coding. KDE Google Summer of Code administrators strongly recommend weekly updates to the subproject’s development mailing list, but the exact way you do this is up to your mentor.
This year KDE has accepted 60 Google Summer of Code students. We are happy with this number, it is more than last year, and I’m sure these 60 students will make a great contribution to KDE as a whole.
But this number is still a hard limit: we had to say no to many brilliant proposals. The selection process has not been easy, and we had to make a lot of tough choices. KDE definitely has the mentoring capacity for more than 60 students at a time. So while we cannot come up with more Google Summer of Code slots, we can still make our mentors available through a similar scheme: Season of KDE.
What is Season of KDE?
Season of KDE is a community outreach program, much like Google Summer of Code, hosted by the KDE community. It is meant for people who could not get into Google Summer of Code for various reasons, or people who simply prefer a differently structured, somewhat less constrained program. Season of KDE is managed by the same team of admins and mentors that take care of Google Summer of Code and Google Code-in matters for KDE, with the same level of quality and care.
Who can take part?
Everyone can apply for Season of KDE. We give preference to those who have applied for Google Summer of Code and to students, but we will gladly consider applications from anyone.
What do I get out of this?
A great summer working on a really cool KDE project and gaining valuable experience. If you complete your project successfully you also get a T-shirt, a certificate, and maybe a few other goodies.
How do I apply?
If you are serious about it and have already contacted the relevant KDE subproject to discuss your proposal, fill out the Season of KDE application form and we will get back to you.
What is the timeline?
The timeline is up to you and your mentor. We advise you to stay as close to the Google Summer of Code timeline as possible. The only hard constraint is the application deadline: you apply through the application form before May 7, 2012 at 19:00 UTC in order to be eligible for participation.
Do I need to have a mentor before applying?
It is preferred. Ideally, you should contact a KDE subproject well before applying, ask for feedback on your idea if you have one, and request a mentor directly. A list of KDE subproject contacts is available on the Google Summer of Code 2012 ideas page. You can also apply without a mentor and we will try to find one for you.
Do I need to have a project idea before applying?
It is preferred. If you do not have one we will try to find one for you. Keep in mind that the KDE community is pretty big, so you should at least have an idea of which KDE subproject you wish to work on.
Do I need to write a proposal like in Google Summer of Code?
No, but we would like to see a brief project plan describing what you will be working on.
Is it only for coders like Google Summer of Code?
We are willing to consider non-coding projects as well, but you should definitely get in touch to figure out the details beforehand. The KDE Community Wiki describes ways to get involved with KDE that do not require coding.
I applied for a project in Google Summer of Code but another student got selected for it. Can I still work on it?
Maybe, but likely not. You should ask the mentor that was assigned to your idea. We can try to find something related for you if you want, or something completely different. Let us know what you wish and we will do our best to accommodate your request.
Is this an extension of Google Summer of Code or connected to Google?
No. While Season of KDE is in many ways modeled after Google Summer of Code and administered by the same members of the KDE community, it is completely independent from Google Summer of Code and has no connection to Google whatsoever.
For further questions feel free to join our IRC channel #kde-soc on Freenode or email the admin team at email@example.com.
In the past four years we had in order 1, 4, 8 and 20 successful Season of KDE students. We like to think this says something about how welcoming, helpful and fun the KDE community is. Our goal for this year is at least 30
Are you going to be one of them? You should be!
Google has just published the list of student proposals that have been accepted for Google Summer of Code 2012.
This year KDE received more than 200 proposals. 192 of those are valid and have not been withdrawn. The general quality level is very high, and most of those 192 proposals are very good. Google has allocated 60 student slots to KDE, which means that this year we are able to accept 60 Google Summer of Code students. The trouble is that we got a lot more than 60 good proposals! During the past few weeks the GSoC admins and mentors of KDE had to make some really tough choices.
If you are a student, you should have received a notification about the state of your proposals via email. Either way, you can check the status of your proposals on Google Melange.
Accepted into Google Summer of Code?
Has your proposal been accepted by an organization? Congratulations!
Has your proposal been accepted by none other than KDE? Awesome! This means that you will be spending your summer hacking with us. On behalf of the KDE community, I wish you a warm welcome! The selection process was hard and competitive, but if your proposal has been accepted it already means that we think you are the very best. Feel free to brag about it a bit, you’ve earned it!
I will write another blog article shortly on the next steps for accepted Google Summer of Code students.
Not accepted into Google Summer of Code?
If on the other hand your proposal has not been accepted, you are still very welcome to hack on KDE! Note that I never used the word “rejected” because I do not consider a proposal that has not be accepted for Google Summer of Code as something that’s unwelcome or unworthy for KDE. Many factors come into play in proposal selection which do not depend on the skill set of a student, including slot availability and mentor availability. We had to say no to quite a few brilliant proposals.
For those students whose proposals have not been accepted for Google Summer of Code who still wish to contribute to KDE in a guided, mentored way this summer, KDE hosts the Season of KDE program. Season of KDE is much like Google Summer of Code: while the student doesn’t get paid, he does get a mentor and a T-shirt, and he gets to hack on KDE for the summer and beyond. My first summer with KDE was as a Season of KDE student, and it was a very rewarding and enlightening experience. Season of KDE will be officially announced shortly, stay tuned
Some other organizations also host programs similar to Season of KDE for students who did not find a place in Google Summer of Code or simply prefer a differently structured program. Such programs include Haiku Code Drive (not confirmed yet for this year), illumos Students (not confirmed yet for this year), Umit Summer of Code (not confirmed yet for this year), X.Org Endless Vacation of Code, Ruby Summer of Code and possibly others. All of these programs allow you to work on really cool software with a mentor over a longer period and create something you can be proud of. Other communities will likely also be willing to provide guidance if you contact them directly, so don’t be shy
Prospective Google Summer of Code 2012 students.
This is a friendly reminder that the student proposal submission period closes in 3 days.
If you are still working on a proposal, or if you have prepared a proposal but you have not submitted it to Google Melange yet, you better do it very soon!
I’m happy to announce that KDE has been accepted as a mentoring organization in Google Summer of Code 2012. This is our 8th consecutive year. Congrats to all accepted organizations, and a big thanks to everyone who helped to make this happen for KDE!
Students. Now that you have a list of accepted organizations, it’s time to start working on your proposal. KDE maintains an ideas page which is an excellent starting point, and don’t forget to check our student guidelines. I’ve also prepared an article a while ago with a few tips on how to structure your proposal.
You can come up with your own idea or base your proposal on something from the ideas page, but either way it’s very important that you get feedback from the team you wish to work with well before the submissions deadline. If you have general questions about getting involved with KDE as a Google Summer of Code student you’re welcome to ask on our IRC channel #kde-soc on Freenode, or join the mailing list firstname.lastname@example.org. For questions about a specific idea please contact the relevant team (subproject) directly.
Finally, make sure to keep an eye on the official Google Summer of Code timeline – those deadlines are always closer than they seem
Mentors. Now that we know that KDE has been accepted, it’s time to get ready to mentor some students. If you wish to be a mentor your next steps should be:
- subscribe to email@example.com,
- sign up on http://www.google-melange.com and apply as a mentor for KDE,
- contact one of the admins to approve your requests.
For questions you can reach the admin team on #kde-soc or at firstname.lastname@example.org.
And most importantly, in the following weeks you’ll be contacted by prospective students with questions and feedback requests for their proposals. It might take a bit of time and you might get questions with very obvious answers. Please be patient and keep an eye on the timeline
To help you through the process I’ve updated last year’s KDE GSoC process flowchart, courtesy of Lydia Pintscher.
So fine, we skipped a number!
As you may remember, the last beta release was 2.4.2 beta 1. After that, we did roll a 2.4.2 (final) tarball, but because of some issues which were fixed right after the tag we decided to make another tarball and call it 2.4.3.
That being said, I’m happy to announce the immediate availability of Amarok 2.4.3 codename “Berlin”.
So, what’s new in this release?
There’s a whole bunch of UI tweaks with the aim of making the main window less crowded. The 90s called and they wanted their status bar back, so we ditched it and replaced it with relevant notifications where necessary, recovering a bit of vertical space. Also, the Dynamic Playlists feature has undergone an overhaul which should make it easier to use. A bit of work has been done on Internet Services and Podcasts. Moreover, we have accepted quite a few patches from external contributors, and we have squashed lots of bugs, both during the Randa sprint and after.
Read the full announcement here.