oSC13, Strategy and Factory

The openSUSE conference had some chats about strategy. Ralf talked about suggestions from SUSE in his keynote and there were more suggestions discussed in person between various people. I'd like to summarize some of the things I heard. In this blog I will talk about the directions of Factory, what Ralf mentioned as SUSE's ideas from his keynote; later this week I will blog about the openSUSE releases.

This is a combination of stuff I heard (not just at oSC but also earlier - even from the first strategy discussion, 3 years ago) and ideas I have. I just attempt to put it into text so it is easier to shoot at, comment upon, think about.

Factory

Let's start with talking about Factory.

Who is it for

We need to think about who factory is for, how these people are supposed to be using it etcetera. Right now, we have a shared understanding - but it probably isn't always as shared as it seems and it can be good to write things down and talk about them (see my keynote at oSC). Some of these thoughts will come to the mailing lists, I am sure, over the coming months.

Where should it go

On the technical side, there are some things I've heard about and seen several times and which will most likely see some form of implementation:

• more automated testing - the openSUSE team did a openQA sprint but many agree that there is more room for improvement.
• getting more people involved - As Ralf said, SUSE will commit to more SLE engineers on openSUSE; and the community & the openSUSE team should work more on both growing our dev pool and training people. In a GSOC discussion about this at oSC, this point was made as well: it would be good to use GSOC also for bringing existing contributors to a higher level.
• Bringing Tumbleweed, Devel projects and Factory in alignment - As Ralf noted in his keynote, not all work on Devel projects and Tumbleweed benefits Factory and openSUSE ultimately - it would be great to unite forces and bring them all in one process!
• segmenting Factory in rings - which Coolo has been talking about for a while now. It would create a Ring 0 with the bootstrap- and compiler infrastructure, ring 1 with the base system and other rings on top of that. He has been experimenting with this, hinting at some results in this mail. I leave it up to a later post (perhaps by/with Coolo) to be more concrete about this whole thing once the core Factory team has talked to more people and expanded upon it...

That last point is by far the least concrete - it is an idea which is discussed and toyed with. How much and what exactly will happen - only the Geeko knows ;-)

Some discussion has started on the mailing list, by the way, with the idea of segmenting Factory in even more 'components' than just the rings. I had a chat with Coolo before this proposal came out and I suggested the same thing. He noted that it would lead to a huge mess of dependency issues, including many circular ones (he gave libpoppler as example). This is already brought into the discussion there, let's see where this goes!

Akademy and openSUSE Conference

It's been a insane 7-8 days. Starting with Akademy, where I gave just one talk but still have notes on 5 or 6 sessions to send to the mailing lists, followed up with the openSUSE conference where I give 3 workshops, 3 talks and a keynote, luckily not all unique or alone. The latter is still happening, I just wanted to share some thoughts ;-)

Akademy...

... was awesome as always. I really like that the community is moving forward with thinking about the future. The manifesto is of course a first step but there were BoF sessions talking about the position of KDE e.V. and how it relates to other projects which might want to join us or that we work with; and I ran a session with Valorie and Peter on how to deal with the dark side of community - the least fun moments. (I'll mail to the community ML about this)

Now I am aware that some of these things don't move as quickly as many would like. The manifesto is great but also excluding projects and people many of us actually don't want to exclude. And I bet that beyond that there is even more room for KDE e.V. to play a role, say in helping other FOSS organizations handle GSOC money or even more. Or think about our relationship to Qt...

Meanwhile, I'm of course still concerned with the Marketing side of things. At my presentation I put forward some strategic thoughts from the KDE Marketing Workgroup in this area and there was some good feedback, also in the BoF session about this. If you're on the promo list you can expect mail some time next week.

And many thanks to Carl and everybody at Akademy in helping getting articles out on the dot! It was real team work and that does not only lead to better results but is also a whole lot more fun... Awesome!

openSUSE Conference

Like Akademy, I spend the first oSC day running around, talking to people. And having a few more hours of meeting-with-the-board than I care for. The keynote by Georg however was a great start of the day (see article on news) and I must say the Greeks have outdone, well, everybody. There is a lot of creativity and fun everywhere - from the beach ball shooting (at the audience...) in the welcoming talk to the small pools outside, the style of the event is just awesome. Lots of fun.

On the content side, I really enjoyed talk by Alexjan Carraturo. He pointed out many hard issues with promoting Linux in Italy. And he's an excellent speaker, too - his English might be a tad Italian but it is not hard to follow and his presentation and slides are awesome. Most importantly, he brings up a lot of real excellent, interesting issues which the local team bumps into. From political and economical to social. They have found very creative solutions like the 'openSUSE Live USB station' where people can put in a USB stick and get their live openSUSE on it or using bare ARM board to draw people into the booth.

Max Huang (sakana) gave a great talk on how things are going in Taiwan - amazingly much better. Where Alexjan brought up the many troubles he and his fellow Geekos (and tuxies and more) run into, Max seems almost exhausted by the many open source events taking place in Taiwan! He showed some impressive numbers and facts about what is going on in Asia - clearly, that's where we, as FOSS community, need to put more focus.

Before these two ambassadors sharing their experience, Richard and myself spoke about new directions in the ambassador program and merchandising handling. Of course there were many, many more talks but I haven't seen that many and the above did catch my attention mostly because this is the area I care strongly about...

Currently I'm listening to the openSUSE Board talk about technical directions for openSUSE in response to a question. SUSE has some ideas on that and is sharing those with the community at this event, which is an interesting experience.

oSC isn't over yet and there is much more to come, I look forward to much of that ;-)

(edit: fixed some stupidity with names, I wrote this too quickly)

Debugging a system without desktop

Sometimes, Linux Desktop bites you in the ass. You just get a command line after booting up. I've ran various bleeding edge distro's over the year, including Cooker, Unstable, Factory, Unmasked stuff; build my own kernels and desktop and more.

Seeing a request for help today made me decide to write down the steps I go through when my favorite desktop doesn't appear in the morning... I bet there's plenty to improve, tips are welcome!

General approach

I try to work quickly from the bottom up: test pieces of the lower stack, go higher until it breaks. While digging through logs can find the issue most likely, I've found that shooting a few quick commands to catch common issues is often faster than immediately going to comb through logs... So, first basic things before diving in logs.

step 1: common issues

I usually of course think back to what I recently changed or updated - that's likely the issue. But to keep it generic, let's assume that doesn't tell us anything. Then it's time to look at a few common causes of problems. Log in on a console with the root user name and password.

disk space

First up for me are disk space and stuff in tmp. A full disk can lead to the weirdest problems - from an end user perspective, it often makes no sense. So check how much space there is on your devices:
df -h
and check the output for 100% full drives:
Filesystem       Size   Used   Avail   Use%   Mounted on
devtmpfs         7.7G   8.0K    7.7G     1%   /dev
tmpfs            7.7G   5.2M    7.7G     1%   /dev/shm
tmpfs            7.7G   319M    7.4G     5%   /run
/dev/sda1          2G   704M    1.2G    63%   /boot
/dev/sda2         20G    14G    5.0G    74%   /
tmpfs            7.7G      0    7.7G     0%   /sys/fs/cgroup
tmpfs            7.7G   139M    7.6G     2%   /tmp
tmpfs            7.7G   319M    7.4G     5%   /var/lock
tmpfs            7.7G   319M    7.4G     5%   /var/run
/dev/sda3        213G    74G    139G    35%   /home
Obviously, if a drive seems full (less than 100 mb free), it's time to clean up. I trust you know enough cd ../cd [directory] and rm -rf [directory]/rm [filename] to get this done...

Temporary directory

Looks all good here, so next step then, just to check: if /tmp is not mounted on a temporary ram drive (like in my case), just clear everything in there to make sure nothing is causing issues. rm -rf /tmp/* will do the trick. Yeah, canon, fly, but /tmp should not be used by applications to store important data (hence the name) so this is safe™. Also, check permissions for /tmp, just to be sure:
ls -la / |grep tmp
drwxrwxrwt 30 root root 760 26.06.2013 15:37 tmp/
Yes, /tmp should be readable and writable by anyone, so the permissions string rwxrwxrwt is important. If it is anything else, execute
chmod +rwxrwxrwt /tmp, remove the contents of /tmp again with rm -rf /tmp/* and try again.

update the system

Third, I always quickly do a zypper refresh && zypper update. If an update broke it, let's see if a newer update can fix it ;-)
Of course, use the commands appropriate to your distribution: apt-get update && apt-get upgrade; pacman -Syu; etcetera.

Step 2: does X work?

Second is seeing if the graphical system (X.org/xorg/X11, or just 'X') still works. Type
startx /usr/bin/xterm
This will start a simple terminal in the graphical environment and nothing else. As failsafe as it gets... If it works go to step 2, if not, see below.

X not working?

Now it's time to check the X.org log file and perhaps the output of the startx command. Any hints there as to what's wrong? If not, look in /var/log/Xorg.0.log (less /var/log/Xorg.0.log will do) and see where you have errors. The Xorg log is long, but has a neat way of showing errors: the codes between parenthesis give hints to what the line represents. Example output:
[199842.753] (WW) Falling back to old probe method for fbdev
[199842.753] (II) Loading sub module "fbdevhw"
[199842.753] (EE) Failed to load module "modesetting" (module does not exist, 0)
First a timestamp, then the code (WW = warning, II is for your info; Look for EE, meaning error!) and then you can try and solve this. In this case, a module doesn't exist - that looks like xorg didn't upgrade properly or got partially uninstalled. Search your package database for xorg and see if possibly-important packages are missing: zypper se x11
Loading repository data...
Reading installed packages...

S | Name                          | Summary       | Type
--+-------------------------------+---------------+-----------
[cut for simplicity]
  | xorg-x11-driver-input         | [cut for simplicity] | package
i | xorg-x11-driver-video         | [cut for simplicity] | package
  | xorg-x11-driver-video         | [cut for simplicity] | srcpackage
  | xorg-x11-driver-video-nouveau | FOSS nVidia driver   | package
[cut for simplicity]

You could imagine the input driver might be missing. Or, if you have nvidia hardware and don't use the proprietary driver, well, nouveau is what you need!

Likely culprit for users of NVidia and AMD hardware is in the proprietary drivers. You're in for a world of pain - I'd just remove them and re-install once your graphical system works again. For NVidia (the only one I have experience with) I usually just remove anything I see with nvidia in it and install the mentioned nouveau driver. Find more Xorg debugging solutions on this excellent Fedora wiki page. Once startx works, I'd reboot.

Step 3: does the desktop work?

Third is finding out if your desktop (plasma desktop, GNOME Shell etc) works. Exit the xterm (note that your mouse has to hover the window before you can type in it) and now start startx without the terminal command:
startx
Because you're root you have a relatively 'clean' user account (you should never daily use the 'root' account for your desktop, we're just testing here). If it doesn't work, you could attempt to remove the desktop user settings in the root user account. For a KDE Plasma Desktop that means:
rm -rf ~/.kde4
Note that I again assume you don't USE this account and the settings are inconsequential. Don't do this on a normal user account, you loose lots of settings, recent files and even data!

If the problem is in user settings, you should by now be on you to your desktop of choice, logged in as root! If that is indeed the case, skip to the next step. If you're not there, let's find out what is wrong.

Desktop doesn't come up?

Ok, step back. xterm did work, Plasma/Shell/XFCE don't? Let's see if we can start them FROM a xterm and catch a glimpse of where we get!
startx xterm
Now back in the terminal? Ok, let's start Plasma Desktop as example. type
startkde
and observe KDE attempting to start. Now you should see some messages and hopefully you can take it from here - going any deeper doesn't really fit this blog post, google is your friend from here onwards...

Step 4: User config broken!

Now we know where the problem is, at least, approximately: the graphical system works, the desktop works, so it's in the user settings. Time to dig there. 90% certain the issue is in the configuration of your desktop, although it could be an application somehow botching stuff. Let's start with startx and xterm again. Log in from the command line as your user and type
startx xterm and then startkde or the equivalent for the desktop you're looking for. Observe the failure, see if it tells you anything. If that doesn't help, next up the Real Hard Work: finding out what setting in your ~/.kde4 configuration folder is the culprit.

I suggest to back up your config folder:
cp -R ~/.kde4 kde4-config-backup
Then go in and randomly nuke files and folders until you get the problem. Ok, random is a bit too bad, I'd start removing ~/.kde4/share/config and if that doesn't solve it put it back and remove ~/.kde/share/config/apps instead. One of these two contains the problem, most likely...

More?

In the end, you'll have to find and solve the problem with googling and simply some hard work... The above is a guide which I personally follow, essentially a heuristic based on lots of fixing. I bet lots of readers have tips and tricks that are far more helpful and I'll happily update this post to include them...

Hugs and good luck!

oSC2013 next!

After Akademy 2013 in Bilbao, we will fly (via Berlin...) to Thessaloniki, Greece, where the openSUSE Conference will take place. Like I argued for Akademy, oSC is a relevant and useful event for the openSUSE folk.

History - oSC 10, 11 and 12

This year oSC takes place in Greece, a fact far more relevant than it might seem. The first three openSUSE Conferences I attended took place in Nürnberg. First in a conference center, the third was the legendary oSC2011 in the Zentrifuge, an old factory building creating an absolutely amazing atmosphere. Both events were largely organized by SUSE employees from the Nürnberg office but oSC11 already had a fair involvement of volunteers and a strong focus on BoF sessions and 'getting stuff done'. We had a lively marketing and ambassador team by then. I vividly remember the day before the event, when I rode a van full of crazy geekos by a few stores, buying everything from carpets and plants to lights to dress up the location. Every day we figured out who would staff the bar, organize stuff in the rooms - and moving the chairs was a matter of asking outside if a few folk would be willing to help out. At this event, there was already talk about doing the openSUSE conference in Greece.

First Prague

But going from doing the event in Nue and by SUSE people (with help) to doing it in Greece by volunteers (with help) seemed a big step and the team also had limitations as to the date and time: the event would have to be in May or June. As it was already September when oSC'11 took place, that was very close.

There came a different proposal from Michal and others in Prague, and with an office there, we decided it made much more sense to do it there and told Kostas that he'd have his oSC in Thessaloniki, but one year later. I joined Michal in scouting for a location in Prague and discovered a local community was about to organize another Linux event a mere two weeks after the openSUSE Conference! I proposed to merge the two, and the format of oSC'12 was born. Like oSC'10 two years earlier, this event tried to focus on collaboration and bringing communities together. I unfortunately had to scale back my involvement in the conference significantly after LinuxTag Berlin in May 2012 due to health issues and barely could make it to the event itself. Meanwhile, the Greeks had already started preparing the organization of oSC'13 and were present with a large team at oSC'12 to help run the show.

Greece in 2013

Feedback from the event did show that the openSUSE community wanted more 'Geeko time', so the Greek team has made sure that there will be a good openSUSE focus at the event. Of course, without compromising our open nature: there will be plenty colors besides green. Naturally, SUSE input will be lower than usual - the Nürnberg can't easily take a afternoon off to visit, even a bus trip is not enough. But we have made sure that many central developers will be there and there is a host of great sessions coming - a post about that on news.opensuse.org is coming soon!

Due to the internal changes at SUSE, I haven't been as much involved in the event as I would have liked but just seeing the conference team work has been amazing. It isn't just a Greek affair, mind you - for example, the logo and much artwork comes from the other side of the world, by the hands of US citizen Anditosan and Brazilian Carlos Ribeiro! And as with the Prague conference, Izabel Valverde again played a major role in handling travel support and sponsors. And we have Robert Schweikert and Henne Vogelsang, working on the program and website, Matt Barringer building OSEM (!!!) and some others.

Awesome

I might be overusing that word - but I really, really think oSC'13 will be awesome. As far as it is up to the Greekos organizing it, there's no doubt! And like with Akademy, if you haven't booked yet - you should...

Have a lot of fun and see you in Greece ;-)





PS: note that the above is mostly my memory of How Stuff Happened™. There were plenty more people involved, pushing, making it happen. Thanks to all of them, as we're gonna have a great conference in Greece ;-)

Akademy for everybody

About six weeks from now the yearly KDE conference 'Akademy' will kick off in Bilbao, Spain! Looking forward to that. I had to ramble a bit on why I think it's worth going there. And a tip for if you still have to book!

Have not booked yet?

Aw, I was late, and I'm paying the price, in terms of money and convenience. There's work and family and in my case a dose of always-lateness with this stuff that got in the way. Probably not different for others. But keep in mind - I never met anybody who who was sorry they went through the trouble of going to Akademy! It's worth it...

Relevant

Akademy is relevant, useful and fun above and beyond just another Free Software event. Seriously. Even in a world of Android, KDE still builds major Free Desktop stuff. Think about Krita going places lately. Think about how KDE PIM still is arguably the only serious Free enterprise-ready mail-calendar-etc solution on the market. There is plenty more at the event: KParts might get a successor, we move forwards with new task-centered UI paradigms, we move to new devices and more.

Directions

Akademy is important for setting directions. We don't all agree on where KDE is going and that's why we meet. To SET goals and CHECK expectations. That is hard to do over mailing lists, blogs, social media and all that - so we need to talk in person. We're doing new things and it takes a while, often a long while, to get stuff together. We have to address misconceptions, improve common understanding, find out why we disagree. And this works, we're making progress! Nepomuk is now getting the love it needed and same for KDE PIM, the Plasma team can finally implement their ambitious plans without the technical limitations of old thanks to QMLv2 and openGL etc etc.

And I'm betting that those who think KDE is doing the wrong thing actually have arguments and reasons for that. Are these reasons so vague and unconvincing that nobody will listen? Or would the KDE folk be so stubborn they wouldn't listen to obvious facts? That is either under-estimating who-ever-disagrees or the 300-odd KDE contributors. And both, I think, are undeserving of that.

Family

Akademy is about more than listening to talks or giving them. Even if you haven't had time or motivation to contribute, if you didn't agree with one thing or another or got yelled at by (or did yell at) somebody, does that matter? KDE is family: family has plenty of disagreements and fights, yet in the end, you all hug and make it up to each other, yes? Being at Akademy is not just about learning new things and deciding on the future of what we do (and, to a large degree, where Free Software for end users is going) but it is also about meeting, having energizing and inspiring conversations, learning from each other, sharing great ideas. Something we all enjoy, don't we?

Booking

I'm sure there'll be a lot of people at Akademy but I think that should include you... Now, about the booking. It will be hard to get a hotel room, esp if you need space for two people, I'm afraid... I booked the first 3 days (Thursday-Friday-Saturday) for a painfully high price in the Holiday Inn Express Bilbao and the rest in RÍA DE BILBAO which is far cheaper.

And last but not least, if you're going to Akademy and want to make sure all relevant people are there, be sure to talk to those you'd like to have a chat with, convince them to go! And perhaps add the awesome going to Akademy badges to your blog or website!

openSUSE at LinuxTag 2013

As I wrote last week, openSUSE was at Linuxtag. We didn't have a huge team like last year, nor did we bring all the beer - but we had some fun nonetheless.

Awesomeness

For me, the most awesome thing was the openSUSE Jeopardy done by Christan Boltz, it was SUPER cool. Of course, part of that was because I won, mainly due to the quotes section - my fellow participants had no idea who wrote them. I even recognized my own quote and it looks like I still can agree with myself. Must say that the Jeopardy thing was really, really fun.

For those wondering what the heck I'm talking about: we have small booth talks at our booth at LinuxTag. I believe Henne Vogelsang once started doing this (even before I joined openSUSE), teaching people how to fold paper Geekos and stuff like that. I'm not that creative, so I only gave KDE tips and Tricks on Wednesday and Saturday. Strange enough, nobody even seemed to have noticed that I gave that session in my favorite GNOME shirt... Luckily Christian had a way better idea for these booth talks: Jeopardy!

He has a cool html web thingy for it, complete with tracking scores and all that and I had arranged Club Mate for the winners (and, often, for the losers too). There were questions in areas like security, coding and development languages. Some worked with pictures, others had text but they were all quite ingenious. The '/etc/firstline' was cool although I didn't know any of them: it shows you the first non-comment line of a random file in /etc and you have to say what file it's from. Many of the questions were rather not openSUSE-specific, only the quotes from the Factory mailinglist (quote, you guess who said it) and the openSUSE Releases (screenshots of openSUSE login screens, you guess the version) were. I even learned a thing or two ;-)

Bernhard Wiedemann also joined the booth team, I even have to say he formed the core of it, being the most steady force as Christian didn't make it on Wednesday and I wasn't there on Thursday and Friday. He talked about OBS packaging which also attracted people interested in packaging.

The booth

Meanwhile, I've been working on the new openSUSE Merchandising program and that includes making a 'list of stuff to bring'. I decided to try and use LinuxTag to test out a few things! The booth pictures you see include some (but not all) of the goodies we plan on including in booth boxes. We learned some valuable lessons about the materials at the event. Our booth was at the entry of the event, for good or bad. The area was a bit small (although we shared some space with the ownCloud team next to us) but mostly people simply walked by to the main hall with booths and I'm not sure if they ever came back...

We had no beer this year but openSUSE Conference flyers and posters as well as a batch of 500 openSUSE flyers based on a design we've been working on in the last 2 years (until now they were only printed in the US). It seems not too many are interested in going to Greece (can't imagine why) but it was still good to point the existence of the conference out to people.

For the openSUSE flyer I had the explicit goal of seeing if it could help kickstart a conversation. I am not sure if that really works, but of course our booth team was so experienced they don't really need talking points.

The 'we believe' poster got some very valid criticism from the ownCloud team which was next to our booth: it has too much text on it and people simply won't read it. Having that design as small (a6 or so) hand out might work far better, or as a slide in a presentation. And having a big one with images or somehow else more, hum, easily (lazily) processed might be a good combination. Anybody has any ideas on how to put our philosophy as expressed on this poster in the form of a more graphical image? I'd love to see some ideas ;-)

Also, if you visited our booth and are reading this - I would love feedback, both good and bad. On the looks of it, the posters, flyers, DVD, people - all of it!

Talks

We also had a few 'big' (as in, not at the booth) talks. Bernhard and Sascha spoke about OpenStack / SUSE Cloud / crowbar in the main track and I myself talked for about 30 min on what happened to openSUSE in the last year and gave a 2 minute lightning talk about our booth as well. All talks went well but LinuxTag isn't the most crowded event and seems to be getting smaller - talking for 20 people is perhaps more fun as you get to have more close contact to the audience but it's hardly worth traveling for.

The booth talks I gave about 'advanced KDE usage' where big fun. They usually had just a handful of visitors which meant we all sat together around my laptop and could discuss things quite nicely. Fun!

Edit: and I forgot to mention the talk Bernhard gave on "openSUSE on ARM" including our cross-compilation tricks with qemu-linux-user. And sorry for the appearance of some old blogs on planet.KDE, I have no idea how to convince blogger not to do that stupid thing - I only updated the tags. The dates are correct :(

Getting involved in Free Software

I frequently get the question, by mail or over social networks:

But how do I get involved in $PROJECT?

Now a common answer is 'just do it' while others often point to resources like the KDE Developers Beginners Guide and Contribute to openSUSE, or write a simple how-to for building a package. But I usually don't actually reply with links to any of those. Mostly, people have found these resources by themselves.

What they want to know now is how to, you know, actually do it! And as that question can actually be answered rather project-independent so I thought it would be useful to write it down here.

Step one - Build the Code and get Familiar

After reading the various guides and how-to's, you set up a development environment. Be sure you can run the unstable application(s) or hack on a package. Getting that up and running is a very good first step.

I would also subscribe to mailing lists, read the blogs and hang out in IRC. Just watch what is going on: it will teach you the culture of the community and that's crucial to get stuff done later.

Step Two - Hack Something

Perhaps you will already find bugs, then: trying to report them is good, trying to fix them is better. It will not be easy to fix them but that is when you can ask for help on IRC, forums or here!

If you don't find any bugs you want to fix, perhaps you can think about what to add, what to change. What do YOU think is important and what needs to be done? It doesn't matter if you pick something yourself or find a todo list or wiki page of the project and pick something there. The hardest part will be: JUST DO IT. Get hacking. You'll get stuck, that is OK: read documentation and when you can't figure it out, just ask for help. Above all: don't give up until you are done! I would suggest not to pick something too big. A one-liner patch will take you a day, easily, and might not seem important, but this first step matters a lot. Don't try to fix the entire user interface or work flow with your first change! For example, fixing code style to comply with the project rules is already a perfectly fine first step.

Step Three - Get it in

Now you got something, so get it back to the project. On Github or on the Open Build Service you do a merge request; in other projects you have different work flows varying from sending the patch by mail to using review board or other tools. It doesn't matter.

This won't be easy, but that is mostly due to you being so anxious about it: it can take quite a while for the developers to review the patch and they're sure to have some comments on it. Don't be discouraged and do know that you're allowed to poke them: two weeks waiting isn't much in many projects but it's enough that you are entitled to poke somebody. Send a follow-up mail or ping somebody you know is active in the project on IRC and ask politely if they know how you can get feedback or if you did something wrong in the way you asked.

Note that your patch will not always go in, even in modified form. Not all projects might be OK receiving code style fixes or consider what you fixed a bug. Again, the hardest part here is to not be discouraged. You can ask if they can at least tell you that what you did made some kind of sense; and/or ask for a suggestion for something easy to fix. If they're half-way decent they will be nice about it! If not, perhaps you picked the wrong community to help out in...

Step Four - That's all!

When you manage to fix or hack ONE thing, you have done the hardest part of getting involved in Free Software: you GOT STARTED. From then on, you can find other things and really Make a Difference.

Really

Seriously, there is no more to it. The hardest part is of course the doing itself - but no amount of preparation can make that easier. The most important tip in this is to not give up, the second most important one is to ask for help. All developers had to go through this. Some locked themselves up in a basement, others spend a week banging their head against a computer screen. All of them created a ugly beast of a patch, article, image or whatever your first attempt is. That is perfectly fine. Accepting that is probably the third most important tip ;-)

Of course, I can recommend to check out Open Advice as it contains the lessons of quite a few smart folk. The short essays make for a nice read before bed time or so.

Have a lot of fun and enjoy hacking ;-)