Much ado about scripting, Linux & Eclipse: card subject to change


LATER & WONTFIX Bugs (The Saga Continues)

This was orginally going to be a post in bug 178923, but seeing as Ed and Aaron have decided to duke it out themselves, I'll just move it here.


Reading through the later comments on bug 178923, I would like to clarify a few things, just in terms of the my experience working on and with the EMF team.

I felt your treatment of my bugs (= what I cared about) on the verge of abuse.

That's unfortunate, but FWIW, we've all been there. I've opened bugs against sourceforge projects and had them sit for ages, untended & ignored. (You might argue that's not as bad as being closed WONTFIX or LATER, but IMHO, it amounts to the same thing - my complaint is unresolved.)

I've also seen the backlog of bugs sitting queued against some projects (like Azureus, for example) and thought, my god, there's no point opening a bug, it'll never be triaged up the queue. (And yet I haven't sworn off using Azureus every day just because the bug backlog was long.) I've spend time watching the traffic around the OpenEmbedded/OpenZaurus teams and decided that opening bugs wasn't worthwhile either, because again, they're swamped. I've consistently had things crash while using KDE but never even thought I should open a bug because, frankly, I don't know enough about the way the platform works to open a bug which would be useful to the developers. Besides, where there's a will, there's a workaround.

To me, a long bug queue can be seen to mean:

  1. insufficient time & resources to do everything everyone would like
  2. very large community being sourced by a very small team
  3. lots of great ideas (enhancement requests) but few contributors to work them
  4. lots of strange corner cases, or uses which were never expected, or unsupported combinations/platforms/environments for which the core team can't test (lacking hardware, for example)
  5. there's probably excellent support in other ways (newsgroup, wiki) for where a fix isn't possible but a workaround or better approach is possible ... and not just for the "Doctor, it hurts when I do _this_." - "So don't do _that_." scenario. ;-)

Reporters of bugs can't see how stressed the Eclipse teams are, what their priorities are...

We do publish Project Plans on our websites... but perhaps this question should be asked when opening a bug? Something along the lines of:

This might be an odd corner case, but it's costing me $$$ and time, and so I'll volunteer to write a wiki doc in return or field some newsgroup questions so that the people who normally do that can be focused on my bug for a few minutes instead.

Give and take, not just take. Isn't that what open source is about? Collaborating, not demanding? Sharing, not taking?

A bug must hurt to some exten[t] before someone takes the time and effort to file it. So I'm in a bad mood when I write a bug report.

How do you think dev teams feel when they realize they have yet another TODO added to their already massive pile? ;-) In all seriousness, *I personally* am grateful for the fact that I can, ahem, rely on the community for the odd bug report here and there. It means the massive job of testing all cases can be shared, I can focus on new development sooner, and it also validates the fact that people are using the stuff we create. Being told I'm not perfect sucks, but being told someone uses my code certainly offsets the offput.

When I report bugs, "LATER" screams "WE DON'T CARE!" and "GO AWAY!".

I would argue that it means "low on the pile" or "can we put out the 4-alarm fire before we get your cat out of the tree?" It's about prioritizing, not ignoring. I'm sure you've had the odious experience of waiting several hours in a hospital w/ a non-life-threatening problem. Sure, to you, that broken foot is super-painful, but to the staff, it's something that can wait a few hours, because the guy who came in just after you with the bullet holes needs immediate care first. Sorry to pull out the public sector metaphors, but let's be real here - there's some definite parallels between us open source workers and the overworked/underfunded public workers on which we depend.

For these reasons, I've stopped to report bugs against EMF because the responses to my bugs clearly showed that I was neither welcome nor would I ever get anywhere. And *that* shouldn't happen.

I agree - it should never happen. But look at it this way: bug fixing is a form of routine maintenance, like getting an oil change every few months, or a visit to the dentist for a cleaning. Would you be offended if you were told that the next available appointment was in 2 months' time? No, you'd think, "Damn, my dentist is popular. He must be such an expert he's got people beating down the door for his service." ;-) If you think I'm being flip, it's not intended - my point is that there's more than one way to perceive a situation.

The bottom line is this: if your bugs aren't being addresseda s prompty as you might like, ask yourself this: how many bugs have I opened w/ full Steps To Reproduce, screenshots, JUnits, or patches? If you meet the teams part way by contributing something to the bug fix effort (beyond just reporting it) it goes a LONG way towards its resolution and its ascent up through the priority pile.


nickb said...

Update, just for context. Of the 9 bugs Aaron opened:

1 x NEW, too much work to be contained in this cycle (but some R&D done)


1 x REMIND (problem appears to exist on WinNT only, which is not a supported platform, even 3 years ago)

2 x WONTFIX (working as designed / please DIY / example code only)
2 x WORKSFORME (functionality already exists)

That's 8 out of 9 bugs fixed or resolved, including contributor credit for your patches for bug 130468. It might just be me, but it seems EMF's doing a pretty good job of containing your bug requests.

AlBlue said...

Nick, you're focussing on one small part of this issue. It's not about 'never fixing bugs' or for that matter 'not able to reproduce' bugs. It's about hiding bugs so that you can't search for them by virtue of them being in the RESOLVED bucket.

Also, it's not LATER and WONTFIX as your blog post suggests -- it's LATER and REMIND. I don't think anyone has an issue with WONTFIX or WORKSFORME if they're valid resolutions.