Current bug situation

[TSP]

Hi, 

So I realize there's been topics on this before, but I would just like to hear an update from you on this subject and present some issues I feel has been idling in the bug tracker for what I deem too long with no visible progress. 

You currently have 21 pages of bug reports in the "Active Reports" area, of which 17 pages are pending. The situation of you having 15+ pages of pending bug reports have, as far as I remember, been going back to early versions of IPS 4.0. 

Unfortunately it seems new issues trickle in as fast as you fix existing ones. I realize you're working as hard as you can, and that your resources are limited. But I feel you need to set apart some time specifically and systematically to go through bug reports at a much faster pace than you do in a normal situation for a certain period. I fear that you will or have already started work on IPS 4.2 before you do this, which will once again increase the amount of new issues once again when that's released. 

You've earlier emphasized that you feel going by the number of bug reports does not really tell anything about the state and stability of the software. I agree on this to a certain extent. The problem is that you often seem to give more attention to the newer reports and rarely give much attention to reports that "fell through the cracks" when they were new. These issues often go on a 6 month long idling time waiting around for someone to finally start working at issues from another angle. These issues still may have consequences that affect and annoy end users on a daily basis. 

The text editor is what I would consider the center piece of any community software and a lot of end users use and interact with it every day. It's what I currently receive a lot of complaints about. Here are for example two issues I feel should be given some added priority

I've also noticed that reports that have been marked as "Rikki" or "Theme" seems to be the most frequent in reaching a state where they are untreated for a long period of time. Maybe Rikki should spend some more time in the Bug Tracker? I realize all staff are busy doing other things, but I feel you need to get a period with more systematically ensuring the number of bugs go down and start working on reports that have been around for a long time, especially the issues related to the editor. 

[Charles]

Thank you for your post but we handle things as we think is the best approach. Obviously you have no awareness of our internal procedures or priorities so a topic like this just ends up being you pontificating without a purpose  

[Matt]

As IPS 4.1 matures, we'll be switching gears to devoting more time in the bug tracker.

One must keep in mind that we make dozens of bug fixes and changes a day based on tickets sent to us, so please don't think that we're neglecting the software.

[Tracy Perry]

On 7/1/2016 at 7:06 AM, Charles said:

Obviously you have no awareness of our internal procedures or priorities so a topic like this just ends up being you pontificating without a purpose

And sometimes the purpose may be to gain a little insight into the procedures or way priorities are assigned by the license holders of the software to a valid purpose. 

[Tom_K]

On 7/1/2016 at 2:07 PM, Matt said:

As IPS 4.1 matures, we'll be switching gears to devoting more time in the bug tracker.

One must keep in mind that we make dozens of bug fixes and changes a day based on tickets sent to us, so please don't think that we're neglecting the software.

I know devs are working hard on fixing bugs and it shows in the bug tracker. There are however some active bug reports in pending status that are a few months old and some don't even have any feedback from IPS staff.

Would it be possible to clean them up and mark them as Won't fix or Planned for major fix so at least the bug reporter knows what's going on?

I've found bugs dating back to 4.1.3 which are still pending.

It's just the feeling that those bugs are forgotten.

[Charles]

We cannot forget bugs marked Pending

Many bugs in the bug tracker are very low priority or are larger changes that are more than a simple "bug" so aren't that simple.

You can always submit a support ticket if you are every experiencing a problem with your site. We are planning on making changes to the bug tracker as people get a bit overly-obsessed with it yet if we ask them if they are actually experiencing any problems on their site they say no. So it's kind of a situation where people are overthinking the importance

 

[Dll]

3 hours ago, Charles said:

We cannot forget bugs marked Pending

Many bugs in the bug tracker are very low priority or are larger changes that are more than a simple "bug" so aren't that simple.

You can always submit a support ticket if you are every experiencing a problem with your site. We are planning on making changes to the bug tracker as people get a bit overly-obsessed with it yet if we ask them if they are actually experiencing any problems on their site they say no. So it's kind of a situation where people are overthinking the importance

 

 

 

 

Equally, there are some who report bugs which are problematic only to have them marked as pending and left for months. Not important to you perhaps, but moreso to others, and a poor reflection on yourselves.

[Charles]

If you have an issue on your site which is causing you problem then please do submit a ticket. Tickets are always our first priority.

[Dll]

23 minutes ago, Charles said:

If you have an issue on your site which is causing you problem then please do submit a ticket. Tickets are always our first priority.

Then why have public bug reporting at all? I assume you recognise how bad it looks when someone takes the time to report a bug to you and it's ignored for months? (Or worse closed without being fixed, which is another fairly regular occurance). 

You can't have it all ways, either have the bug reports and look after them, or don't. You can't have them, ask people to use them but then ignore lots of them and expect people not to see that and draw negative conclusions from it. 

[Charles]

Yes I do agree that is an issue. We have a two-fold problem: 1. many issues (but not all) in the bug tracker are not critical or only impact certain situations and 2. many issues in the bug tracker are already fixed via tickets and we have to do a periodic sweep.

We always say if you have an issue that's actually impacting your site then submit a ticket. Like I said, we plan on making changes to the bug tracker so people are more able to manage what to do and also so we can better manage the flow too  

FYI: we will be doing a bug tracker sweep next week so you should see what I mean.

[Nathan Explosion]

28 minutes ago, Charles said:

We always say if you have an issue that's actually impacting your site then submit a ticket. Like I said, we plan on making changes to the bug tracker so people are more able to manage what to do and also so we can better manage the flow too  

The addition of a "Is this bug currently impacting your site?" yes/no, and a resulting yes = "Would you like to submit a ticket via the client area?" option would likely cover this one off then

[James W]

I just wanted to add that, although I've run into a few bugs (and submitted some bugs in the bug tracker), submitting a support ticket is usually the fastest way to fix your particular issue on your own forum, and it's generally a very quick fix that's addressed within a few days.

I fail to understand why people are complaining about the multiple venues that you have access to, to report a bug. I see the tracker as something you can live with, but a nudge to the developers that something is broken. A support ticket is generally concerning a bug or issue that you simply cannot live with, and the staff is generally on top of that like white on rice, and get you fixed up in a jiffy.

[Joel R]

11 hours ago, Eerand Wright said:

I just wanted to add that, although I've run into a few bugs (and submitted some bugs in the bug tracker), submitting a support ticket is usually the fastest way to fix your particular issue on your own forum, and it's generally a very quick fix that's addressed within a few days.

I fail to understand why people are complaining about the multiple venues that you have access to, to report a bug. I see the tracker as something you can live with, but a nudge to the developers that something is broken. A support ticket is generally concerning a bug or issue that you simply cannot live with, and the staff is generally on top of that like white on rice, and get you fixed up in a jiffy.

To be clear, no IPS client in this topic to date is complaining about multiple avenues of support.  

 

Apparently IPS has a very strong idea of what sorts of bugs they would like to be reported or what they think are reported to the tracker, but I don't think they have an equally strong communication policy that conveys what support will be given to the tracker and what kinds of issues clients should report.  There's genuine confusion from well-intentioned clients who are actually trying to make the most out of ALL support avenues to benefit all communities.  Not just to fix their own.  

 

[Lindy]

3 hours ago, Joel R said:

To be clear, no IPS client in this topic to date is complaining about multiple avenues of support.  

 

Apparently IPS has a very strong idea of what sorts of bugs they would like to be reported or what they think are reported to the tracker, but I don't think they have an equally strong communication policy that conveys what support will be given to the tracker and what kinds of issues clients should report.  There's genuine confusion from well-intentioned clients who are actually trying to make the most out of ALL support avenues to benefit all communities.  Not just to fix their own.  

 

Interestingly, I was thinking just that earlier today and we agree. We're going to restructure maybe as soon as next week and have a gateway of sorts. "Something is wrong with my site, I need help." -> Redirect to new support ticket. "Just want to let you know about something that isn't having a big impact but should be addressed at some point." -> Bug tracker. In terms of the latter, your bugs will be visible only to you and IPS (unless support provides a direct ID number for a client to follow.) For those familiar with Apple's bug reporter, it will work very similarly. 

Honestly, the bug tracker ends up being 90% "stuff we should get to when things are slow." Language bits, things 1px off, put your left foot in and your left foot out while using Android and you may not be able to ... well, do anything... you're using Android. I kid, I kid. Seriously though - most of the tracker is what-if's, minor cosmetic quirks, etc. Unfortunately legitimate site-impacting issues are often buried in mix. That's why I think before we get to the point of submitting a bug report, say "hey, is this impacting the use of your site? let's submit a ticket instead" will get the bug tracker more streamlined and ensure people with problems are addressed more efficiently. 

[Dll]

8 hours ago, Joel R said:

To be clear, no IPS client in this topic to date is complaining about multiple avenues of support.  

Apparently IPS has a very strong idea of what sorts of bugs they would like to be reported or what they think are reported to the tracker, but I don't think they have an equally strong communication policy that conveys what support will be given to the tracker and what kinds of issues clients should report.  There's genuine confusion from well-intentioned clients who are actually trying to make the most out of ALL support avenues to benefit all communities.  Not just to fix their own.  

 

 

 

 

 

1

I agree with this. I don't know if other people do the same, but before raising a ticket about a problem I've seen, I'll tend to check the bug reports, forums etc to see if someone else has reported the problem. If they have then I won't raise the ticket, as I'll assume that the bug report is being looked into and that there's a reasonable likelihood that if others are having the same problem, someone else may have raised a ticket as well. 

On top of this, and perhaps it's just me, but I'll also tend to test things against a clean install when trying to figure out a bug, and again if it's clearly not just limited to my install, then often I'll post it as a bug rather than just raise a support ticket. Perhaps wrongly I assumed this is a more helpful way of raising bugs as it's public so, in theory it stops duplicates, and helps to save on multiple tickets being raised for the same thing.

What I really don't understand is the message being given out that for some reason if I raise the identical problem as a ticket as was raised in a bug report, it'll be looked into faster. Why? Is it really the case that if I go and find a bug report posted and marked as pending months ago, and raise it as a ticket, it'll be fixed straight away for me?

[Lindy]

6 hours ago, Dll said:

What I really don't understand is the message being given out that for some reason if I raise the identical problem as a ticket as was raised in a bug report, it'll be looked into faster. Why? Is it really the case that if I go and find a bug report posted and marked as pending months ago, and raise it as a ticket, it'll be fixed straight away for me?

Tickets are given priority because if you're filing a ticket, it's generally because you have an issue that's impacting your site from a usability standpoint vs something that in reality doesn't need to be addressed immediately (like "this doesn't line up correctly", "pasting a username doesn't turn it into a mention")

Again, we will better define the appropriate use of tickets vs tracker to make it easier and less frustrating. This will ensure higher impact issues are addressed more swiftly and also make sure the issues posted in the tracker are not redundant and are also handled more efficiently over time. 

[Claire Field]

Perhaps redirecting people to support tickets in the bug tracker itself is the answer? So then it's clear this person DOES have a problem and IS getting help? Then tag it accordingly [Ticket] or something?

I've been having an issue since the beginning of 4 and I was entirely unaware that it could be resolved via a ticket, I reported it as a bug and left it, assuming since it was not just me having the issue that it should be a bug report and not a ticket. I am now making a ticket...

[Dll]

Triaging and prioritising the bug reports properly would help solve this problem too, rather than putting all of the onus on customers to use the bug reports/tickets as you expect them to.

Regardless, though, I don't think anyone here is saying all reported bugs should be sorted within the same time frame as a ticket raised for a show-stopping type problem. But equally, there ought to be no reason a bug is just marked as pending and left sitting with no response for months and months, even if it is a low priority, and too often that is what happens. The sorts of issues in there maybe aren't major, but they're not just tiny things like something not lining up correctly either, and deserve more attention than they're getting. 

[Colonel_mortis]

There are some bugs in the core suite that affect my site, and that I would very much like fixed, but which only affect me because I use a custom theme, plugin or app. Maybe I'm wrong, but it was my impression that it is difficult to get issues like that resolved via a support ticket. For example,

(5 months ago) and

(finally fixed 8 months after reporting)

 

Then there are the bugs that are annoying, but don't make a massive difference to how the site works, for example

(9 months ago),

(6 months ago),

(5 months ago). Do you really want me to submit a ticket for every single one of those? They are annoying, I would like them fixed, and in many cases I have provided the fix for you, but that doesn't mean that they are things that are absolutely breaking the experience and getting loads of members complaining about them. My threshold for submitting a ticket is that the issue is affecting most users, it is affecting some users badly, it is affecting some users but I believe that the issue is specific to my site and I have been unable to fix it myself, or it is a security issue. In my opinion, I submit plenty of tickets as it is. If you would like me to submit a ticket whenever there is something that could do with fixing, because that's the only way that it will be fixed, then so be it. But quite frankly, that is a waste of my time and yours, and I might just give up and fix all the issues myself, merging your changes and mine, rather than fighting to get my issues fixed by you.

"Is this issue affecting my site" is the wrong question to ask, and the wrong place to put the bar, in my opinion.

On 17/09/2016 at 4:42 PM, Lindy said:

"pasting a username doesn't turn it into a mention"

I absolutely agree that shouldn't be put in a ticket. However, that sounds like a very annoying issue, that really should be fixed. How else am I going to mention "? ๖ۣۜKirotone ?" (yes, that is their username, and yes, I have restrictions on characters in usernames now)?

On 17/09/2016 at 5:31 AM, Lindy said:

In terms of the latter, your bugs will be visible only to you and IPS (unless support provides a direct ID number for a client to follow.)

Maybe I'm missing something obvious, but I can't see any benefit to doing that, but it will result in an increase in duplicate reports. Maybe you could enlighten me about why me not being able to see anyone else's bugs is going to help?

[TSP]

I'm in a situation where I cannot provide access to our servers due to security concerns and the cost it would be for us to constantly activate and deactivate an account for you. It's also not a clear-cut FTP environment where you would just edit a file and it would appear on the web, I would have to give you instructions on how to properly deploy the changes out to the "production servers", how to log on to the servers etc.

I have reported, followed and chimed in on many different bug reports. I have for long periods of time read and kept myself up to date with all of the bug reports. This is something that feels beneficial to me to do, or I wouldn't have done it. 

Among the benefits are:

• I can alert staff if I feel they missed some information which led them to close or dismiss a report from someone else.
• I can confirm that I've heard of or seen an issue myself, but that I haven't been able to reliably reproduce it in such a way that I've reported it myself.
• I can know about issues before they present themselves on communities I work on. This can help me make preventive measures, inform the staff or be able to readily respond "It's been reported and is being worked on" when someone reports it. Instead of me then having to spend time making a reproducible case, coming up with possible fixes etc. 
• You as a software developer have to deal with less duplicate reports
• You are more likely to believe and more thoroughly investigate an issue you can't readily reproduce if you see many people reporting the same issue within the same area. Than if those reports are spread among many different tickets and handled by a number of different tech support staff.
• Other members may come forth with information that may help help to resolve a bug, that they may not have thought of doing if they didn't see the report. 
• I can know when bugs are supposed to be fixed and which are still active, even bugs I've not reported myself

I have reported and followed a number of reports that have been unresolved for months and with many minor versions in between. These issues are issues that continue to frustrate end-users on the communities I'm a techie on or the other staff on the same sites (depending upon what sort of issue it is).

Are you telling me, that if I had reported these issues as a ticket, they would be fixed right away? Because that's what it sounds like. That you're not able to sensibly divide resources between fixing bugs reported in the bug tracker and solve tickets - both within a timely manner - is not my problem. This should be entirely possible by sensible triaging bug reports and having some sort of "deadline" so bug reports are not kept in limbo for 6+ months. 

Apparently it seems you have the resources to say "We want more tickets and more duplicate bug reports to go through", so obviously it shouldn't be impossible for you to achieve what I've said above. 

Apple is like a bazillion times larger than you are, and with a whole other level of support load, so I don't see how following in their footsteps on having a closed bug tracker is even remotely a sensible argument in itself. And I have reported something in the Apple bug tracker back in 2014. The issue was deemed a duplicate of another bug report 4 days later. That other bug report is still "Open" and never resolved. So the standard of the Apple bug report system is not something I feel someone should try to live up to. 

To cherry-pick just two my own reports here: 

This is currently the oldest pending report and have been sitting there quietly for 10 months. I've implemented a custom fix with edits to multiple core files in order to resolve this, as this was a very inconvenient problem to all the communities I work on. Members sometimes asks for removal (and especially often on this one community I'm on) and to have no ability for later readers to differentiate these "Guests" in topics is frustrating for many. This was an issue we were unaware of for just the first days, yet multiple members were deleted before it was discovered and because of this we now have hundreds of posts that are simply posted by "Guests". Which is inconvenient.

Is it annoying? Yes. Does it really need me to report it as a support ticket to have it be resolved in a version in the near future as opposed to 6+ months from now on? Apparently so, from what I've heard you say.

And then you have reports like: 

Which, apparently, you don't know about yourself and which has been a nuisance for a very long time. If you had taken some time to triage the bugs and actually make some effort into not letting bugs stick around for more than 3 months (or ideally shorter) you would've known. Instead of staring blankly into the wall patiently awaiting for more tickets to emerge in your support system before you deal with issues like this.

 

Will this "New and improved" bug tracker methodology of just seeing your own reports speed up how fast bug reports are handled? Or will it continue to be just as slow as before for some reports, but now people will just not notice as easily? I feel like you're just hiding the real problem here with a solution that takes away a bunch of benefits of having an open bug tracker without giving anything in return. 

[Joel R]

On 9/16/2016 at 11:31 PM, Lindy said:

In terms of the latter, your bugs will be visible only to you and IPS (unless support provides a direct ID number for a client to follow.) For those familiar with Apple's bug reporter, it will work very similarly. 

You want us to send in a bug report.  

Just to make it crystal clear, let's compare the aforementioned "bug report" to the existing "support ticket":

• They're private tickets in a private support system
• They're tied to our accounts
• They're sent directly to IPS with no community input, no community feedback, and no community validation
• BUT ... good news ... they're not as important as a support ticket.

I'm genuinely confused why we would want a second-tier support ticket system.  As a client, why wouldn't I use - you know - the first-tier support ticket system and send in a normal support ticket on every issue?  

I suppose in this second-tier support ticket system, our tickets (Whoops!  I meant "bug report".  So sorry.) will be gently ignored for a couple of months, then marked as "solved" in a mass sweep.  But this time with less public scrutiny?  Because that helps how?  I genuinely don't see how that constructively addresses any of the fundamental issues that plague the bug tracker.

Some things that I think will constructively help the bug tracker:

• A validation by other clients.  Include an ability for other clients to notate the bug, which can inform IPS to know the issue is outstanding on a certain date or a certain version.  The more notations can also help IPS better prioritize the magnitude of the problem.  
• More detailed categorization of issues.  We know that IPS does periodic sweeps through each of the apps, so better categorization would help them more precisely group related bugs together.  
• A more formalized submission template that requires better information from clients, such as steps to reproduce, code suggestions, places to upload the latest error logs / sql logs.  
• Prioritization of bugs.  I'll agree that language strings are totally nominal, so make a category for "language strings" and do a periodic sweep. But there are important bugs in the bug tracker that impact every IPS community, and those bugs shouldn't be glossed over in the cursory sweeps. Maybe bug reports need to be filtered through a gateway person who can prioritize the bugs.  But I wholly disagree with the heavy reliance upon private support tickets.  That builds upon the community's knowledge base and ability to group-solve how?
• Specially marked bugs for Contributors.  Because they've actually dealt alongside the IPS framework.  Also, IPS built this whole purple borders thing.  Use it?  
• When you mark a bug as solved, actually solve it.  That usually helps a lot.  

In general, you can be leveraging the community more.  I kind of think you have a legion of volunteer workers and bored teenagers (I mean, "aspiring developers") who are more than willing to do unpaid work to cross-check, validate, and confirm bugs.  

Ultimately, no matter the channel or medium, you should know that you have clients who do passionately care about trying to help you improve your software.  And I'd like to think we can work with you more - yes, even if that opens you up to public scrutiny and more honest feedback - but ultimately that moves us all forward and fixes the bugs in the most expedient way possible.   

[Adriano Faria]

I stopped reporting stuff on Tracjer because IPS leave it well clear that Tracker isn't important.  So why would I waste my time on it? I do when something impacts in one of my resources, like this one. But I do to let the purchaser of my resource knows that it is something in Core.

Example of how they simply don't care for Tracker: 

How can you seriously think in use Commerce X Downloads with multi currency? It works well only in boards with one currency, like this board.

Wish I have known the issues of multi currency before I developed Classifieds. I wouldn't had use Commerce on it.

[Matt]

Hi all,

Thanks for pitching in, we do appreciate your input.

Our aim here isn't to cripple anyone's enthusiasm for helping us out by reporting bugs, neither is to try and diminish the importance of the bug tracker.

What we're trying to do is find a way to streamline things a bit. During the course of a day, we probably fix a good few legitimate bugs reported via tickets. This means that while it looks like the tracker is sitting dormant, it is possible and indeed likely that many things are fixed but via tickets rather than the bug report.

What we tend to do is work in cycles. We always try and find a balance between stabilising things and adding cool new things. When we do a stabilisation cycle, we will go through the tracker, which we're currently doing now if you took a look. You'll see we've created a few new categories to help key staff members order issues they will be responsible for. We've moved a lot of more complex engineering bugs that require significant work to our internal tracker so we can discuss how and when to resolve these issues. Of course, if it was a critical issue, then it would have been fixed by now because show stopping bugs tend to get our attention.

As always, if you have a critical issue then a ticket is always the first port of call. That's what you're paying support for.  I'm currently managing our top support tier and I'm committing bug fixes daily.

So, to recap: we appreciate all your input. We love that you are enthusiastic and want to help us and we're not trying to diminish the importance of a tracker.

[Claire Field]

Guys, I am totally confused tbh. I just went back to check the bug I figured I needed to use a ticket for and after re-reading the staffs reply to the report I am not sure if we should do a ticket, but if we don't I don't see this getting fixed:

 

[Charles]

9 minutes ago, Claire Field said:

Guys, I am totally confused tbh. I just went back to check the bug I figured I needed to use a ticket for and after re-reading the staffs reply to the report I am not sure if we should do a ticket, but if we don't I don't see this getting fixed:

 

If you are ever having any issues with your community feel free to submit a ticket. We are always happy to help