But this is the "100 paper cuts" thing. I use and curse Gnome daily. I could list ten more if I had any belief there'd be action. $1000 is a week's worth of action if you sell yourself really cheap.
Rant 1: If you look at a given "bug list" for any large project you'll find a dozen problems posted where the reply is a very curt "will-not-fix/not-a-bug/your-configuration-is-wrong". It feels generally snarky and unwelcoming, especially when I'm searching for a solution to the same bug. If someone could figure out protocol that would make bug-reporters feel more welcome, it would really help the process. As developer, I know that, in fact, a lot of things people see really aren't bugs but expected behavior/configuration problems. BUT!, BUT... you have to create an atmosphere of involvement if you want people involved.
Proposal/Rant 2: The format for menus in Gnome is the convoluted piece of trash that anyone ever foolish - how freedesktop could possibly publish it as a "standard" is beyond me. It needs to be junked and replaced with a simple approach. (And suspect this format is why panels has notable, annoying delay to be displayed even on modern hardware that should show stuff instantly).
Proposal/Rant 2: Scribus has a zillion bugs I'd love to see fixed. I have a private list I keep out of frustration. I won't bother pasting it here unless I see more interest. It's more likely that Inkscape will become a viable DTP project through supporting multiple pages than that Scribus will ever stop being a piece of total garbage - because it's really hard fix large, poorly coded project. Yes, I've used Scribus, a lot sadly.
The "recently used documents" seems like the most specific bug / fix that we might be able to get done first.
However, am I right in thinking that what you are seeking is essentially this:
If so, it looks like it has been fixed (or am I misreading the bug)?
Changing the resolution of the display (ie., dock/undock laptop) causes the panel icons to shift around. The bug is marked fixed, but it isn't.
The fix would involve an overhaul of the interface used to add icons to the panel, and it would not fix any existing panel configurations. It would also require at least some sort of an extra step of understanding for the user (Do you mean left justified, right justified, or absolutly positioned?) and some interesting Gnome-panel rendering hacks.
This is a lot of work for something that doesn't affect a lot of users, as most users do not customize their panels, and of those that do probably are not changing their resolution often. If someone who wanted to work on user interface hacking worked on other parts, such as improving file system access, preferences configuration, or even login screens, it would be more appreciated by more users.
Sure, it takes work and testing to get a UI into a condition that seems, to the end-user, to just work
BUT that kind of work, each in the small end-cases that only come up ocassionally, is needed. Sure "that doesn't affect a lot of users...".. yeah it will continue to "not effect a lot of users"* as long your usability sucks and not one uses the thing...
An app or desktop or whatever needs to fully implement the features it claims to have. And it is often true that the last yard turns out to cost as much as the rest put together. Yes but the last yard is necessary. I can understand if it won't get done 'cause there's not enough time or money. But the attitude that it shouldn't get done 'cause "that doesn't affect a lot of users" makes my blood boil. Sorry, I'm sure people put lots of effort into this stuff but I just have to get this off my chest.
This complaint is similar to desktop icons not maintaining their position when you change desktop resolution. It requires far more work than changing the way the backend handles shortcut keys (to fix the menu bug), and doesn't improve most people's experience.
I'm not saying you're wrong! This is a legitimate problem! I'm simply saying that it's not a priority, similar to how it's not a priority for Apple to expose a user interface to customize the button layout on their windowing engine, or fix their dock to work properly in vertical mode. All projects have priorities, open source and closed source, and this bug doesn't seem very important to me.
The problem with that thinking is that all of those little corner cases, in aggregate, create a situation in which you are constantly encountering little unpolished, sharp edged bits of ungainly behavior, and it's never going to go away until people reject CADT-type behavior and realize that polishing enough corner-cases for small subsets benefits large majorities in aggregate.
Shuttleworth seems cognizant of this with his support for the paper-cuts project, but there's too little of this polishing going on upstream for a 100-odd little fixes per-release effort to really tip the balance too far towards improvement.
Open source has a different problem from closed source in the sense that the "sausage making" is visible from the outside.
I don't think that processes or design principles of closed source companies and products is applicable. Is important to prioritize and manage what's happening ... It's just that it's important to do that in a way that makes lets the random person walking-in feel like they've begun to participate rather than giving an answer like "who let you in". (essentially should be the opposite of Linus managing the Kernel).
Perhaps a "friendly bug reception area" would be a worthwhile project. Launchpad may be very functional in ways but I'd say it's very, very broken as far feeling you're participation valued. A random bug thread is "comment-1, comment-2... little-icon-saying-this-is-not-a-bug-with-little-explanation". Just a longer boiler-plate explanation for changes like could be more soothing.
What I have experienced is the "Internet Interface" of ....
"Whatever the problem is, the first answer is 'it's not a priority'"
THAT needs to be tweaked. I understand prioritizing things. But we really, really, really need a way to relate to those frustrated by and reporting X that doesn't involve "answer 1: we don't care about X" because that has as it's implicit message "screw you".
Edit: Also, the original problem is something really looks like a bug to the end-user whatever is may look like the programmer. So fixing it should be "bug priority" whereas a number of the thing you mention are clearly features, look like features to the end-user and so should have "feature priority". Just consider...
I'd say the duplicate bug count, angry comment count, subscriber count would disagree with you.
However, if we can call features a bug, I would really like some better graphical frameworks for HTML5 a-la Flixel or Flashpunk for Flash. As a game developer, I would love this, even if it's simple or bare bones, as it would send me in the right direction and show me some best practices.
- Fix suspend/resume on Linux or work towards integrating TuxOnIce/Suspend2 in the mainline. At the very least, improve DSDT debugging tools, so that non-geeks can help developers identify why suspend is not working on their desktops. http://goo.gl/oUzF
- Create a SVGALIB backend to Plymouth, so that nvidia/ATI cards dont have shitty bootsplash (http://goo.gl/1D52)
- Fix SIL-Graphite support in Pango so that Asiatic fonts (using smartfonts) are better supported.
- Fix upstart scripts for postgresql, php-cgi and a zillion other services (migrate them from the old style - it really messes up having them in different places.)
- And of course, the long running IPV6 slowdown bug (http://goo.gl/y0SN)
Short version: any theme installed by the user (to ~/.themes) will not be picked up when running admin apps (because they're run as root and thus look in /root/.themes, but it's a UX issue all the same).
The long and short: changing the CSS of a parent element of a flash movie causes the flash movie to reload.
4. nm-applet crashes a lot!
3. Often, elevating privleges (sudo and the like), runs the program as root, meaning that any files it makes belong to root, and the home folder isn't used but the root folder.
2. If several users are on, only one of them will be able to run nm-applet.
1.Keyrings, aka. can a design be a bug?
Seemed an easy place to have the voting happen.
We need someone to get the ball rolling!
As a sidenote: I always am a bit skeptical when i see links to a HN thread propagated in posts, primarily because it may bring too many new people here in particular if the post gets picked up by major news outlets. Nothing wrong with new users, but I think anyone interested in HN related topics learns of this site sooner or later anyway. The rate of submissions/changes on the front page has increased a lot during the last year and I'm a bit afraid where that will lead to (unless PG starts updating / trying a couple of things with HN, such as thresholds, categories, etc).
You're right - in many ways $1k is tiny, but I was hoping that there would be a bunch of annoying bugs / bugs in boring areas that cause people headaches that (other) people could fix in ~1 hour or so.
If others wanted to chip money into the pot, I'd happily give it a shot at administrating it for a bit and see if it gets traction. So far, we aren't seeing bugs submitted that would cost > $1k to fix either - if we do, perhaps we can persuade some people to chip in to help meet the cost...?
Could be enough to set up a website with accounts and a system that gives you "karma" for each bug you remove or a feature you add. Amount of karma depending on the bug/feature and maybe an additional voting system for users to push their favourite feature or most annoying bug.
Having a lot of karma on such a site may even be interesting for your resume when you apply for a job.
It would have been nice if he could have backed something like, a StackOverflow for opensource bugs/feature requests with payment integration.
Didnt hear back though!
It's now fixed, but that is the kind of thing we're looking for.
I'm not a developer - I'm a business guy primarily - so I'm unlikely to be the best person to pick out things that typically hold up developers.
Anyone going to get us going with a bug you'd like to see fixed in an open source project?