2008 has been a slightly unusual year for the Pidgin chat client. Improvements were made, but the biggest news was caused by unhappy users. That's one of the reasons why I created a user survey to figure out what the big issues are.
If you're a Pidgin user, please fill the survey out! It should only take a couple of minutes and will be invaluable in figuring out how to improve Pidgin.
For some background, a change to the size of the chat input box led to the largest dispute. Time will tell whether the right decision was made; for now a bigger question looms- was there anything we could have done to handle this better?
Most of the discussion occured in a back and forth email flamewar. Frankly it's hard to gauge how big a problem is from a venue like this. To put it into perspective, Pidgin has so many users that an issue affecting 0.1% of the userbase means thousands of people are unhappy.
This post has comments enabled- do you have any suggestions for things we can do to improve the way users interact with one another and with developers? Surveying users is just one step along this path. I'm sure we can do more though, and we need things that can support the huge size of the Pidgin community.
If you're a Pidgin user or someone who has experience managing user requests, write down your ideas!
Posts
20 comments:
A change in philosophy? But I seriously doubt that would happen. 2009 is in the yard now, Empathy is looking quite good with it's voice and audio (plus Telepathy framework. It's already been added to Spicebird - means both programs are aware of your status. Smartness like that is the way to go).
A non-misleading homepage would be appreciated: http://www.ubuntu-pics.de/bild/7699/screenshot_100_125__2r9TZE.png
"Was there anything we could have done to handle this better?"
Leaving users the option to stay with what they're used to. Be it the text input box or the emoticons or the buddy list interface/away setting interface (I liked the old gaim "you are away, press here to unaway" dialog box although I can live with the current state). There of course must be a balance between bloating the software with old functionality and confusing users who are used to the status quo.
The other big thing is more aggressive development. At various points there have been patches/branches floating around like MSN protocol updates and ICQ user statuses. Watching these attempt to get merged usually looks like some kind of skirmish between opposing factions; the old guard of libpurple insiders versus the underdog new developers.
I think the single worst/best example of this lack of aggressive development is video and voice support. This is where the "pidgin developers don't care" came from... right from ticket #34 ( http://developer.pidgin.im/ticket/34 )
"For the last time, if you are not a Pidgin developer or patch writer, DO NOT WASTE OUR TIME BY COMMENTING ON THIS TICKET."
"I do understand the frustration of developers having to argue about this over and over again. But I'd like to ask you to please be patient with n00bs like myself for just a little longer. This is currently the only way for us users wanting this feature to communicate, for lack of a forum."
So 3 things to solve these concerns:
- Prepare more preview releases of functionality. This allows feedback including drawing developers (that may not even know that pidgin is taking on a new feature) to become interested. A video and voice preview especially ;)
- If trac isn't appropriate for feature requests, a system like launchpad could allow users to "vote" for features and discuss their differing perspectives. I believe Wordpress have just taken this on as their policy.
- Breaking the old guard. There are many tickets on trac where developers send in a patch, only to have it never accepted (even after lengthy code style debates). While some may be "not what pidgin is for" (rss clients etc.), simple things like enabling the setting of a email notification sound become lost. This is of course the trickiest part of open development and perhaps there needs to be clear criterion for accepting new features. This may require an interface that allows hiding obscure functionality to avoid overloading the option dialogs while still allowing it's use by those who want it.
I would like proper MSN support, not like a second-class citizen. It's the most widely used protocol around the world, and basic features like set your nickname are hidden in some obscure item in the account options.
But for some reason Pidgin developers can't see that, and doesn't matter how hard I've fought for features for MSN, they just won't listen.
And of course a DSCM that more than a dozen persons use would be nice; there's a clear winner in the battle of DSCM's: git. There's absolutely nothing you can do with monotone that you can't do with git.
Things won't change, the current developers will choose new developers that think the same way they do... their technical merit is irrelevant, nor their innovative new ideas.
I'd object on the DSCM point.
More blog posts like this would be a great thing. More blog posts people can comment on will get you more insight into what we are thinking, and we will get more insight into what you are thinking as well.
Vadi,
Thanks for pointing out the stuff on the webpage. I'll see if I can get that fixed.
While it's great that Empathy exists, the majority of Pidgin users are on Windows- switching isn't going to be the answer for everyone.
maxious,
I just looked at the Wordpress launchpad and it looks interesting. Do you know if there is any good open source implementation of that board?
felipec,
I've actually heard complaints about monotone from some developers, so you're not alone. That might change someday.
As far as MSN goes, there seem to be plenty of users asking for various features. In fact, it gets the most protocol specific requests. I'll be sure to post the results publicly at some point later.
I'll be sure to do just that Amy :)
The single greatest improvement would be better communication! The #4986 ticket alone is *113* screenfuls in my browser, and the amount of text about this issue in the mailing lists was even greater. *Nobody* has the patience to read all that (and yet the developers have to...).
As a result, most of the discussion is just the same thing being rehashed again and again, with different "users" saying the same things over and over, and the developers giving the same replies again and again; until the developers get pissed off and start giving curt "we've answered this already" replies, and the users get pissed, ad nauseam.
When some debate like this erupts, it would help greatly if there was a short and clear webpage *summarising* the developers' replies to these points, so that at least (1) users would know what's on the developers' minds, and (2) the developers would only have to see *new* questions (or at least new variants of them) each time. "Read the mailing lists about this issue" or "read ticket #...." is not a practical reply.
Thanks for taking time to do this.
If the launchpad you're talking about is launchpad.net, then no, there is no "open source version" - it's just a really feature-rich project management system. Bugzilla probably comes closest.
But the software behind http://brainstorm.ubuntu.com/ is open-source: http://www.ideatorrent.org/
IdeaTorrent seems to fit the bill well. Thanks Vadi! Does anybody know of other similar open source programs? (More options to compare = better)
displayname, great point. Can you think of any projects that do a good job of this off the top of your head?
I think in the context of Pidgin and libpurple, one must look back and go read Eric Raymond's well known essay 'The Cathedral and the Bazaar'. As I see it libpurple has taken the Cathedral approach where the select few sit and decide whose patches are accepted and what features are good for the software, or even which DSCM they will use. Review and testing of patches is a good thing, but it may help to have a larger tester base as well as a larger developer base. Most people cannot see what is going on in the development process as they are not used to Monotone. Even if a patch-writer learns to use monotone, unless the code is accepted no one else from the general testers and hackers population can test it. If this cathedral style continues I'm afraid the development process will slow down to a halt in the future and the interested hackers would migrate to other projects like empathy, which offer a bigger feature set.
I think some sort of public discussion forum or the launchpad type stuff that people above mentioned would be a good idea. It would also be a good idea IMO to have a dedicated person doing sort of PR type stuff, like I guess you're doing. The impression most people have of the Pidgin developers is that they don't like to take input from users, which I think is a fair criticism. I like what you've been doing so far. Also, go bears!
(I noticed that when I saw your autoprofile site)
(current EECS student at Berkeley).
kshitij_kulshreshtha, you raise a very interesting point. As I pointed out in an earlier comment, I don't think this will be considered anytime in the next several months, but stay tuned.
Ibrahim,
I definitely agree with the feeling that the developers don't listen. I can't blame my fellow developers though. Pidgin has a uniquely large and non-technical userbase, and traditional open source support methods don't work.
This is going to sound random, but do you post on any other Cal related blogs? I think I've seen you pop up before and I can't put my finger on where.
More blog posts would be great. I'm always reading articles on the upcoming versions of Firefox, OpenOffice, the Linux kernel, the Gnome and KDE desktop enviroments, etc. But the development of Pidgin is fairly low-key. I'd like to know what the developers are up to...whatever decisions they're faced with, features they're planning to add/change, roadblocks slowing development.
I think in general there are 2 cases when people think "we don't listen".
One being things that we don't work on but don't mind seeing patches for. No amount of survey can change that. Personally it's hard for me to spend lots of time to work on things that I don't use myself. Of course, that doesn't stop others from demanding that I should spend my time to make them happier.
Second are things that there are patches but most of us disagree with those patches. One example is the input area size change that got lots of attention per pixel. In all open source projects people who have commit access get to decide, so I am not sure how this is related to cathedral and bazaar, unless people are suggesting that we should give commit access to everyone, which would obviously be a bad idea.
Early survey result suggests that the vast majority people are happy with the input area size, so it turns out that those who write code can sometimes make a correct design decision afterall. If only the users would listen though.
In relation to monotone I agree that it's probably not the best DVCS now. However it does its job and I think we should wait a little more before deciding on what to switch to. Switching once more is definitely better than switching twice. It doesn't stop others from mirroring our monotone database with other DVCS though, there are tools out there that can do that.
One final thing I want to say is that whenever I use the word "we", I only use it in a very loosely defined sense. I don't necessarily agree with what other developers do or think, and many times I don't (heck, I am disturbed by Casey's first comment already). In a sense we are pretty bazaar, we don't schedule meetings where "we" collectively try to decide on something, or even for things like when the next release should be. Things happen either by rough consensus, or because someone spend the time and do the work to make it happen (such has Maiku's work on vv). So I am pretty raged whenever people say things like "pidgin developers are < insert adjective here >", because that rarely correctly describe most of us.
I think main problem is lack of communication.
Hard for users to give feedbacks others than bug report and hard to find info about developers statement, answers, etc without reading tons of unrelated tickets.
Things like this survey are great and give the feeling to be somewhat considered.
Now the questions may be a bit improved, see below.
Are you happy with the chat input size ?
Yes I am.
Did you keep the default size ?
No I changed it to greater size.
Are you happy with the auto resizing when text growns ?
No, it draws my attention making me think a new message appeared and is buggy with bigger than line-height emoticons.
Just to show you need to choose correct and clear questions to have accurate answers. Being happy with the chat input size does not mean you like its behaviour.
Other example is "I am satisfied with with the process for getting support/reporting bugs/requesting features"
Yes I am with bug report, trac is great.
No I think feature request is almost impossible.
What to answer now ?
S,
Your point is well taken. However, that wasn't the exact goal of the survey. I designed the survey to help identify crucial areas that need to be worked on.
I could have designed a survey including all the points you just mentioned, but then it would be unbearably long with all the options. Complicated answers wouldn't necessarily make sense either (for example, a majority of users have not used Trac).
This is just the first stage of the feedback process. The second stage will require more in-depth research into certain areas and will ask questions like you just mentioned.
Post a Comment