“Some or all of your votes have been removed from bug NNNNN.

You had X votes on this bug, but X have been removed.

You have no more votes remaining on this bug.

Reason:

The rules for voting on this product has changed; you had

too many total votes, so all votes have been removed.

https://bugzilla.redhat.com/show_bug.cgi?id=NNNNN”

First, some background:

Bugzilla has “votes” on bugs. It allows each user to spend from their pool of votes and assign them to bugs that they like. I guess the idea is that highly voted bugs would show up as somehow more “important” and get more resources. We looked at generating a report on this to garner more resources for “important” bugs, but found that votes failed at this task for several reasons: They were hard to query, you could not tell how many people had voted, only total vote number, the vast majority of people didn’t see the voting interface so never voted, votes were never reported to maintainers in any way aside from the raw web interface, and others.

Additionally, some few people who did see the voting interface spent time and energy voting on bugs and asking others to do so, when in the end that did no measurable good aside from wasting their time. For these reasons, I asked the redhat.bugzilla.com folks to disable voting in the Fedora product.

Sadly, I was unaware that it would send emails to everyone who voted telling them (in a very negative sounding way) that their votes no longer counted. I’m sorry for any problems or negative energy this caused, I was just trying to save time and energy.

Additionally, I did hear of a valid use case for votes after the fact (but likely not enough for me to want to re-enable them): You can vote on bugs you care about, and use the voting interface to see progress on them (no need to CC yourself to a bug or spam it, you can silently see a group of bugs simply by voting on them).

So, I think this change was still for the best moving forward, and I would urge everyone who voted on a bug to go look at it and see what additional information could be added to it to move it to a resolution instead. FESCo has been looking at a way to see ‘very active’ bugs for a while now, please see: https://fedorahosted.org/fedora-engineering-services/ticket/24 if you have ideas or would like to help out.

I don’t think this sort of person (an OS gypsy) is super common, but it’s interesting to think about the various types of gypsies we have in the open source world, migrating around. How should we handle them? Of course it may depend on where and what they are migrating to or from.

For the OS gypsy, should we provide all the help and resources we would for someone who would stay and contribute? I would say we should. Making our install process easier for those that do so often, or making docs easy to find for people who might be switching can only help everyone in the end.

On the next step down, we have desktop gypsies. These folks might well stay in a distro they know well, but might switch between KDE, Gnome, Xfce, LXDE, and others as their mood strikes. Again, I think it can only help everyone if we try and help these folks make the easiest and smoothest transition between them. Some will stick with a desktop, and some won’t, but making it easier for them to do so helps everyone who switches to that desktop.

Finally, on the bottom level, we have folks who migrate between apps. I find myself in this category for some things. Web browsers and IRC Clients. Even though I end up coming back to xchat and midori, it’s fun to see what chromium or firefox4 or kvirc or quassel have to offer. Even if their offering ends up not being what I want it’s good to know how they look and work to help others with them.

So, in the end I think we should try and learn from the gypsies at any level. Even if it seems like they aren’t going to stick with your OS or Desktop or application, they might just tell you something that helps other stay and settle.

• more rules to specifically ban or censure the behavior
• removal of privileged or access for people “blamed” for something.
• enforcing existing rules in a more rigid manner, banning people, moderating them or removing them from feeds.
• establishing some kind of community committee to do all of the above

I would like to suggest another (hopefully better) way forward: Respond to negative energy with positive wherever possible.

Some examples:

• A negative reply to someone on a mailing list: Reply to the orig poster with the positive answer you would have liked to have seen.
• A poorly phrased, rude or condescending IRC reply to a question: Reply to the orig poster with the better, positive answer you would liked to have seen.
• A post on the planet feed you find offensive, in poor taste or disagree with: Post your own blog post with a positive reply. How could this have been better? Whats something related that’s good?
• A bugzilla bug with a rude or curt or bad reply on it. Add a comment with the correct answer phrased in a nice positive way.

Do I think this will solve all issues with negative people? No. But think about it: If someone is unwelcoming to a newcomer and your first reaction is to try and blame or punsh the unwelcoming community member, what is the newcomer to think? How about if you instead focus on being positive and helping the newcomer. I think you’ll find that in the first case the newcomer will leave in disgust that the community is so flamefilled, and in the second they will rightly realize the unwelcoming person is a outlyer and should be ignored.

How about giving it a try today? Instead of flaming, looking for someone to blame for something, or coming up with new rules you just simply lead by positive example?

I’d like to invite everyone to join us on irc.freenode.net in #fedora-social for a all day release party!

Come by and say hi and tell us what you think of Fedora 13, how you use Fedora or just share the release day fun with other Fedorians.

Some general notes from my trip:

• The Droid phone worked very nicely and was quite handy. Being able to get directions, find nearest services, check irc/IM, text house sitters, and play audio were all great. Coverage was very impressive as well
• Wandering around the coast of oergon was great. I just wish we had more time to visit Fedora folks while we were up there.
• This American Life is excellent for listening to on long drives. Please support them.
• South Park Seafood and Grill is an excellent place in Portland. Local, fresh food, great service, yummy desserts.
• The Van Gogh in the Portland art museum was lovely. It’s really amazing to me how much cooler great paintings are in real life than they are in just pictures of them on the net. The lighting, the texture, the way it looks from different angles and distances all make it well worth going to see these things in real life.
• Spokane is a interesting city. I had no idea about the falls and such there.

All in all a fun trip, although it’s good to be home. I’ll probibly post pictures here or somewhere soon…

First we had a great class from Joe Brockmeier on How to make life awesome for journalists. I was sadly unable to attend (as I was running the FESCo meeting that was taking place at the same time), but reading the logs it was a great class.

Then tonight I ran another class on How to test Fedora Updates, which I think went reasonably well. If you wondered about how Fedora updates work now and you can provide feedback, how they will look soon, and how they might look someday, please do give the session a read over.

We have a number of other sessions coming up if folks can make them:

• A Short Tutorial On i18n Through gettext – Naveen Kumar on 30 April, 2010 at 12:30 UTC (6:00 PM IST)
• Introductory workshop on GNU Autotools – Siddhesh Poyarekar on 03 May, 2010 at 13:30 UTC (7:00 PM IST)
• Learn about exciting Fedora 13 Features – Kevin Fenzi on 10 May, 2010 at 01:00 UTC

As we get closer to the release of Fedora 13, this is a great time to run a class on something you are working on thats going to be released with Fedora 13, so do consider attending, signing up to teach a class yourself, or peruse the logs after a session. All the info on how to do that is on the Classroom page.

I am going to throw my hat back in the ring for FESCo again. I hope folks will consider voting for me.

I would like to see a number of things through in the next cycle:

• I would like to see more folks working on Fedora Engineering Sevices, and more tasks for them that make Fedora better
• I would like to see us implement and put in place our new updates policy.
• I would like to see us look longer range and come up with a better updates policy and ways to implement it. For example, I think we can expand the karma concept in bodhi a good deal and work on test plans for bugs and packages.

And many more items too.

If anyone has any questions for me on plans, goals or how I envision the engineering side of Fedora moving ahead, feel free to comment here, drop me an email, or catch me on IRC. I’m always happy to help out and answer questions.

I hope we will have a good slate of folks for this election and some good town halls and questions.

I think someone who has never used or seen EPEL would be a great person to work on this, as you could see the pages in a light that a new wiki visitor would.

I hope someone will take up the challenge.

Different types of communication have different amounts of information bandwidth.

• If you are talking in person, face to face with someone, you have a lot of bandwith. You can hear the tone in their voice, see if they are smiling or frowning. Hear if they are yelling. See if they are slouching or waving their hands a lot. See if they blink, look away or frown at you. You can get a lot of information from an in person conversation, and most of us have been doing it all our lives, so we pick up on subtle cues without thinking about it.
• If you are talking to someone on the phone you have less bandwith. You can now not use any of the visual ques. You can still however listen to tone of voice, volume and laughing/crying/sobbing. Most of us have spent time on the phone and pick up on these clues pretty easily as well.
• If you are exchanging emails with a list or persons, you now have even less bandwith. You can use things like or and you do have time to think and be more deliberate with what words you use (if you choose to), but you have no tone of voice or visual clues. Just the words.
• Finally, if you are communicating with someone via irc or other IM/chat you have even less bandwith. Here people are expecting you to just blurt out your thoughts without much editing or consideration (unlike email). You have no sight or sound to help you, as well as no time to carefully consider your response.

To quote the freenode channel guidelines:

Look for the best in people. If you assume people have no self-control, they’ll confirm your belief. If you look for personal responsibility, and ask for personal responsibility, most people will respond well.

Set a good example. Be what you want other people to be. If you want them to be calm, be calm. If you want them to be courteous and friendly, be courteous and friendy. The habitual behavior of people on a channel is the most powerful influence on newbies arriving on the channel.

1. First ask yourself: Did this thing work before? It doesn’t now? What changed? Check /var/log/yum.log or other history and find out exactly what changed. Did you change a setting? Did you upgrade a package? You can think look for how to revert that specific thing that caused the problem. No need to re-install.
2. Do you have reason to think the package or application was messed up somehow on your disk? ie, do you have disk problems, or did you run a script as root that might have messed up binaries? Sure, then a ‘yum reinstall package’ might be in order.
3. Does the problem/issue occur with another newly created user? If not, then that points to a user specific setting. Reinstalling the package won’t do any good, because the setting is tied to your user. Instead look for what that setting is or how to revert it.
4. Is the problem/issue causing you to not be able to boot? Instead of re-installing, look to a rescue media. You can often fix the issue by booting ‘linux rescue’. No need for a re-install.

About the only time you should absolutely re-install your OS is when your machine has been compromised. Otherwise, it’s a lot better to fix the real issue, no only because it’s often easier, but because you will learn something in the process!