Two weeks ago was the GNOME Software hackfest in London, and I’ve been there! And I just now found the time to blog about it, but better do it late than never .

Arriving in London and finding the Red Hat offices

After being stuck in trains for the weekend, but fortunately arriving at the airport in time, I finally made it to London with quite some delay due to the slow bus transfer from Stansted Airport. After finding the hotel, the next issue was to get food and a place which accepted my credit card, which was surprisingly hard – in defence of London I must say though, that it was a Sunday, 7 p.m. and my card is somewhat special (in Canada, it managed to crash some card readers, so they needed a hard-reset). While searching for food, I also found the Red Hat offices where the hackfest was starting the next day by accident. My hotel, the office and the tower bridge were really close, which was awesome! I have been to London in 2008 the last time, and only for a day, so being that close to the city center was great. The hackfest didn’t leave any time to visit the city much, but by being close to the center, one could hardly avoid the “London experience” .

Cool people working on great stuff

That’s basically the summary for the hackfest . It was awesome to meet with Richard Hughes again, since we haven’t seen each other in person since 2011, but work on lots of stuff together. This was especially important, since we managed to solve quite some disagreements we had over stuff – Richard even almost managed to make me give in to adding <kudos/> to the AppStream spec, something which I was pretty against supporting (it didn’t make it yet, but I am no longer against the idea of having that – the remaining issues are solvable).

Meeting Iain Lane again (after FOSDEM) was also very nice, and also seeing other people I’ve only worked with over IRC or bug reports (e.g. William, Kalev, …) was great. Also lots of “new” people were there, like guys from Endless, who build their low-budget computer for developing/emerging countries on top of GNOME and Linux technologies. It’s pretty cool stuff they do, you should check out their website! (they also build their distribution on top of Debian, which is even more awesome, and something I didn’t know before (because many Endless people I met before were associated with GNOME or Fedora, I kind of implicitly assumed the system was based on Fedora )).

The incarnation of GNOME Software used by endless looks pretty different from what the normal GNOME user sees, since it’s adjusted for a different audience and input method. But it looks great, and is a good example for how versatile GS already is! And for upstream GNOME, we’ve seen some pretty great mockups done by Endless too – I hope those will make it into production somehow.

XdgApp and sandboxing of apps was also a big topic, aside from Ubuntu and Endless integration. Fortunately, Alexander Larsson was also there to answer all the sandboxing and XdgApp-questions.

I used the time to follow up on a conversation with Alexander we started at FOSDEM this year, about the Limba vs. XdgApp bundling issue. While we are in-line on the sandboxing approach, the way how software is distributed is implemented differently in Limba and XdgApp, and it is bad to have too many bundling systems around (doesn’t make for a good story where we can just tell developers “ship as this bundling format, and it will be supported everywhere”). Talking with Alex about this was very nice, and I think there is a way out of the too-many-solutions dilemma, at least for Limba and XdgApp – I will blog about that separately soon.

On the Ubuntu side, a lot of bugs and issues were squashed and changes upstreamed to GNOME, and people were generally doing their best to reduce Richard’s bus-factor on the project a little .

I mainly worked on AppStream issues, finishing up the last pieces of appstream-generator and running it against some sample package sets (and later that week against the whole Debian archive). I also started to implement support for showing AppStream issues in the Debian PTS (this work is not finished yet). I also managed to solve a few bugs in the old DEP-11 generator and prepare another release for Ubuntu.

We also enjoyed some good Japanese food, and some incredibly great, but also suddenly very expensive Indian food (but that’s a different story ).

The most important thing for me though was to get together with people actually using AppStream metadata in software centers and also more specialized places. This yielded some useful findings, e.g. that localized screenshots are not something weird, but actually a wanted feature of Endless for their curated AppStore. So localized screenshots will be part of the next AppStream spec. Also, there seems to be a general need to ship curation information for software centers somehow (which apps are featured? how are they styled? added special banners for some featured apps, “app of the day” features, etc.). This problem hasn’t been solved, since it’s highly implementation-specific, and AppStream should be distro-agnostic. But it is something we might be able to address in a generic way sooner or later (I need to talk to people at KDE and Elementary about it).

In summary…

It was a great event! Going to conferences and hackfests always makes me feel like it moves projects leaps ahead, even if you do little coding. Sorting out issues together with people you see in person (rather than communicating with them via text messages or video chat), is IMHO always the most productive way to move forward (yeah, unless you do this every week, but I think you get my point ).

For me, being the only (and youngest ^^) developer at the hackfest who was not employed by any company in the FLOSS business, the hackfest was also motivating to continue to invest spare time into working on these projects.

So, the only thing left to do is a huge shout out of “THANK YOU” to the Ubuntu Community Fund – and therefore the Ubuntu community – for sponsoring me! You rock! Also huge thanks to Canonical for organizing the sponsoring really quickly, so I didn’t get into trouble with paying my flights.

To worried KDE people: No, I didn’t leave the blue side – I just generally work on cross-desktop stuff, and would like all desktops to work as well as possible

I am using FreeBSD+ZFS for my NAS home server since 2009, see my old post about it here: My ZFS Home NAS/HTPC Box Build

The setup worked perfectly in the last years and even if I had a few hard drives failures I never lost any data. Replacing the hard drives was really easy and the system was back to normal in a matter of minutes. Over the last years I also upgraded the hardware a few times:

• two years ago I replaced the mainboard, cpu and added more ram: ASUS P8H77-I + Intel Celeron G460 + 8GB Ram
• about one year ago I replaced the cpu with an Intel Core i3-3250 and went up to 16GB Ram (maximum supported)

And finally, a few weeks ago, I have just found a great deal for a HP Proliant Microserver Gen8 having in standard configuration Intel G1610T cpu and 4GB ECC Ram and I could not miss it. I replaced the Ram with 2x8GB ECC. So that's my new, current, Home Server (NAS) and I am really happy with it. I spent some time with its configuration because of some little issues with running FreeBSD on it and I also decided to change a bit my setup (adding jails for services). I am not using this box for HTPC anymore.

# dmesg
Copyright (c) 1992-2016 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.3-RELEASE #0 r297264: Fri Mar 25 02:10:02 UTC 2016
    root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
CPU: Intel(R) Celeron(R) CPU G1610T @ 2.30GHz (2294.84-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x306a9  Family=0x6  Model=0x3a  Stepping=9
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0xd9ae3bf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,TSCDLT,XSAVE,OSXSAVE>
  AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
  AMD Features2=0x1<LAHF>
  Structured Extended Features=0x281<FSGSBASE,SMEP,ERMS>
  XSAVE Features=0x1<XSAVEOPT>
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 17179869184 (16384 MB)
avail memory = 16571678720 (15803 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: <HP     ProLiant>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
[...SKIP...]

Here is a short story with the issues I had: The HP ProLiant MicroServer Gen8 is a small, quiet, and stylishly designed server that is ideal for a NAS storage. It has 4-Bay for hard drives (main storage) and one place for an ODD drive but there is no ODD drive supplied. Initially I decided to add a SSD to this Sata II port to have it for FreeBSD OS and use it also as a storage for some virtual machines (more about my home virtual lab setup in future posts). The first issue was that I could not boot from that SSD because the system is able to boot only from the HDD in the first bay or from usb. After some research I found that the system will be able to boot from the Sata port connected to ODD drive but only if you create a RAID0 and add only the single SSD disk to it. I tried it but if the RAID card is enabled in BIOS, there is no chance to boot FreeBSD. Even from USB is not booting anymore, I always got "BTX Halted" error (there is a screenshot in the photo album below).

The solution was to just disable the RAID card in BIOS, and anyway because I am using ZFS for my NAS is not recommended to use the RAID card (for ZFS storage) which is coming with the server, so is better to just disable it and use the AHCI mode for hard drives.

Not being able to boot FreBSD from my SSD I had to change my plan a bit and perhaps boot from usb. I picked up a SanDisk Ultra 16GB usb stick, installed FreeBSD on it and thrown it in the internal usb port. After I was sure that everything was working as expected I decided to move /usr and /var on the SSD drive and let just keep the / partition on my usb stick. Importing the storage drives with mirrored ZFS pools was really easy and everything is working perfectly now.

I mentioned that I decided also to change a bit my NAS configuration and instead having all services (samba, afp, transmission, plex, monitoring, ...) on my host machine, move them to run each of them in their jail will be preferred. Here are the current jails I run right now:

# jls
   JID  IP Address      Hostname                   Path
     1  192.168.0.41    samba.home.local           /storage/jails/samba
     2  192.168.0.42    afs.home.local             /storage/jails/afs
     3  192.168.0.43    transmission.home.local    /storage/jails/transmission
     4  192.168.0.44    plex.home.local            /storage/jails/plex
     5  192.168.0.45    monitoring.home.local      /storage/jails/monitoring
     6  192.168.0.46    gitlab.home.local          /storage/jails/gitlab
     7  192.168.0.47    confluence.home.local      /storage/jails/confluence
     8  192.168.0.48    virt.home.local            /storage/jails/virtual

And here are some pictures: HP Proliant Microserver Gen 8 Home NAS Photos

Since mid-2015 we were using the dep11-generator in Debian to build AppStream metadata about available software components in the distribution.

Getting rid of dep11-generator

Unfortunately, the old Python-based dep11-generator was hitting some hard limits pretty soon. For example, using multiprocessing with Python was a pain, since it resulted in some very hard-to-track bugs. Also, the multiprocessing approach (as opposed to multithreading) made it impossible to use the underlying LMDB database properly (it was basically closed and reopened in each forked off process, since pickling the Python LMDB object caused some really funny bugs, which usually manifested themselves in the application hanging forever without any information on what was going on). Additionally to that, the Python-based generator forced me to maintain two implementations of the AppStream YAML spec, one in C and one in Python, which consumes quite some time. There were also some other issues (e.g. no unit-tests) in the implementation, which made me think about rewriting the generator.

Adventures in Go / Rust / D

Since I didn’t want to write this new piece of software in C (or basically, writing it in C was my last option ), I explored Go and Rust for this purpose and also did a small prototype in the D programming language, when I was starting to feel really adventurous. And while I never intended to write the new generator in D (I was pretty fixated on Go…), this is what happened. The strong points for D for this particular project were its close relation to C (and ease of using existing C code), its super-flat learning curve for someone who knows and likes C and C++ and its pretty powerful implementations of the concurrent and parallel programming paradigms. That being said, not all is great in D and there are some pretty dark spots too, mainly when it comes to the standard library and compilers. I will dive into my experiences with D in a separate blogpost.

What good to expect from appstream-generator?

So, what can the new appstream-generator do for you? Basically, the same as the old dep11-generator: It will extract metadata from a distribution’s package archive, download and resize screenshots, search for icons and size them properly and generate reports in JSON and HTML of found metadata and issues.

LibAppStream-based parsing, generation of YAML or XML, multi-distro support, …

As opposed to the old generator, the new generator utilizes the metadata parsers and writers of libappstream. This allows it to return the extracted metadata as AppStream YAML (for Debian) or XML (everyone else) It is also written in a distribution-agnostic way, so if someone wants to use it in a different distribution than Debian, this is possible now. It just requires a very small distribution-specific backend to be written, all of the details of the metadata extraction are abstracted away (just two interfaces need to be implemented). While I do not expect anyone except Debian to use this in the near future (most distros have found a solution to generate metadata already), the frontend-backend split is a much cleaner design than what was available in the previous code. It also allows to unit-test the code properly, without providing a Debian archive in the testsuite.

Feature Flags, Optipng, …

The new generator also allows to enable and disable certain sets of features in a standardized way. E.g. Ubuntu uses a language-pack system for translations, which Debian doesn’t use. Features like this can be implemented as disableable separate modules in the generator. We use this at time to e.g. allow descriptions from packages to be used as AppStream descriptions, or for running optipng on the generated PNG images and icons.

No more Contents file dependency

Another issue the old generator had was that it used the Contents file from the Debian archive to find matching icons for an application. We could never be sure whether the contents in the Contents file actually matched the contents of the package we were currently dealing with. What made things worse is that at Ubuntu, the archive software is only updating the Contents file weekly daily (while the generator might run multiple times a day), which has lead to software being ignored in the metadata, because icons could not yet be found. Even on Debian, with its quickly-updated Contents file, we could immediately see the effects of an out-of-date Contents file when updating it failed once. In the new generator, we read the contents of each package ourselves now and store them in a LMDB database, bypassing the Contents file and removing the whole class of problems resulting from missing or wrong contents-data.

It can’t all be good, right?

That is true, there are also some known issues the new generator has:

Large amounts of RAM required

The better speed of the new generator comes at the cost of holding more stuff in RAM. Much more. When processing data from 5 architectures initially on Debian, the amount of required RAM might lie above 4GB, with the OOM killer sometimes being quicker than the garbage collector… That being said, on subsequent runs the amount of required memory is much lower. Still, this is something I am working on to improve.

What are symbolic links?

To be faster, the appstream-generator will read the md5sum file in .deb packages instead of extracting the payload archive and reading its contents. Since the md5sums file does not list symbolic links, symlinks basically don’t exist for the new generator. This is a problem for software symlinking icons or even .desktop files around, like e.g. LibreOffice does.

I am still investigating how widespread the use of symlinks for icons and .desktop files is, but it looks like fixing packages (making them not-symlink stuff and rather move the files) might be the better approach than investing additional computing power to find symlinks or even switch back to parsing the Contents file. Input on this is welcome!

Deploying asgen

I finished the last pieces of the appstream-generator (together with doing lots of other cool things and talking to great people) at the GNOME Software Hackfest in London last week (detailed blogposts about things that happened there will follow – many thanks once again for the Ubuntu community for sponsoring my attendance!).

Since today, the new generator is running on the Debian infrastructure. If bigger issues are found, we can still roll back to the old code. I decided to deploy this faster, so we can get some good testing done before the Stretch release. Please report any issues you may find!

Last night I found time to finally install the first release candidate of Volumio 2, my preferred audio player software. This is more exciting than it sounds, because when I read the blogpost last summer that Volumio is going to be completely rewritten, with replacing the base technologies, I was a bit afraid that this will be one of the last bits that we heard from this project. Too many cool projects died after famous last announcements like that.

But not Volumio.

After quite some development time the project released RC1. While there were a few small bugs in a beta, my feelings about the RC1 are really positive. Volumio2 has a very nice and stylish GUI, a great improvement over Volumio1. Album-art is now nicely integrated in the playback pane and and everything is more shiny, even if the general concept is the same as in Volumio1.

I like it because it is only a music player. Very reduced on that, but also very thought through and focussed to fulfill that job perfectly. I just want to find and play music from my collection, quickly and comfortable and with good sound quality. No movies, series, images. Just sound.

About speed: While the scanning of my not too big music collection on a NAS was a bit of a time consuming task in the past, this feels now much faster (maybe thats only because of a faster network between the Raspberry and the NAS?). Searching, browsing and everything works quite fluid on an Raspberry2. And with the Hifiberry DAC for output, the sound quality is more than ok.

This is an release candidate of the first release of the rewritten project, and the quality is already very good. Nevertheless I found a few things that did not work for me or could be improved. That the volume control is not working is probably because of the Hifiberry DAC driver, I remember there was something, but haven’t investigated yet.

There are some things in the GUI that could be looked at again: For example on the Browse page, there is the very well working search field. After entering the search term and Enter, the search result is displayed as a list of songs to select from. I wished that the songs were additionally grouped by albums, which should also be selectable to be pushed to the play queue.

Also it would be great if the Queue would somehow indicate which entry is currently played. I could not spot that.

But these are only minor findings which can easily be addressed later after enhancement requests were posted :-)

I think Volumio2 is already a great success, even before it was released! You should not hesitate to try it if you love to listen to music!

Thanks for the hard work Volumio-Team!

With kind support of the Medialab foundation and Jan Šedivý, we are looking hard for students in Prague to work with us on a summer internship! We actually have two options for you:

• eClub Summer Camp (main option) – we have some ambitious projects and ideas for you to try out if you are excited by machine learning, big data and artificial intelligence. Exploratory, exciting, state-of-art research without required previous in-depth knowledge! (Just good basic math and programming.)
• Summer Job (auxiliary option, full-time coder) – we need help polishing the edges of some of our projects, seeking students that are skilled programmers.

We are mainly affiliated with FEL CVUT, but we also have students from MFF UK and we’ll welcome students from other Czech universities too. As long as you are a competent programmer, want to do something more than yet another Android game, and willing to come in person three times a week – let’s do something groundbreaking together!

Recently, the YodaQA team is collaborating with Falk Pollok from RWTH Aachen who is interested in using Question Answering in education to help people digest what they have learned better and to generally assist with studying. To this end, he has created PalmQA – a QA application that multiplexes between many question answering backends, ensembling them together to a more accurate system.

Falk has built backends for IBM Watson’s DeepQA among others (Google, Evi, Kngine and MIT’s Start), but in the end, the combination of YodaQA and Wolfram Alpha is “a match made in heaven,” as Falk said in an email a short while ago.

As a finishing touch to his work (being submitted as a diploma thesis), Falk made a Grand Challenge – letting an independent third party make a list of 30 factoid questions of varying difficulty, and pitching the PalmQA against a wide variety of humans. Perhaps not quite as dramatic or grandiose as IBM Watson’s Jeopardy participation, but still a nice showcase of where we are now.

Well, PalmQA did great! 26 people competed, and typically could get about 15 out of the 30 right. The best human answered 24 questions correctly. But no matter – PalmQA managed to answer 25 out of 30 questions right!

So, in this challenge, Falk’s ensemble-enhanced YodaQA beats the best human!

As mentioned above, PalmQA offers integration of YodaQA with Wolfram Alpha, Google QA, MIT’s Start, Amazon’s Evi and Kngine. We hope to merge this ensembling system into the YodaQA project in the future!

I also entered just plain YodaQA into the Grand Challenge, in the configuration that’s running at live.ailao.eu right now. It got 18 questions right, still better than an average human! If we also included purely “computational” questions (algebra, unit conversions) that YodaQA just isn’t designed to answer (it’s still essentially a search engine), that’d make 24 questions out of 30. Pretty good!

See the Grand Challenge Github issue for more info. We should get the complete details of the challenge, comparisons to other public QA engines (like Google) etc. in Falk’s upcoming thesis.

This is how the plain YodaQA fared:

Guest post by Petr Marek (source)

YodaQA learned how to use twitter during easter holidays. You can ask it by sending tweet with question to @askYodaQA . YodaQA will answer you shortly. How is it possible? I created app in the Googleâ€s App Script, which handles receiving question from twitter and answering them.

Why did I create it? YodaQA can reach more users in the new interesting form thanks to it. I believe they will help us to find even more ways how YodaQA can help them. It is pretty symbiosis. YodaQA will help twitter users, and they will help it back. Letâ€s look how it is made.

The two important tools

The most important ingredient was Googleâ€s App Script. It is basically JavaScript with the connection to Google services. You can make your own App Script apps in Google Drive. The best thing is that you can make triggers run the app every minute for example. And itâ€s for free.

The second thing you need is to create twitter app on account, which your bot will use to communicate with its followers. It will grant you access tokens, which you need to connect to twitter API. I used Twitter Lib for Google Apps Script to simplify the communication with API. It allowed me to tweet and get tweets with questions easily. You just need to call the right function with some arguments.

General idea behind

That was the tools that I used. But how did I make it work? I will describe the general idea now. I set App Script project to run my code every minute. The code does basically two things.

The first step is to obtain answers from twitter and to ask YodaQA. Bot searches all tweets with @askYodaQA. It saves the users that tweeted them and the time when it found the tweets. Then it sends the text of the tweet to YodaQA. YodaQA replies with dialog id and question id, which it saves to the list of questions.

The second step is to go through list of questions and to ask YodaQA for answers to these questions. Bot sends questions to users as soon as the answers are finished. You can even rely on features of the Hub, such as dialogs and coreference resolution. Two questions are connected to dialog when they are asked within five minutes interval.

I said that I save some information. Where? I used spreadsheet as memory. I use one sheet as “user memory”, the second as “asked question list” and the last as memory for the id of the last served tweet. I even log some information into a Google Docs text document. It may sound simple (and it is simple), but it works.

You can try it right now. Just tweet question with @askYodaQA and answer will arrive within few minutes. You can even use hashtags or mention other users. They will also receive the answer.

You can see the whole code on GitHub. You can use it and modify it for your own twitter bots too, maybe on your own data?

The openSUSE Project is awesome. We’re doing facinating stuff that is treading new ground in the world of Free and Open Source Software.
If you’re interested in how and why we’re doing this stuff, if you’d like to get involved, then this blog post is for you.
After reading you should have an idea of how we work and how to get started working with us.

• “How does the openSUSE Project work?”
• “Who decides what happens?”
• “What do you need me to do?”
• “How do I get started?”

How does the Project work?

The Project is a self-organised, self-governed, community working on the openSUSE Distributions (Tumbleweed & Leap) as well as various other Free and Open Source Software, including OBS, openQA, OSEM, Portus, Machinery, and more.

We have no Product Managers, Project Managers, or Community Managers.
We have no Technical Committees or Steering Groups.
For those who have read “The Cathedral and the Bazaar”, openSUSE is very much a “Bazaar” and hardly anything like a “Cathedral”. Whatever Teams we do have are self-organised by the members of those teams, with different ways of working together to accomplish whatever particular goals within the project they are working on.

The Project does have the openSUSE Board, who’s role is to ‘lead’ the Project by acting as a central point of contact and conflict resolution. In other words, they help keep everyone in the loop with what everyone else is doing, help resolve any conflicts that arise, and act as the ‘decision makers of last resort’ in situations where decisions need to be made and there is no one else available or willing to do so.
The Board is a little like the ‘A-Team’ - If you have a problem, if no one else can help, then the Board is there for you, either to help out, or help you find better help elsewhere. The Board is elected by the openSUSE Members, those contributors who have demonstrated sustained and substantial contributions to the Project.

SUSE are the primary sponsor of the openSUSE Project. All SUSE employees are encouraged to contribute to the openSUSE Project. These contributions are carried out as ‘peers’;
No special treatment is granted to SUSE employees, in fact the employer of a contributor should be irrelevant within the openSUSE Project.
In areas of particular interest or importance to SUSE, they may hire folk to work in particular roles within the openSUSE Project. With one exception (the role of Chairman of the Board), none of these roles should be considered exclusive to SUSE. There is scope for anyone to contribute to the openSUSE project at any level, assuming they are willing and capable to do the work.

Who decides what happens?

You Do.

We are driven by our contributions. If something is not being done, it’s because no one has decided to do it. We do our best to make openSUSE very accessible in order to make us the natural choice to be the Project through which you give your time & effort.

The openSUSE Project is structured the way it is to empower our contributors to really shape the direction of the Project. Also a significant amount of the tools we have as a Project exist in order to make those contributions easier. OBS and OSEM are obvious examples, but this is true in all aspects of the project, from the technical parts to the diverse range of other activities, marketing, advocacy, outreach, community, wiki, documentation, and more.

You don’t need to ask permission to get started, you just need to know what you want to do.

What do you need me to do?

You Decide.

Please don’t be terrified by this! To quote The Cathedral and the Bazaar:

“Every good work […] starts by scratching a […] personal itch.”
– “The Cathedral and the Bazaar”, Eric S. Raymond

Find things inside openSUSE, our Project, our distributions, our tools, our wiki, that you do not like, that affect you, that get in your way, and decide to change them.

While it may sound selfish, there is no better motivation than solving the issues which affect you first and foremost, the benefit of doing that as part of a community means your work ends up helping others, and others will in turn help you when they share that same itch that needs scratching.

Don’t expect someone else to do it. Don’t think it is someone else’s job to fix. It is your responsibility to help make openSUSE succeed in the areas that matter to you.

And don’t expect anyone else to tell you what to do or what needs doing - volunteers are rarely motivated when given orders from others, so that just isn’t typically the openSUSE way.
That said, I do believe we could do with having some indications of particular areas where we need help; The new openSUSE Mentoring website is a perfect example of something the Project now has to solve that problem.

In the highly unlikely event that you think everything is wonderful and there is nothing that annoys you, but you still want to give something back to the openSUSE project, then dig a little deeper, try something new, either technically in our products, or get involved in a new aspect of the Project that interests you.
I guarantee you’ll find something somewhere which could do with your help.

How to get started?

So, you’ve picked something to work on, how to get started. Here is my advice.

Do your homework

Make sure you understand the topic you are tackling. Dig through the problem to make sure you haven’t missed something.
Read our wiki pages on the topic. Use Google. Look at how other FOSS Projects deal with the problem. Is their solution better or worse than what you are thinking?
Talk to people who might know stuff about the topic, and bounce your ideas off them. Our IRC channels are a good place for such discussions, as are events like our openSUSE Conferences.

Plan your solution

You’ve decided what you want to do, now you need to decide how you intend to do it.
You don’t need to have all the details worked out, but you should have a clear understanding of the direction you want to go in, and how things should look when you are done

Do you need help?

Is this going to impact other people in a noticeable way? Do you want a second opinion?
If the answers to any of these questions are yes, continue to “Share with the Project”.
If no, skip to “Do It”.

Share with the Project

Take everything you have learned, and what you plan, and put it all together in a clear, succinct email for the mailinglists.
Avoid writing open ended questions. Despite everyone’s best intentions, coming to the Project with a question like “What do you think we should do about X?” will lead to either silence, or an almost infinite number of responses, many of which will disagree with you, often without proposing alternatives.
Write the email from the perspective of “This is what I think we need to do, and this is what I intend to do about it”.
Describe your findings from “Do your homework”, explain your plan. Include proof of concepts if you have them.
Post this mail to an appropriate mailinglist.
If you cannot identify an appropriate list, or you think the topic is deserving of a project-wide audience, then use either opensuse-factory@opensuse.org for technical changes, and opensuse-project@opensuse.org for everything else.
Once you are happy the email makes it possible for everyone else to understand the problem, and that this is your problem and you are going to solve it, fire away!.
Now it is the responsibility of everyone else in the Project to convince you that you need to do things differently.

Listen

The openSUSE Project is full of very clever people. Listen to their feedback, consider it.
As your proposal included your reasoning, their feedback should be equally reasoned and informative, and so even a ‘failure’ of a proposal at this point is a learning experience.
And that is a good thing, sometimes better than accomplishing the thing you set out to do in the first place.

Respond

Fast feedback drives innovation.
If people are giving you feedback, discuss back with them, tell them when you agree with what they’re saying, tell them when you disagree and why.
This is how you will find other people to work with you on this thing.

Decide

You do not need to accept all, or any, of the feedback.
If nothing comes up that convinces you to deviate from your plan, then carry on as you planned.
If something gets in the way, then work together to find a solution, either one that includes a compromise that everyone is equally unhappy with, or one where ‘both’ options are possible.
This is an aspect of the openSUSE community that we often overlook - when we have two sets of contributors wanting to pull in two different directions, our collective natural instinct is to often find a way of accomplishing both.
How else do you think we ended up with KDE, GNOME, XFCE, LXDE, Enlightenment, etc?
This is a good thing, makes our project reflect everything which our contributions want to work on, and something which really sets us apart from many other Projects out there.

Do it

You’re all set! Get to work. Start your engines! Time to inconvinience some electrons with your code! and don’t forget, Have Fun!

Talk about it!

Our statistics show that the openSUSE Project is on the up and up, and we are in many ways ahead of a great many similar projects who are often perceived as being more successful than us.
A big part of that is because we excel at doing stuff, and are lousy about talking about it.

So this is a call to action to ask that everyone reading this post keeps in mind the cool stuff that they’re working on as part of openSUSE, and talk about it.

Social media, conferences, meetups, whenever you get a chance, tell the world about what you’re doing. It is not just a case of being ‘Green and Proud’, but talking about recent successes often leads to conversations that reveal what the next challenge is, and so the cycle continues, but at least it’s a lot of fun ;)

You can start with this post. Please share it on Facebook, Twitter, Google+, Reddit, Hacker News and anywhere and everywhere else people might be interested in contributing to openSUSE.

openSUSE is amazing, it can be even more incredible, and we want YOU to help us shape it and make it into something even more special.

One of our great student interns at eClub/Ailao Petr Marek who also made the current YodaQA web interface is now working on adding a new element to our ecosystem – the Hub. This is an interface between the web app and the YodaQA system which takes care of various tasks that don’t fit a “pure question answering” system well. For example, it tracks dialog context or allows domain-specific question handling (if you want to add support for retrieving current traffic information, TV schedules or custom question transformations).

We see voice (and chat) as the perfect fit for question answering systems like YodaQA, and together with this, dialog comes naturally. This is why Petr M. has recently transformed our live QA interface to the dialog format (and it now goes through the Hub). The dialog tracking is internally still relatively simplistic from a scientific point of view, but it’s more than enough to already create a great impression. And right now, in a simple, tongue-in-cheek informal test, YodaQA does great compared to “competition”!

See the complete presentation!