More on contributing

This is a bit of a follow up to my previous post but it’s going to wander around a bit.

Image of blindfolded people communicating

Get some guidance

Growing our mentoring programs

One of the common themes was not being sure where to start and needing some guidance. Justin suggested extending mentoring in KDE, which seems like a great idea.

We already have Season of KDE which has been very successful as we explain on the Google Open Source blog (thanks to the many people, students and mentors, who responded to my questions about this and helped me put the summary together).

Perhaps less well known is our list of mentors already available for you at any time of the year (see the list at the bottom of the page – thanks to annma for the pointer). Hopefully, with Justin’s suggestions, this can be made more visible.

Improving documentation

A recurring theme in reply to the posts by Justin and I was that a lack of good documentation makes getting started with hacking on KDE software harder than it needs to be. Techbase tries to address this but it seems there is plenty more to do. However, there are a couple of problems. Can we really expect our volunteer contributors to spend time writing docs when they could be coding? It might bring great benefits in the medium-long term but the results are not as readily apparent for the contributor as a bug fix or a new feature. Also, are our coders good documentation writers? Being good at doing something doesn’t necessarily make you good at explaining it.

So here’s a suggestion: if you ask a question on a mailing list about something that you couldn’t find in the documentation (or if you provide an answer to such a question) please consider uploading the answer to techbase. If you can rewrite it to make it as good as possible, that’s great, but even a start is better than nothing.

Contributing without coding

I often come across some problem, wish there was an app to solve it and – after a bit of digging in Google – find that there is one, often built upon the KDE Platform or at least Qt. As Apple might put it, “there’s an app for that”. However, a lot of our apps don’t really get the attention or publicity they deserve, simply because we don’t have time to write about all of them.

As an example, KMid (a KDE MIDI player, now with backends for Windows and Mac too) had a new release last week. It’s exactly the kind of application that might benefit from a bit of exposure on the Dot, but none of us had time to pick it up and write a release story.

If you have a favourite application that isn’t getting the attention it deserves, consider writing a story for its next release – or perhaps do an interview with its developers (check the Dot Guidelines first).

2 Responses to “More on contributing”

  • keith says:

    One thing I enjoyed and with KDE was on their community forums was Klassroom. Where a mentor would set one up to give a few bugs to people and help them with it. The only thing I seen wrong was they didn’t happen that often.

    I made my first contribution to KStars patching GHNS2 -> 3 in Klassroom. About the documentation issue, I’m one of the people that can do the code, but cannot explain it for my life when documenting Doxygen in my project.

  • Stu says:

    Yeah, that’s probably a good way – particularly if we can get some documentation out at the end of the session too. I guess we come up against some of the same problems though whether the people with the knowledge have the time and ability to share it.