TSP

+Clients
  • Content count

    6,332
  • Joined

  • Last visited

About TSP

  • Rank
    Frequent Contributor

Contact Methods

IPS Marketplace

  • Resources Contributor
    Total file submissions: 8

Profile Information

  • Gender
    Male
  • Location
    Norway

Recent Profile Visitors

104,675 profile views
  1. It is indeed a true story, unfortunately.
  2. The autosave feature is something I find very useful myself. If only it had kept my post in situations where I would actually be likely to need it in 10/10 cases, like when receiving error messages. (They are emptied on submit rather than successful post ¯\_(ツ)_/¯ ) The issue here is that removing things from the editor is buggy (which is the real issue) and that it might have been an idea if the autosave-feature had some sort of timeout value that could be defined by the administrator.
  3. ... You're taking one thing I wrote and using it against me, great. Just as I initially suspected you would do when I first saw you like that post. Obviously bug reports should be triaged. Just as regular tickets need to be triaged in some sense. Just as feedback needs to be triaged. I'm like merely pointing out the obvious here. That doesn't mean it's only one possible to triage them the "Charles way". Does that mean I said "Bug reports should be handled in the ticket system"? No. Does that mean I said "a non-developer should triage them"? No. One of my bug reports had me have to explain tier 1 support staff one extra time what I said, while I'm pretty sure any of your developers would've caught on right away. The delay from when I report a bug, to when it end up in the bug tracker is extended. Your reiteration of the bugs also have less information in them, leaving your developers to have to more regularly jump between bug tracker and tickets. How I think triaging here should work: I report bug -> Anyone else can see and comment on my issue with any additional information they may have etc. -> An assigned developer to take care of new reported bugs for the current week takes a look. Any "5 seconds fixes" are done then and there, if the issue is more complex it get's triaged to be completed and looked more closely at later, then they continue to go through the reports. Many many years back you had terabyte in your staff whom I remember was very good at this. It's a situation like that I would primarily like to see again. Ultimately it's like not any harder than to say "Let's make sure all bug reports are dealt with within two months of submission in some way.", and the situation you have would be like 10 times better.
  4. Charles, this new situation where we end up submitting bugs through the client centre, and you post it as a bug report just leaves me utterly demotivated. I know it probably doesn't make any ounce of sense to you, but I'm simply put off the thought of continuing to submit bugs now. You're making this harder than it has to be, both for you and for us, and I just end up feeling unappreciated as well. I hope this is not meant to be a permanent thing and that you really reconsider this.
  5. If they had someone that would respond to and/or properly triage the bug reports as they come in, that wouldn't be a problem.
  6. I guess it could be an option in the move window itself too, in the same way there is an setting to leave a topic link in the old forum or not. And the default state of the checkbox could be decided by a setting like the one you suggest.
  7. I feel like I have mentioned this before, but I could not find the topic. Either way, on a related note: when a topic is moved it should be sent a notification about the topic for members following the forum it is moved to. Now that will only happen if it happens to fit in with the cycle of daily or weekly digests. But for example those who follow immediately will not be notified about the topic under any circumstance. Those who follow the forum the topic is moved to should be notified.
  8. This. So much this. (Your whole post lives up to the Joel R hype/awesomeness, but especially this) But how will hiding bug reports from everyone elses view than the reporter help anything? Apart from your apparent satisfaction of us not seeing all the old bug reports that can still be reproduced and have been laying dormant for months. I have seen you have been very active at fixing bugs since the day I started this topic. Great! All I have asked for have been for you to take your time to do some major stabilization releases. But I do not see how it can be so difficult to avoid having bug reports lay around with no action taken (at least as far as we can see) for 3+ months. It takes just as much for you to fix that bug regardless of whether it was something I sent in a ticket or in the bug tracker. In the ticket system you will also take up time from support staff that are not responsible for fixing bugs. Sure, advertise tickets as the go to solution for inexperienced clients or whatever you feel you need to do, but do not disregard the benefits that comes from well-organized public open bug trackers.
  9. 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.
  10. Yes, ideally we should be able to choose a name for ourselves or it should at least include more/all of the configuration options.
  11. I think there should be one notification for each post where you've been quoted. It doesn't make much sense to combine these into one.
  12. Yeah, I mean they are still reading within that category. The difference is they are looking at a topic in that forum, but they should still be shown both places. Bascially I think it would make perfect sense they be shown as being in all areas that they currently have breadcrumbs for. So for example, the breadcrumb for this page is: Forums > Sales, Feedback and Information > Feedback and Ideas > Product Feedback > Please show users reading content as being in that category Then I should be listed as being in the Forums-application (if a widget shows that), I should be listed as browsing "Sales Feedback and information" (if the widget is placed there), I should be listed in "Feedback and ideas", "Product feedback" and this topic. But at a minimum I think you should be shown as in the "last" container the current item belongs to.
  13. No, they shouldn't in my opinion.
  14. Looks like they may have forgotten about the suggestion. I'm not into Commerce myself, but I agree this is a reasonable request.
  15. These are all things I've heard from our staff as well. For example one community I'm at has 20 staff members, watching over a forum that gets 4000-5000 posts a day. This is a community that gets very actively moderated. One of the most common feedback among them after the upgrade to IPS 4 was two things: 1. The post content is not kept as it was when it was reported. This makes it difficult to really have any proof when it comes to what they actually said at a later time. Yes, there is the edit history. But I have two problems with it, it stores all edits. I would only be interested in edits to comments that have been reported. And this edit history is not readily available or made clearly aware of how there has been edits in the post after the content was reported. 2. The report center shows all reports as default, which makes it difficult to actually view the things that needs to be sorted now. Additionally I find the color coding here confusing. There is a light green color which I initially thought would mean the report has been resolved, but that actually means the report is open. A more appropiate color coding would have it be slightly red (or let actually completed reports be slightly green and active reports have no background color (white) ). There should be an additional filter here that shows "Active reports" that contains both "New reports" and those "Under review". That these things you mention and especially those two things mentioned here have not been adressed yet is beyond me. Maybe the current system works for forums that receive less than 5 reports a day. But not when you receive 40+ separate report items a day (yes I'm serious), then it gets really unwieldly. I really hope for a report center and moderating overhaul.