Check the full program here, and if you plan to come, register here. My endless thanks to the e.V. for sponsoring my travel. I hope to be able to pay for part myself this year, to spare the expense.
So much happens; I hope to see you there!
Monday, June 3, 2013
Weeeeeee, Akademy!
This year for the second time I’ll be able to attend Akademy, the annual world meeting of the KDE community. We'll be in Bilbao, in the Basque country of Spain from 13th to 19th of July.
Check the full program here, and if you plan to come, register here. My endless thanks to the e.V. for sponsoring my travel. I hope to be able to pay for part myself this year, to spare the expense.
So much happens; I hope to see you there!
Check the full program here, and if you plan to come, register here. My endless thanks to the e.V. for sponsoring my travel. I hope to be able to pay for part myself this year, to spare the expense.
So much happens; I hope to see you there!
Friday, May 24, 2013
Catalyst Leadership
I read a list post thread tonight that saddened me. I won't say what community it is part of, or point out the participants, because it is far too common in many of our community meeting places, whether they be lists, IRC or forums. Stereotypes are used rather than names here.
Newperson speaks up, I think for the first time, wondering when a new project result will be put to use, and offering a possible sample.
Longtime Devel speaks up, using rather angry questions about how the old symbol came to be displaced.
Another Oldtimer speaks up defending the symbol, accusing Longtime Devel of being out of touch.
And on. And on. The listowners don't redirect the discussion, and when questions are asked, they are answered angrily.
Newperson probably has departed by this point.
This seems like a small occurrence, but it is bad for every single participant, and each bystander has the power to change the conversation at each point.
This blog is a call for each of us to think about our power to influence the community spaces we inhabit, to exercise leadership, to become a catalyst for dialog, to open up trust. When I was first asked to become an IRC channel operator, I was asked to read the Freenode Philosopy: Catalysts. Whether or not you use IRC, I recommend reading this page to change your thinking about how you interact with others in your free software project. In fact, these ways of thinking about personal interaction would transform business, education and politics if put into wide use.
We know that bullying in schools can be brought to a stop by bystanders who show the courage to immediately speak up on behalf of the victim, and walk away from the confrontation. While I don't want to label those who use abusive language as bullies, we can transform tense situations in similar ways by speaking up in a positive, calm manner, as outlined in the Catalyst page.
Labeling people as trolls doesn't defuse the situation, or create an atmosphere of trust and dialog.
Please folks, if you are in an IRC channel, on a list, or help out on a forum: read the Catalyst page, and remind yourself often to be the change you want to see in the world. You don't need to be an op, a listowner, or a moderator, to be a leader; bloom where you are! Our Codes of Conduct aren't bludgeons to be used against evildoers; rather they are guides to our everyday interaction with one another.
Newperson speaks up, I think for the first time, wondering when a new project result will be put to use, and offering a possible sample.
Longtime Devel speaks up, using rather angry questions about how the old symbol came to be displaced.
Another Oldtimer speaks up defending the symbol, accusing Longtime Devel of being out of touch.
And on. And on. The listowners don't redirect the discussion, and when questions are asked, they are answered angrily.
Newperson probably has departed by this point.
This seems like a small occurrence, but it is bad for every single participant, and each bystander has the power to change the conversation at each point.
This blog is a call for each of us to think about our power to influence the community spaces we inhabit, to exercise leadership, to become a catalyst for dialog, to open up trust. When I was first asked to become an IRC channel operator, I was asked to read the Freenode Philosopy: Catalysts. Whether or not you use IRC, I recommend reading this page to change your thinking about how you interact with others in your free software project. In fact, these ways of thinking about personal interaction would transform business, education and politics if put into wide use.
We know that bullying in schools can be brought to a stop by bystanders who show the courage to immediately speak up on behalf of the victim, and walk away from the confrontation. While I don't want to label those who use abusive language as bullies, we can transform tense situations in similar ways by speaking up in a positive, calm manner, as outlined in the Catalyst page.
Labeling people as trolls doesn't defuse the situation, or create an atmosphere of trust and dialog.
Please folks, if you are in an IRC channel, on a list, or help out on a forum: read the Catalyst page, and remind yourself often to be the change you want to see in the world. You don't need to be an op, a listowner, or a moderator, to be a leader; bloom where you are! Our Codes of Conduct aren't bludgeons to be used against evildoers; rather they are guides to our everyday interaction with one another.
Monday, May 20, 2013
Why we do this crazy thing we do
Looking through a nice blog by Andreas Schilling, I found this classic linked:
It catches very well why we're here, and perhaps why you are reading this blog.
Also, if you are mentoring in GSoC or Season of KDE this year, remind yourself what motivates you and your students, both. We all want to make the world a better place.
Saturday, May 18, 2013
The water we swim in
Healthy relationships. I've been thinking about them not in my personal life, but in terms of teams in free software. When I first began contributing, it was within a team creating an application (Amarok), so rather small. Then I became active in Ubuntu-Women, which is larger, but still not huge. Then Kubuntu, then the larger Ubuntu community, and now KDE, which is truly enormous.
In all of these projects, communication and trust are paramount. Dialog which fosters creativity and progress is only possible when people enlarge their trust in one another. Along the way to the highest trust levels, many barriers will come down, as people allow them. Sometimes these barriers are invisible, until someone points them out.
I thought I'd seen a cartoon illustrating this story, but a web search tells me it's a story by David Foster Wallace:
So how is the water? To me, the drama played out completely predictably, because any time you have one company selling a product, and volunteers working in that same project, you will have class issues, and class is like the water fish swim in. People are often not aware of it, and thus have difficulty dealing with their emotions around it, because they have been taught to ignore it, or even that it doesn't exist. So when the designers removed the link, it was felt as a slap to the face of community members, while the designers see it as just a step to a clean, functional design. The conversation about this change at the recent vUDS clearly betrays this lack of understanding of the other on all sides. http://summit.ubuntu.com/uds-1305/meeting/21740/community-1305-ubuntu-website-planning/
There is no such thing as a culture without class. There are always power imbalances, and privileges. However, that doesn't mean that class is the death of the Ubuntu project, or that volunteers and companies can't happily co-exist. They can, but the fact of class must be acknowledged, and those with privilege and power must realize what they have, and use them on behalf of the project.
A healthy culture has hierarchy, but not one based on domination. In fact, in FOSS that is part of what we are attempting to dislodge, right? We want our hierarchies to be constructed for function, not to rule over us. For instance, those who demonstrate their skill in packaging or coding are given the right to upload to the repositories. And those who grant them that right are those who already have built their reputations by using their skill and trustworthiness in that domain.
Recently there has been a breakdown -- or an apparent breakdown -- in that hierarchy of function in Ubuntu. And I think that both those inside Canonical and those outside, perceive that the other is the one causing that break. So, some repair is needed.
All of our differences can be overcome as we build (or re-build) trust. However, all sides of the issue will need to think about, process emotion about, and finally discuss openly what has gone on. The replacement of the Community link alone will not mend this breach, nor will brief virtual UDS sessions. In fact, I think the lack of in-person face-to-face interaction is allowing this divide to grow.
Folks, we don't want resentment and suspicion to grow, so we are all going to need to work on this if the Ubuntu project is going to continue to thrive as a free software enterprise. In my opinion, thinking about and discussing class issues are fundamental to that effort.
This blog appears on the Linuxchix, KDE and Ubuntu planets, and these issues of class appear in all teams. Health and progress are the goal, and honest dialog is the means. I propose we look one another in the eye and start a conversation. These are difficult dialogs, but our health is at stake.
In all of these projects, communication and trust are paramount. Dialog which fosters creativity and progress is only possible when people enlarge their trust in one another. Along the way to the highest trust levels, many barriers will come down, as people allow them. Sometimes these barriers are invisible, until someone points them out.
I thought I'd seen a cartoon illustrating this story, but a web search tells me it's a story by David Foster Wallace:
Two young fish meet an older fish, who asks them “How’s the water?” The younger fish look at each other and say, “What the hell is water?”I was reminded of this story recently while observing the various reactions to the removal of the Community link on Ubuntu.com, the portal to the Ubuntu project. The link is coming back, so I'm not complaining. However, what I've noticed is that most of the people discussing the issue seem to be talking past the folks they are hoping to connect with. The emotions expressed range from puzzlement, to shock and outrage, with little understanding on the other "side" on the perceptions causing these reactions.
So how is the water? To me, the drama played out completely predictably, because any time you have one company selling a product, and volunteers working in that same project, you will have class issues, and class is like the water fish swim in. People are often not aware of it, and thus have difficulty dealing with their emotions around it, because they have been taught to ignore it, or even that it doesn't exist. So when the designers removed the link, it was felt as a slap to the face of community members, while the designers see it as just a step to a clean, functional design. The conversation about this change at the recent vUDS clearly betrays this lack of understanding of the other on all sides. http://summit.ubuntu.com/uds-1305/meeting/21740/community-1305-ubuntu-website-planning/
There is no such thing as a culture without class. There are always power imbalances, and privileges. However, that doesn't mean that class is the death of the Ubuntu project, or that volunteers and companies can't happily co-exist. They can, but the fact of class must be acknowledged, and those with privilege and power must realize what they have, and use them on behalf of the project.
A healthy culture has hierarchy, but not one based on domination. In fact, in FOSS that is part of what we are attempting to dislodge, right? We want our hierarchies to be constructed for function, not to rule over us. For instance, those who demonstrate their skill in packaging or coding are given the right to upload to the repositories. And those who grant them that right are those who already have built their reputations by using their skill and trustworthiness in that domain.
Recently there has been a breakdown -- or an apparent breakdown -- in that hierarchy of function in Ubuntu. And I think that both those inside Canonical and those outside, perceive that the other is the one causing that break. So, some repair is needed.
All of our differences can be overcome as we build (or re-build) trust. However, all sides of the issue will need to think about, process emotion about, and finally discuss openly what has gone on. The replacement of the Community link alone will not mend this breach, nor will brief virtual UDS sessions. In fact, I think the lack of in-person face-to-face interaction is allowing this divide to grow.
Folks, we don't want resentment and suspicion to grow, so we are all going to need to work on this if the Ubuntu project is going to continue to thrive as a free software enterprise. In my opinion, thinking about and discussing class issues are fundamental to that effort.
This blog appears on the Linuxchix, KDE and Ubuntu planets, and these issues of class appear in all teams. Health and progress are the goal, and honest dialog is the means. I propose we look one another in the eye and start a conversation. These are difficult dialogs, but our health is at stake.
Friday, May 17, 2013
Tea and cookies for your new team members
What does every development team want? New contributors!
I'd like to suggest a simple process that can turn visitors to your website, list or IRC channel into a successful part of the development team. When people actually contribute, they quickly feel like a valuable part of the group. New people bring fresh energy, and new ideas.
At your next sprint or meeting, start dreaming. Is your user documentation well-written and up-to-date? Do you need promotion, or video guides? How about art or diagrams for your website? Speaking of your website, when was the last time all the links were tested, and it was checked for spelling and grammar? Create a nice, friendly list of tasks for your newcomers.
Could your codebase use some grooming, for common misspellings, for instance? (EBN is a great source for these). When you run across a bit of code which needs pruning or refactoring, or normalizing signal-slot stuff, the easy thing is to fix it while it's in front of your eyes. Instead, consider which of these small tasks can be filed as a "Junior Job", created for the purpose of getting those knowledgeable people to move from faithful user, to part of the team.
The Bugsquad and Quality Control teams can likely suggest more ideas, too.
KDE Junior Jobs can be easily found: http://kde.org/jj. Teams can create their own shortcut links too, such as Amarok has done, listed in the #amarok IRC channel topic: http://tinyurl.com/amarokjjs. Other tasks can be blogged about, posted on a trello, on the Community wiki; whatever your team likes to use. For more ideas, see http://community.kde.org/Getinvolved.
The Kubuntu team has a list of tasks in Trello, which works well.
So, when you feel like not fixing a little issue, don't feel lazy. Feel responsible! File a bug, make it a JJ, and call attention to those issues when new folks show up and ask, how can I help?
PS: Thanks to the #kde-www team for suggesting this blog. Einar77, neverdingo, mamarok; you are wonderful.
PPS: How LibreOffice does it: https://wiki.documentfoundation.org/Development/Easy_Hacks
I'd like to suggest a simple process that can turn visitors to your website, list or IRC channel into a successful part of the development team. When people actually contribute, they quickly feel like a valuable part of the group. New people bring fresh energy, and new ideas.
At your next sprint or meeting, start dreaming. Is your user documentation well-written and up-to-date? Do you need promotion, or video guides? How about art or diagrams for your website? Speaking of your website, when was the last time all the links were tested, and it was checked for spelling and grammar? Create a nice, friendly list of tasks for your newcomers.
Could your codebase use some grooming, for common misspellings, for instance? (EBN is a great source for these). When you run across a bit of code which needs pruning or refactoring, or normalizing signal-slot stuff, the easy thing is to fix it while it's in front of your eyes. Instead, consider which of these small tasks can be filed as a "Junior Job", created for the purpose of getting those knowledgeable people to move from faithful user, to part of the team.
The Bugsquad and Quality Control teams can likely suggest more ideas, too.
KDE Junior Jobs can be easily found: http://kde.org/jj. Teams can create their own shortcut links too, such as Amarok has done, listed in the #amarok IRC channel topic: http://tinyurl.com/amarokjjs. Other tasks can be blogged about, posted on a trello, on the Community wiki; whatever your team likes to use. For more ideas, see http://community.kde.org/Getinvolved.
The Kubuntu team has a list of tasks in Trello, which works well.
So, when you feel like not fixing a little issue, don't feel lazy. Feel responsible! File a bug, make it a JJ, and call attention to those issues when new folks show up and ask, how can I help?
PS: Thanks to the #kde-www team for suggesting this blog. Einar77, neverdingo, mamarok; you are wonderful.
PPS: How LibreOffice does it: https://wiki.documentfoundation.org/Development/Easy_Hacks
Monday, May 13, 2013
New to the commandline? Don't lose heart
Beginners, you are not alone! Many of us have tried to work through problems, only to be stymied when the steps to work through the problem don't work, and efforts to google those error messages yields nothing helpful. In fact, that's why I started this blog; not just to remind myself how to fix various problems, but to point the way to others who are trying to learn the way to CLI-foo.
A word to the wise who are trying to help beginners -- please don't leave out "obvious" steps!
I'll illustrate with a recent experience I had, trying to help a user work through a problem using Krusader. A bit of googling told me that s/he wasn't alone; there are bugs filed on both launchpad[1] and bugs.kde.org[2]. First, kudos to the unnamed person for asking for help in IRC. That's an excellent place to get step-by-step help.
In the launchpad bug, a helpful person posted a series of step to fix the bug by building an updated version from source:
Step zero, uninstall, is unambiguous. So far, so good.
Step one, download source, leaves out the best practice, which is to create a directory into which you want your source file! Probably not specified as people have their own schemes of organization, but in general, I advise a ~/kde folder into which I put all source files and builds (thank you for your advice on that, Myriam!)
So step one should be: a) open a konsole, and type or paste: mkdir kde && cd kde && mkdir krusader && cd krusader && wget http://downloads.sourceforge.net/krusader/krusader-2.4.0-beta3.tar.bz2
Then, step b) tar xf krusader-2.4.0-beta3.tar.bz2
Then, do step two, which is correctly stated as cd krusader-2.4.0-beta3
Step three is almost all there, with a missing note: be sure you have cmake installed! My bet is that my troubled user did not.
Cmake ran uneventfully, as did make, so steps three and four are perfect. Step five, however, does not work at all for me, because I don't have checkinstall installed. And I don't think I'll do that for the sake of finishing this blogpost! I don't need a deb file, when Krusader is available from source.
I hope our Kubuntu packagers will get the newest version packaged soon, and make it easy for my troubled user.
1. https://bugs.launchpad.net/ubuntu/+source/krusader/+bug/1065110
2. https://bugs.kde.org/show_bug.cgi?id=294542
A word to the wise who are trying to help beginners -- please don't leave out "obvious" steps!
I'll illustrate with a recent experience I had, trying to help a user work through a problem using Krusader. A bit of googling told me that s/he wasn't alone; there are bugs filed on both launchpad[1] and bugs.kde.org[2]. First, kudos to the unnamed person for asking for help in IRC. That's an excellent place to get step-by-step help.
In the launchpad bug, a helpful person posted a series of step to fix the bug by building an updated version from source:
Made my own deb from 2.4.0.beta3 which solved the `krarc` problem.The unfortunate user came back into IRC, and posted this error message:
How to:
0 Uninstall Krusader
1 download source from http://www.krusader. org/
2 cd krusader-2.4.0-beta3
3 cmake -DCMAKE_INSTALL_ PREFIX= /usr/ -DQT_INCLUDES= /usr/share/ qt4/include
4 make
5 sudo checkinstall
Don´t forget in step 5 to set version on 3 instead of beta3, only digits are allowed in versions in debs nowadays.
xy@xy-ubuntu:~/Downloads$ cmake -DCMAKE_INSTALL_PREFIX=/home/user/app/krusader-2.4.0-b3-2 -DQT_INCLUDES=/usr/share/qt4/includeHaving struggled through this process myself, I see what's missing in the instructions. The person posting them didn't realize, I'm sure, that steps were being left out, because they have become automatic. To a beginner, they are bewildering.
CMake Error: The source directory "/home/jony/Downloads" does not appear to contain CMakeLists.txt.
Step zero, uninstall, is unambiguous. So far, so good.
Step one, download source, leaves out the best practice, which is to create a directory into which you want your source file! Probably not specified as people have their own schemes of organization, but in general, I advise a ~/kde folder into which I put all source files and builds (thank you for your advice on that, Myriam!)
So step one should be: a) open a konsole, and type or paste: mkdir kde && cd kde && mkdir krusader && cd krusader && wget http://downloads.sourceforge.net/krusader/krusader-2.4.0-beta3.tar.bz2
Then, step b) tar xf krusader-2.4.0-beta3.tar.bz2
Then, do step two, which is correctly stated as cd krusader-2.4.0-beta3
Step three is almost all there, with a missing note: be sure you have cmake installed! My bet is that my troubled user did not.
Cmake ran uneventfully, as did make, so steps three and four are perfect. Step five, however, does not work at all for me, because I don't have checkinstall installed. And I don't think I'll do that for the sake of finishing this blogpost! I don't need a deb file, when Krusader is available from source.
I hope our Kubuntu packagers will get the newest version packaged soon, and make it easy for my troubled user.
1. https://bugs.launchpad.net/ubuntu/+source/krusader/+bug/1065110
2. https://bugs.kde.org/show_bug.cgi?id=294542
Monday, May 6, 2013
Contribute joy
I've just finished a memoir by Roger Ebert, called Life Itself: A Memoir. This passage struck a chord.
We get to share our love with the world too.
"Kindness" covers all of my political beliefs....I believe that if, at the end, according to our abilities, we have done something to make others a little happier, and something to make ourselves a little happier, that is about the best we can do. To make others less happy is a crime. To make ourselves unhappy is where all crime starts. We must try to contribute joy to the world. That is true no matter what our problems, our health, our circumstances. We must try. I didn't always know this and am happy I lived long enough to find out.We in free and open source software are making the world a better place, and making others happier; often people whom we don't know and will never meet. Roger Ebert shared his love of movies with the world, and I'll miss his voice now that he's gone.
We get to share our love with the world too.
Subscribe to:
Posts (Atom)