If you haven’t contacted the relevant KDE subproject yet (including umbrella projects Kubuntu and Calamares) to submit your proposal for review, it is high time to do so. Take a look at our Google Summer of Code project ideas page, pick one or more of our exciting project ideas, dazzle us with your proposal and hack your way to ultimate glory this summer! A nice paycheck is also part of the deal.

If you have already received feedback and you feel your proposal is in good shape, we encourage you to officially submit it now to Google Melange.

Submitting early means your proposal might get more attention, and you will be able to edit it until the end of the student applications period. The deadline for student applications is March 27, 2015.

Mentors: interest from prospective students has been significant, and we’ll need to match those students with mentors. Offering more mentors might increase the number of student slots we get from Google, so if you are an established KDE developer and you are interested in giving a helping hand with Google Summer of Code, please sign up to be a mentor on Google Melange as soon as possible.

]]>http://teom.org/blog/kde/now-accepting-google-summer-of-code-student-applications/feed/1How to write a kick-ass proposal for Google Summer of Codehttp://teom.org/blog/kde/how-to-write-a-kick-ass-proposal-for-google-summer-of-code/
http://teom.org/blog/kde/how-to-write-a-kick-ass-proposal-for-google-summer-of-code/#commentsFri, 06 Mar 2015 11:42:49 +0000http://teom.wordpress.com/?p=434In a few weeks students can begin submitting their applications for Google Summer of Code 2015.

KDE has been accepted as a mentoring organization again this year, and I’ve already been contacted by several students looking to do a Google Summer of Code project with KDE. Prospective Summer of Code students usually have lots of enthusiasm, and they often write great proposals with little or no help, but sometimes these proposals might not be structured well or lack key information.

I’ve seen my share of good and bad proposals. I’ve been a Google Summer of Code student with KDE three times (four if you count Summer of KDE) so I’ve been in the very situation prospective Summer of Code students find themselves right now. I’ve also been on the other side of the fence: I have been a Google Summer of Code and Google Code-In mentor (and organization administrator) and I’m a professional software engineering instructor (since 2008), so I like to think I can relate with both students and mentors in this case.

This post is for students who wish to take part in Google Summer of Code.

Google Summer of Code is a kind of like a scholarship program, and a very competitive one: if you get picked, you’re one of just a thousand students in the world (1307 last year, 40 of those with KDE) who get to spend their summer hacking on open source software while learning from the very best software craftsmen, and get paid for it too. In order to achieve that, you need to submit an application to Google. An application is essentially a bunch of information you enter in a form, the most important part of it is your proposal.

A Google Summer of Code proposal is a document, it can be rich text but it’s best to consider it plain text because the web application that handles proposal only has basic formatting features.

Writing a good proposal is not easy, especially if you’re a student making first contact with an organization, in this case your proposal is your best advertisement. You have to convince the organization (or at least some key people inside it) why you of all people are the right person for the job. What follows applies to KDE, but it should work for other organizations as well.

I used to structure my proposals the following way (worked well 3 times). This is not a hard rule. You can structure your proposal otherwise, but I think this is a good guideline if you need some inspiration:

Introduction. Your software project should solve a clearly defined problem. Before offering the solution (your Google Summer of Code project), you should first define the problem. What’s the current state of things? What’s the issue you wish to solve and why? Then you should conclude with a sentence or two about your solution. This is somewhat like an elevator pitch.

Project goals. This section should again be short and to the point, and it might be a good idea to format it like a list. You should propose a clear list of deliverables, explaining exactly what you promise to do and what you do not plan to do. “Future developments” can be mentioned, but your promise for the three months of the Google Summer of Code season is what counts. At this point you are making a commitment.

Implementation. This section can be longer and more detailed. You should describe what you plan to do as a solution for the problem you defined earlier. You don’t need to provide a lot of technical details, but you do need to show that you understand the technology and illustrate key technical elements of your proposed solution in reasonable detail.

Timeline. This section is easily overlooked, yet it’s arguably more important than the previous section. With the timeline you show that you understand the problem, that you have thought hard about a solution, and that you have also broken the solution down into manageable bits. If your timeline is reasonable and its deadlines achievable, you show that you have an actual plan on how to go from idea to delivery. With this section you set expectations, so do not make promises you can’t keep. A modest, realistic and detailed timeline is much better than a timeline that promises to move mountains. Mentors are often among the top professionals in their field, and they can easily spot unrealistic timelines.

About me. If you’re done with the other sections this will be a piece of cake. Just put down your contact information and write a few sentences about you and why you think you’re the best for this job. It’s ok to brag a little.

Overall, submit your proposal early, keep it short but include all the necessary information. Get it reviewed by the right people in the organization, well before submitting it to the Google Summer of Code web application. As far as KDE is concerned, you should submit your proposal to the developers mailing list of the relevant subproject as published on the ideas page. I can’t stress this enough: get feedback. Organizations want good proposals and good students, and are usually eager to help you improve your proposal. Just write a brief and informal email, attach your proposal and ask for feedback.

You can submit more than one proposal to the same organization or different organizations to increase your chances, but my advice is to not overdo it: quality is better than quantity.

Good luck!

]]>http://teom.org/blog/kde/how-to-write-a-kick-ass-proposal-for-google-summer-of-code/feed/17Sometimes you need to reinvent the wheelhttp://teom.org/blog/kde/sometimes-you-need-to-reinvent-the-wheel/
http://teom.org/blog/kde/sometimes-you-need-to-reinvent-the-wheel/#commentsSat, 31 Jan 2015 18:37:40 +0000http://teom.org/?p=889On behalf of the Calamares team and Blue Systems, I am proud to announce the immediate availability of Calamares 1.0.

Calamares is a distribution independent installer framework. I had the initial idea for Calamares in May 2014, less than a year ago, and out of frustration: many successful independent Linux distributions came with lackluster installers, and all of these installers were a result of competition rather than cooperation. Improving one of the existing installers wouldn’t have fixed this, as every installer was more or less distribution specific. I wanted to create a product that would satisfy the requirements of most Linux distributions, developed as an upstream project for all of them.

With support from Blue Systems and some help from Aurélien Gâteau I started from scratch around June 2014, with a highly modular design and some valuable contributions from KaOS, Manjaro, Maui and Netrunner developers. Contributors from Fedora, BBQLinux, OpenMandriva and the KDE Visual Design Group joined in afterwards. Now, a little over half a year of design and development frenzy later, we choose to call it 1.0. While there is still room for improvement, we have decided that the first development iteration is done, and we are presenting a modest yet feature-complete product.

I’m happy to announce that KDE has been accepted as a mentoring organization in Google Summer of Code 2013. This is our 9th consecutive year. Congrats to all accepted organizations, and a big thanks to everyone who helped to make this happen for KDE!

This year KDE will also participate in the Free and Open Source Outreach Program for Women, an internship opportunity running almost simultaneously with Google Summer of Code, from June to September. Please note that while the Outreach Program for Women shares many goals and methods with Google Summer of Code, the two programs are not related. Unlike Google Summer of Code, the Outreach Program for Women also allows non-coding contributions. For more information about applying, see KDE’s Outreach Program for Women wiki page.

KDE will also be hosting Season of KDE 2013, with more information to come in the following weeks. Season of KDE is expected to start later in the summer, around the Google Summer of Code midterm.

Students. Now that you have a list of accepted organizations, it’s time to start working on your proposal. The KDE community maintains an ideas page which is an excellent starting point, and don’t forget to check our student guidelines. Also, last year I published an article with some tips on how to structure your proposal, you might find it useful.

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 kde-soc@kde.org. For questions about a specific idea please contact the relevant team (subproject) directly.

For questions you can reach the admin team in #kde-soc on Freenode or at kde-soc-mentor-owner@kde.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

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.

]]>http://teom.org/blog/kde/attention-prospective-mentors-google-code-in-tasks-needed/feed/0Season of KDE: help wanted!http://teom.org/blog/kde/season-of-kde-help-wanted/
http://teom.org/blog/kde/season-of-kde-help-wanted/#commentsSat, 16 Jun 2012 11:13:32 +0000http://teom.org/?p=698Last 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:

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

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

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.

dfc

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

cdu stands for “color du” and it is a Perl wrapper for du. I keep it aliased in place of du.

ls++

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.

Other programs

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. amarok-devel@kde.org for Amarok, digikam-devel@kde.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.

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.

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