Skip to main content
    Country/region select      Terms of use
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

An issue recently came to my attention that (based on my informal poll) has been a thorn in the side for Domino administrators for quite a while. I've been trying to figure out how it is that it's never been fixed.

I'm referring to the fact that end users, when they create or rename a folder, are allowed to use various characters that have special meanings in design element names -- backslash, vertical bar, underscore, forward slash (which causes problems in mobile) and enclosing the name in parens (which makes the folder hidden in the UI). It's a nuisance for administrators, because recovering the "corrupted" folders is hard to do without writing code.

For a long time, we didn't have a bug report for this -- I finally wrote one, SPR # AGUD8USQ68. We didn't have a bug report because nobody ever called it in to Support. We have a system for prioritizing bugs. Recent regressions are at the top of the list. Problems that have been in the product for one release or more, are a distinctly lower priority, unless someone complains about them. By which I don't mean bitching about it in IdeaJam or even asking about it at IBM Connect. The most effective way to boost the priority of an issue, is to call IBM Support and open a PMR. An SPR with one customer report is approximately 100 times more likely to be addressed than one with no reports (especially because the SPR with no reports generally doesn't even exist). An issue with two reports is twice as likely to be addressed as an issue with only one. Reports from development count for approximately nothing. It's all about the customers and partners.

So when a business partner wrote to me recently to complain about this issue, I told him if he really wanted it fixed, he should call it in to support. I personally would love to see a lot of these annoying issues given priority, but people generally only call in to Support when they're blocked -- not when merely annoyed and inconvenienced.  So we now have one (1) report about this issue. That's almost certainly not enough to get it fixed in a quarterly release, though it might get into the next major release.

So, if there are issues on your personal list, things about the Notes client, the mail template, or Domino that are an occasional problem, that you feel might be damaging end-user confidence in the products, impairing productivity, or just generally causing annoyance, and you want the annoyance to stop, then call IBM Support and open a PMR. And then call your Domino buddies and encourage them to do the same.

EDIT: You can also weigh in on this specific issue on IdeaJam. Thanks, Mathieu Pape, for posting this.

Andre Guirard | 13 May 2013 10:23:11 AM ET | | Comments (14)


1) Sounds good but...
Steve | 5/13/2013 11:47:37 AM

There are times(many) I call support and I'm told, "that's a known issue and there are no plans to fix it". We can try to submit an enhancement request, but it will probably be rejected.

So there are issues that will remain unresolved because IBM has deemed them as such. I think by now most users and administrators have just come to terms with the fact that Notes will always have some quirk, bug, issue to deal with. This isn't from a lack of calling, it's from constantly being told, sorry no fix and we're not going to fix it by IBM. So most admins figure why bother.

2) Working the system to get bugs fixed
Andre Guirard | 5/13/2013 12:37:46 PM

I don't have occasion to call Support myself, because I can just drop a line to the relevant developer. So I'm not sure exactly how many hoops you need to jump through. A certain amount of persistence may be required. Insisting on opening a PMR on the issue is the key thing. If you let yourself be fobbed off with a "probably not," there's no record of your call in any system that product managers look at.

3) Think very hard about this statement
Nathan T. Freeman | 5/14/2013 9:13:08 AM

"A certain amount of persistence may be required. Insisting on opening a PMR on the issue is the key thing."

Andre, how do we file PMRs on the PMR process. Because clearly, THE PROCESS IS BROKEN.

For instance, as a business partner, I have to pay to tell you about a bug in your software.

4) Re: paying to report bugs
Andre Guirard | 5/14/2013 9:44:30 AM

Oh, do they charge you for PMRs? I suppose they don't want people just calling up to complain whenever they feel like it, but to show that they really want something. It does seem like there should be something in between. Of course, management does pay some attention to IdeaJam and IBM Connect questions -- you just need more voices to be heard in those venues. Again, if you want something fixed, rally the troops.

5) Do they charge !?!
Steve | 5/14/2013 2:32:35 PM

Yes, they charge it's called annual maintenance and support. If you don't have that I believe you have to pay per incident for support.

I have been very persistent in the past with support. Regardless the persistence the answer is usually the same, no plans to fix, working as designed. At one point I told them well then it's designed poorly and was told I could submit a written business case to try to get an enhancement request approved. After careful wording of our business case, the enhancement was denied, working as designed. can be persistent but it still doesn't net good results, at least in my experience.

6) A programming error was found but will not be corrected
Chris Hudson | 5/15/2013 7:37:53 AM

... and there are those things that don't affect the users but make life difficult for Administrators... For example...

{ Link }

...which apparently will never be fixed despite being recognised as a bug.

7) And there’s more...
Chris Hudson | 5/15/2013 7:48:03 AM

Try opening a database from the files menu in the Administrator client while you have the properties box open. The database won't open until you close the Properties box.

The Admin client is now the poor cousin to the Designer and Notes clients and seems to suffer from the fact that the other two clients now have Eclipse wrappers.

Making life difficult for Administrators is not a good move as we are the ones who are often called upon to defend criticisms of the product and if we are also experiencing problems it gets harder and harder to mount such a defence.

8) Working the system to get bugs fixed
Andre Guirard | 5/15/2013 9:55:20 AM

Chris, I wasn't able to reproduce the opening-database issue in 9.0. So maybe it is indirectly fixed, or maybe you just didn't explain the steps specifically enough.

I was aware that support contracts aren't free; I guess I was assuming that most partners would either already have a contract themselves, or have a customer with a support contract on whose behalf they could do a report. After all, we're talking about the kind of issues that affect everyone, right?

It's a hard call for management; they can only spend so much on development, and there are certainly bugs that aren't worth fixing compared to the value we could deliver thru new features with the same amount of development effort. The freaky infobox thing, for instance; apparently occurs only with slow connections, and not always then, and slow connections are becoming rarer, and there's an easy recovery action. And, again, key factor: just the one report. No decision not to fix is ever really final -- they all say in the SPR (RHOE822LNS in this case): "Support should continue to log customer reports against this SPR. If weight increases sufficiently, it may be re-raised for triage for an upcoming maintenance or feature release."

9) For those on IdeaJam ...
Mathieu Pape | 6/19/2013 4:34:19 PM

... I've posted an idea to reform the way SPR's/bugs could be voted for correction : { Link }

 Add a Comment
Comment:  (No HTML - Links will be converted if prefixed http://)
Remember Me?     Cancel

Search this blog 


    About IBM Privacy Contact