பல நாட்களாக, ஏன் பல மாதங்களாக எனக்கு தமிழில் blog செய்யவேண்டும் என்று விருப்பம். ஆனால் SCIMஐ எனது laptopஇல் install செய்து, அதை செரிவர configure செய்ய இருந்த சோம்பேரித்தனத்தினாலே அந்த விருப்பம் நிறைவேராமல் இருந்தது. மற்றும் பல ஆண்டுகளாக தமிழில் எழுதாததால் என் தமிழ் அறிவும் குன்றி விட்டதோ என்ற அச்சமும் உடன் சேர்ந்து கொண்டது. இருப்பினும் இன்று எதோ டிடிரென்று தமிழில் எழுத வேண்டும் என்ற ஆசை அதிகரிக்கவே scimஐ நிறுவ முற்பட்டபோது தான் அறிந்தேன் அதை நிறுவும் முறையானது மிகவும் எளிதாக்கப்பட்டு உள்ளதை. அதன் எதிரொளியாகத்தான் இதோ என்னை தமிழில் எழுத காண்கிறீர்கள்.

இம்முயற்ச்சியை இதனோடு மட்டும் நிருத்திக்கொள்ளமல் மேன்மேலும் எழுத வேண்டும் என்று விரும்பி அதற்கான முயற்ச்சிகளை எடுக்க முனைவேனாக. தமிழில் எழுதி பல ஆண்டுகல் ஆவதால் இங்கும்அங்கும்ஏற்படும் பிழைகளை பொருத்து, அவற்றினை திருத்துமாறு வேண்டுகிறேன். இனி அவ்வப்பொழுது இந்த blogஇலேயே இந்த blogஇல் நான் எழுதிவரும் தலைப்புகளிலெயே தமிழில் எழுதவிருக்கிறேன். எனினும் முழுக்க முழுக்க சுத்த தமிழில் எழுதாமல், அதாவது சில terminologyகளை ஆங்கிலத்திலேயே எழுத முடிவு செய்த்துள்ளேன். உங்கள் உதவியும் ஊக்கமும் விமர்சணங்களும் எனக்கு துனைநிற்க்க வேண்டும்.

இப்படிக்கு,

தொழில்நுட்பபித்தன் (technofreak)

Tried wordle.net and here is the result of feeding in my blog RSS feed..

I have been always wanting to contribute to Ubuntu since the day I joined Ubuntu India Team. But, other things happening around me always kept me from converting this wish into action. It was this new year that I finally took a resolution to start some solid contribution to the Ubuntu project. The most viable options was to Ubuntu Bugs at Launchpad, which in better terms is the bug tracking system for Ubuntu.

The formal way to help with bugs (not formal as it literally means) is to join the bug squad, the team of ubunteros whose sole motive is to check bugs filed by the users, help the users provide as much information about their problem as possible, assign bugs to related packages, find earlier reports which is very similar or sometimes the same (duplicate bugs), assign status and importance for bugs and finally make it all ready for developers to work on them. This process also filters out reported bugs which are not bugs but user end mistakes, which are rather feature requests (wishlist) or merely misunderstood normal behaviors. In addition, we can also file patches for the bugs if we know how to fix them, which actually reduces a lot of developer time (which is precious).

So, where did I get started? Actually two places, one is Launchpad Bugs for Ubuntu and second is the bug squad team channel #ubuntu-bugs at irc.freenode.net. When I joined the team, the irc channel was both a place to discuss about bugs as well as where the bug announce bot was running, announcing the channel whenever a new bug was filed. Later, the bug announce was moved to #ubuuntu-bugs-announce channel, while #ubuntu-bugs became a complete discussion channel for the bug squad. Then I started reading the docs in the wiki, especially the following,

1. How to Triage
2. Debugging Procedures
3. Standard Responses
4. Bug Importance
5. Bug Status

Apart from reading docs, I started observing how triagers respond to bugs. When I got an idea of the basics, I started triage with some newly filed bugs, easy ones which I could make sense of from the description. All I did was find bugs where I can ask for more information from the reporter. This is the easiest way to start as most filed bugs lack in one information or another, and it’s the primary task of the triager to get as much information from the reporters as possible.

Most people miss out the Ubuntu version they are reporting the bug against, the related package for which the bug is filed and it’s version. These are minimal information required in the bug report. The next important thing is how complete and meaningful is the bug description itself. It is not uncommon for people to be in a tensed mood when they file bugs and their description is quite unclear about their problem. Minimal requirements of a good description are what is their problem and how to reproduce this problem. Some reporters also specify things they tried to fix the problem, and surprisingly sometimes this ends to be round about solution for the problem. Some people take more responsibility of getting into the problem, finding a fix and submitting a patch to the bug as well (which is amazing btw). Now bug triage doesn’t seem to be simple all together, but it offers various levels of participation fitting with one’s level of interest and skills. I know of a few in bug squad who are specialist in dealing with duplicates, which is nothing but a reporter filing a bug which already someone (or even many others) have filed already.

Filing a same bug doesn’t help much, rather what would be welcome is looking at existing bug and adding additional information to it if possible. Similarly, one can also check existing bugs and if the problem can be reproduced at our end we can indeed confirm the bug reported by someone else.A bug also gets confirmed when the triager feels that the bug report enough information for the developer to deal with it. There is no hard and fast rule, but some guidelines on what makes a report complete (which you can find in link 1 above) and is often acquired as a trait by experience.

There is not much for the basic level of bug triage. As I got involved doing these basic things, I started learning more. Sometimes I have done little mistakes, but as I always refer to people in #ubuntu-bugs for doubt, my mistakes got immediately corrected. Am still in the lower levels of bug triage, but learning a lot. One wonderful endeavour regarding bug triage is 5-a-day project started by Daniel Holbach. It is nothing but a team of bug triagers who make sure they at least triage 5 bugs a day. This has really been working and if you would like to see some stats check this one out.  One handy link for every new triager is the Checklist.

So, when can you join us? Anytime anyday and if you are looking for special time to join then Hug Day and Global Bug Jam could be a nice opportunity

I made it yesterday though it was late into the midnight, attending Kubuntu Tutorials Day at #kubuntu-devel. The session I was interested to catch up was the second one by Celeste Lyn Paul aka seele on Usability. I have heard about her, her work, KDE-HIG and openusability.org a few months ago after I attended the HCI workshop at IIT Bombay. The following are the brief notes from my scratch pad on what seele said during her session. Official logs from the Kubuntu Tutorials Day should be available soon (or am not yet aware of the link yet..) and will update when I get it.

( Questions from seele are in italics, with related links I managed to get by Googling and my own comments. A little bit of editing to make it look a bit “blog formal” and readable. Comments are welcome, especially if you find something wrong )

In 20 words or less, what do you guys think usability is? (and no cheating on wikipedia)

If we take this from an ISO standard, usability means that a product must be,
1.learnable
2. efficient
3. memorable
4. prevent errors, and
5. be satisfactory to users

Learnable
This is the one no one usually picks when i ask the “what is usability” question. A product (in our case software) doesn’t have to be so easy that you don’t have to learn it. For a simple task, then you expect it to be simple but for a complex task, it is OK to expect learning.

Efficiency
This probably shouldn’t be #2 even though it is listed in the ISO spec this way, because it is related to learnability and memorability. But it is exactly what the word means, an appropriate use of time and resources in relation to the complexity of the system. Even if you made a simple printing function an easy to use 10 step wizard, it isn’t very efficient if you need to do that every time you print. Clicking one button will get the same amount of work done than stepping the user through all the options and clicking 10.

Memorability
This is what I think should be #2 because it is closely related to learnability.

Have you guys ever heard of the term Information Scent? It is an Information Science Theory

Information scent is a search behavior theory. Information scientists believe we search using the “gathering” skills of our “hunter-gatherer” basic instincts. What it turns in to from a UI perspective is how easy it is to find information (functionality or options) from it’s surface presentation. So, what options you expect to be under menu X before you open menu X? By having good information scent (good labels, structure, etc.), you can use the UI more efficiently because you can stack layers of information.

Basically you are leaving hints to the user to find the information on their own, they don’t need to Remember where options are, but only follow a logical path. This saves the user’s cognitive resources to go on and solve more complex problems instead of using them on the UI. Remember that a UI is a tool to solve a problem, the UI shouldn’t be the problem.

Error Prevention
Have any of you guys heard of Jef Raskin?

He was a famous designer who worked at apple (i think he was employee #12 or something close). He was a true user advocate in the sense that he believed no matter what the circumstance, the computer should do no harm. Also, many of you are probably familiar with the practice of confirming actions, particularly destructive ones, yes? Error prevention is more than just confirming a destructive action. It is preventing the user from having to make that decision to start with.

We dont see this too much in the desktop environment because we model a lot of our work-flows off of existing software, but i see this a lot in other expert systems. “Are you really sure you want to do that? It will cripple the system and you will lose all of your data” (Well then, the user should have never been able to choose that option from the top level of a UI). Even so, there are a lot of confirmations we do in the desktop environment which could be prevented if we shaped the work-flow differently; the user should never have to select Cancel.

Satisfaction (keeping it consistent
Satisfaction is the quality many people tend to identify with usability. But it is also the last dimension in the spec (and i believe the least important of all we’ve talk about). Satisfaction is important. If a user finds a system pretty or cool, they will want to use it more than the other system that is not. Users will sacrifice ALL of the other parts of usability (learnability, efficiency, memorability, error prevention) for satisfaction. our goal is to help them not make sacrifices.

I’ve seen users in usability tests take 3, 4, 10 times longer to complete a task in a terrible UI that looked pretty, and complete the same task in a different not-as-pretty UI much much faster and they still like the pretty UI.This is an advantage and disadvantage: it gives us room to experiment because users will be forgiving if we give them options they want or other cool toys; but at the same time, we should use eye candy as a crutch to solve problems. We should solve problems and make our solutions beautiful.

Have you guys ever heard of a one-time learning event?
Often when you are reviewing a new UI or work-flow, one of the questions you may ask yourself is “will the user figure this out”; and the first time around, sometime the user doesn’t. they can’t find the options, they don’t know the label, they can’t figure it out. But,if they have someone show them how to do it, they find the solution on a webpage, or painfully figure it out, it makes sense to them and they remember it for next time. We call this type of experience a one time learning event

They won’t figure it out the first time, but if they can do it once, they will remember how to do it. This is something that is often forgotten in UI design. You can break users out in to different dimensions - one of them being problem solving skills and related motivation, some users are not afraid to try something and fail, other users will not try new things in fear of failing and the users who do not explore are at risk of never exploring options hidden behind a single-learning event.

That’s why doing user research on your product and understanding who your users are, their motivations, environment, and their skill (it’s not JUST about their skills) is important. This leads me in to a discussion about universal usability.

Has anyone heard this term “Universal Usability” before?

Universal Usability is the belief that any user, no matter their skill, background, motivation, experience, etc. should be able to pick up and use a product. In cases where products must serve the general public (such as e-voting machines), this could be a valid argument, but there are very few products that focus on EVERYONE. Even so, the concept of universal usability would be extremely difficult to achieve, especially in expert systems or systems which knowledge workers use

The ipod, why does everyone use that as an example of universal usability? The ipod is an excellent example of very sexy tech that people forgive its shortcomings for. It doesn’t do everything everyone wants, and not everyone can use it or figure it out, but because it is so damn beautiful, most people don’t care.

Universal usability forces designers to lower the bar of the average user to accommodate more people. This is why it hurts expert systems. If there is a pocket of experience or information that a certain group of users may not have or be able to attain, it must be removed.

[ To a question about apple and the point mentioned above...]
Yes, but apple traditionally does not follow a user-centered design approach. they believe that designers know better. It’s only been recently that they’ve done usability testing.. everything before was market research (which is very different).

[ We seemed to digress a bit, so I tried bringing it back on track with question :P]
There are three domains of usability i work in: User Research, Design, and User Testing. Together, these are part of the user-centered design process (UCD). It is a design philosophy which keeps users in mind while creating a system for them.

User Research is often linked to the Requirements stage of software development. So when you developers are thinking of new features to integrate in to a software, or a new software to develop from scratch. Here are some things you should be thinking of in addition to your functionality spec and other things,

Who are your users?
Try to come up with some example users who you are building the software for. Even if you are a user, try to keep yourself out of the list, it makes it too easy to do what you want instead of what they need.

What will you users be doing too many times?
Not all of the functionality is documented or fully planned. A single function might be discussed and mapped, but the other functions of a system aren’t thought of until afterwards. What happens is you don’t have a complete picture of how your users are using the system, and if the functions are integrated properly mapping out screen flows before you begin coding will help document your functionality (so you aren’t trying to squeeze or force options in later) and give you a reference for when you code.

What problem are you trying to solve?
This is the big one, your Vision Statement. Having an idea of your goals before you start will help development. It is related to the “What are my users doing?” question. If you don’t know what problem you are trying to solve with your software, you can’t know what to provide users or what they will expect? Plus, in larger projects, it is a good idea that all the developers are on the same page. It prevents a lot of road map issues later on

Being able to answer those three questions will give you a head start. On KDE Techbase there are user research templates to help guide you.

I guess we will get in to Open Source Usability 101 now,

First step: Contact the project you want to work with and express interest in working with them.
You dont want to surprise developers by dropping a usability report in their inbox. It will just make them angry, even if the work was good.

Second step: Start small. Open source is a community based on commitment and trust (after the getting work done thing).
Start with a small activity such as interviewing users, conducting a survey, or doing a small UI review. This will help developers get used to your methods, get used to you, and know what to expect from your work.

Third step: Maintain your relationship with the project.
Design is an iterative process, just as open source is iterative development. Developers are wary of seagull designers: designers who fly in, poop on their software, then fly away. Developers are in for the long hull, they are committed to their project and want to see it succeed. They don’t want to work with a designer who will ask them to change a bunch of things, then disappear and not be able to comment on the results.

Obviously I don’t want to see any unhealthy marriages, but keep in mind that you will make a bigger difference in one project than doing a bunch of little activities for a bunch of projects. Design is a VERY iterative process; it is important for both you the designer and the developer you work with to understand this.

[ To my question whether we have something similar like KDE-HIG in Ubuntu/Kubuntu to which we can contribute.. ]
For Ubuntu designers, you will want to look at the GNOME HIG. It might be a little out of date, but one way to get started with contributing would be updating it!

For Kubuntu designers, you will want to look at the KDE4 HIG and the KDE3 User Interface Guidelines.

These are under active development, and so if you have any questions it would be best to ask me or Ellen Reitmayr who sometimes lurks in #openusability.

Other Resources:
Look at other interfaces that do similar things, not just in your own environment but in windows, KDE/GNOME, Mac OSX. You’ll find similar and very different solutions. You will want to look closely at the context of the solutions and make sure it is a good fit before you use it as a mode. Copying a solution will not solve a problem, the goal of reviewing other software is to get inspiration when you have no other better ideas.

[ The End - Applauds!! ]

In the below shown screenshot, the emacs window has 3 emacs-windows within it. Try to find the similarity between them Reward == *free* **hugs**

Kushal came down with a simple looking problem with constraints that might make solving it a bit not-a-needle-into-the-banana. As usual, me and Jacob sat down trying to solve it. Rather try finding various ways of solving it. The problem is, given one character within the range a-z or A-Z (not as a list, but from string.letters) we have to find the next character in the alphabetical order. When ‘z’ or ‘Z’ is encountered, the next alphabet returned should be ‘a’ or ‘A’ respectively. The constraint is that if or while conditions and for loops should not be used. And more importantly, the main solution should be of a single line. Though Kushal had a more mathematical solution, this is what me and Jacob managed to cook up as a more logical solution (note the ‘and’ and ‘or’ ),

import string

def thenext(theletter):
    return ((string.letters.find(theletter)+1) %26) and (string.letters[string.letters.find(theletter)\
+1]) or (string.letters[string.letters.find(theletter)-25])

print "for 'a' i get: "+thenext('a')
print "for 'g' i get: "+thenext('g')
print "for 'z' i get: "+thenext('z')
print "for 'A' i get: "+thenext('A')
print "for 'H' i get: "+thenext('H')
print "for 'Z' i get: "+thenext('Z')

The solution looks like..

for 'a' i get: b
for 'g' i get: h
for 'z' i get: a
for 'A' i get: B
for 'H' i get: I
for 'Z' i get: A

According to what Nielsen says, the average size of web sites have gone up making them fatter and fatter in the last few years. On the other hand, people’s response times have come down to 2.3 seconds per page.

Still he feels that half of the world doesn’t have faster broadband access and hence web sites need to be slimmer, simpler and easier to browse through, and such websites will get more attention than fatter but slower websites. We need to achieve a response time of 1.0 seconds for an optimal user experience.

As we all know, once the inter web was filled with web sites containing big images which rather distracted us. It has moved to a web2.0 era and been replaced with widgets. This hasn’t improved things anyway, still the web sites are slower and distractive a lot. The only way to attain the ultimate interactivity is to have sites which load up faster and are more easier to navigate around. If the user has to search on how to reach the next page or the previous, especially in his first encounter, he rarely returns back to the site again.

Heard about this wonderful little GNOME app called Tasque from nixternal’s blog post today, checked it out (mean the web site) and found it useful. May be I will try it out soon, not now because I am not having much tasks to do and whatever I have is reminded by ReminderFox in ThunderBird. Good thing is it is available for both Hardy and Gutsy (thanks to nixternal) from tasque-packagers’ PPA.

This is what happens to my desktop when twhirl starts everyday..

These pop-ups stay on top for a few seconds and then vanish with a small vibration effect. The green colored pop-ups are actually direct replies to me, some even a month old. I actually do not check the pop-ups as they are too many in numbers and most of them too old.

On turning up at office on Tuesday, after a 3 day holiday, heard about the problem blowing out here and there in our kiosks due to a broken package in our repository. Thankfully it was happening only with our ongoing new rollout image which was installed in around 80 kiosks in Karnataka. We decided to make a field trip and asses the situation, find a fix that can be executed in the affected kiosks with the help of the field engineers and operators itself. Our earlier plan of making the trip on Tuesday evening itself was dropped as it would have been too late when we could reach even the nearest affected kiosk.

We started the field trip around 8 a.m. on Wednesday, getting a cab to take us around. This will help us in visiting as many kiosk as possible in a day. We started with a 2 hour travel to Yadiyur near Kunigal falling under the Tumkur district. The cab driver suggested us a nice hotel in Kunigal, where we had plate-idlis, vada and tea before continuing our journey.

The Yadiyur kiosk is located right in front of the cattle market of the village. We started hunting for the bug which caused all the mess and soon found it to be an extra netmask line in the network interfaces file. Removing this line and rebooting the machine brought the network up and the machine started to operate normally. But when we tried the second machine, it was more than this. The firewall seemed to have messed up during the upgrade, so we needed to clean it, then clean the interface file and bring up the system back. We also started calling up the field engineers, asking them to go to the nearest problematic kiosk and guide them to perform the same fix we found.

Having found the fix, we wanted to test it again. So we next moved to our kiosk in Maisandra, which is some 20 Kms from Yadiyur. We had a bit of trouble in finding the kiosk as it is located in a building interior to the main road. The kiosk was small but neatly maintained. We fixed the first machine following the same procedure, but the second machine did not face the updates because of lack of network switch to connect both the machines and hence it was still unaffected. We finished our job and left to the next location, but it was already afternoon.

Our next location was Huliyurdurga, which is on the other side to Yadiyur and it took us almost an hour to reach. We again had problems locating the kiosk as the name board is not put on the building it is located at and people could not get a clue of what we were searching for. Thankfully the operator was standing out in front of the building, could spot our car and I could spot her waving. We quickly fixed the first machine, made it operational as customers were waiting and moved to the second machine. With some extra effort, we managed to fix it too.

We were hungry and decided to feed us with some snacks from the bakery. We decided not to visit the next kiosk Tiptur as it was very far and it was already 5 p.m. We started our way back to Bangalore and after crawling through the traffic around Nelamangla and Yeshwantpur, we reached office by 7.40 p.m.

We have learnt our lesson that we need more stricter Q.A. process and more rigorous testing before we update our stable repository next time. When we were in the kiosk, probably a hour or two at each location, there were indeed customers turning up at least once every hour On the whole, it was a nice day of traveling through rural Karnataka and visiting few more of our kiosks.

While reading the latest issue of Full Circle Magazine today, I came across the Game section and was surprised to know Maryo was available in the Ubuntu Universe repository. The package is named smc, short form of Secret Maryo Chronicles. I downloaded it (some 41MB totally) and went running it. Unfortunately, it doesn’t get added in the menu. So I had to manually add it and also set its icon.

Always I have the habit of running a newly installed software from the terminal to check whether it spews some error or not. So did smc, there was some dependency error confirming to this launchpad bug. Luckily some one had prescribed a fix that makes it work. Had some fun playing Maryo after a long time. Hope they fix the bugs and we get a really super Maryo game in Hardy.

Due to unforeseen circumstances, personal reasons, financial crunch and “leave” reasons, am not going to join the party at FOSS.NITC this time. It was fun last year with pradeepto, kushal, aanjhan, vivek, jace, kiruba, atul, shreyas, tejas, praveen and lot of known faces joining for a promising FOSS meet. This year, a majority of the tribe will go missing. I fear this was mainly due to the postponing of the schedule a couple of times, from feb end to march end and again to april first weekend.

For me with little penny left in my pocket, mother to be taken back home and morally can’t take successive weekends off from work, I mailed them that am dropping off. They felt so bad, am sorry, so did I. Hope you still rock on this year and we all can join you next year. Good luck!

The title looks interesting, so does the 3 things. First the meet, which happened this weekend. Hobbes` had called for a welcome meet for Kartik moving to Bangalore. We had originally planned to have it in South Indies, Indira Nagar but due to unavailability of  seat we  moved to Tangerine,  just on the opposite side. As the man of the meeting rather went to talk about Debian in some college, we still decided to carry on the party. The #linux-india meet was attended by moi, Hobbes`, tuxplorer, vegpuff, shastri and his friend (forgot name/nick).  The place was nice and the food was nicer. I tried my first hand on a cheesed vegetable steak sizzler and it was awesome. The meeting lasted around a couple of hour, with people trying to find what BLUG was/is and Hobbes’ suggesting that we reactivate linux-india mailing list as the primary list. Then we had a small chat about bikes (not the ones with motor, but the ones with pedals) before we started fining our way back home.

Now to the misery. Summer has started in Bangalore and so does the water problem. We were originally getting Cauvery water filling up the sump directly. Now it got stopped and we have to fetch water from the common water tap in the area. As a single water tap is shared by a dozen houses, each house gets a limited volume of water which has to be further shared by the various tenants. What our owner does is get the water and pour it into the sump, then use motor to pump it to the overhead tank, which finally comes in our taps. Though this idea sounds logical, it doesn’t seem to be practical. The water doesn’t come before I leave to office, hence am not there when it comes. Second, once the limited water gets to the over head tank, you have to be quick in filling up your storage vessels otherwise you will be left without water. As am not there when the water is in the tank, am left without water. Even if am there, I manage to get only one or maximum two buckets of water. This has to be shared between two for all purposes. Third, since there is no water in the tank, my water heater doesn’t work. So no hot water supply, unless I manually boil water in the stove. Life has started sucking, and I have 3 more months to pass before summer ends.

Time for the mess. Someone posted a bug (bug #18395 on BBox, which is surprisingly listed under project’s section for Ubuntu India Loco Community in Launchpad. Thus, the team automatically got subscribed to it and the whole junta who were in the team got the bug mail. This resulted in half of them wondering why they got the mail and replying back to it. Their response lead to cumulative effect of mails and ended up as a major spam. It also resulted in half of the people who were in the team to realize that they have no reason to be in the team, resulting in an unjoin spree. When I poked people for help in #ubuntu-bugs, even the bug control guys reported the bug to be not visible to them. Then we found out that some one made it a security issue. I wonder who did all these things, messing up everything in the pipe line. Please people, do not panic on such an issue, poke around the team and find out if some one is trying to fix it out. If not, ask them to. Phew!

If I was one among the mass of outsourcing fed code monkeys, it would have been a trip outside India. As I was lucky to work for an Indian company operating rural business centers in rural parts of Karnataka I was blessed with a chance to visit the urbanized rural part of Bangalore, around 15 kilometers from our office (not sure, just a guess).

It wasn’t a planned visit, at least for me and my team. We had a deployment plan for today and a couple of guys were to visit th kiosk for deploying. As most of my colleagues were interested in joining them and as we had an extra car to ferry us, we all decided to go to the kiosk. We left office in two cars an hour before our usual lunch time (hence most of us were hungry too) and reached the kiosk in half-an-hour or so. There was a small hotel opposite the kiosk, so most of us grabbed our lunch from there. Jacob and me trying raagi muddhe (with jace telling some personal horror stories about the experience of eating it), while others resorted to chappathi.

We had quite a nice time in the kiosk, finding various issues which we had not thought about especially the usability ones. This has given us some more insights about real situations in the kiosk and how we have to improve our systems to counter it. We also had a fun time with 7 out of 9 from our team being there.

We were done with the deployment by 3 p.m. and 5 of us left a bit earlier back to office. In the way, jace told about the food street and others wanted to go there for an afternoon snack. We ended up having the Gulkand icecream and Masala pepsi. One other important thing about this trip was, jace used his GPS device to track our entire route in the map which can now be uploaded after making some minor edits. Thus, we ended up in a surprise field visit and food street visit today

* Kushal, we all missed you a lot

My 5 today: #127274 (hal), #199362 (synaptic), #59397 (xfce4-session, hal), 33794 (hal), #199358 (nautilus)
Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day

What is 5-A-Day?
We, that means everybody, will do 5 bugs a day - every day. With only
five bugs that everybody looks at every day, we will cover a lot of ground.

What you can do? That's up to you, your interests and your abilities.
 - If you're a developer, you can help out reviewing patches and getting
them uploaded.
 - If you want to just confirm new bugs, you can do that.
 - If you have experience with a certain package and want to triage bugs
you can do that and forward them upstream if necessary.
 - If you know your way around Ubuntu quite well, you can help assign
bugs to the right package.

What you need to do to participate?
 - Do it! Follow the instructions on the 5-A-Day homepage
 - Spread the word by adding your 5 a day to your mailing list posts I have been trying my best to triage 5 bugs a day, but max I could do was 3. Hope I can try better in future.