TSP

+Clients
  • Content count

    6,324
  • 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,638 profile views
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. Yes, ideally we should be able to choose a name for ourselves or it should at least include more/all of the configuration options.
  7. 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.
  8. 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.
  9. No, they shouldn't in my opinion.
  10. Looks like they may have forgotten about the suggestion. I'm not into Commerce myself, but I agree this is a reasonable request.
  11. 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.
  12. Yeah, I've mentioned this before. Having the autosave lose it's content before it has been successfully confirmed it has been stored in the database is an extremely bad user experience. It shouldn't clear on form submit, it should clear on confirmation that the content has been inserted into the database.
  13. I also noticed this, there needs to be at least some mention of the custom URL if it's set.
  14. Hi, When I go through template differences for new versions I use a combination of git diff in my local repo and seeing the template differences page here in cases where I would like some further confirmation/clarity on what have changed. However, currently it's very hard to find specific template bits on that theme differences page. For example template bits like: forums/front/index/index.phtml forums/front/global/row.phtml I use ctrl + f in my browser to search for templates like includeMeta and includeJs, but for the templates above that kind of approach is impossible. Which leads me to have to scroll through the whole ordeal to find it or find something specific in the template itself I can search for. Some suggestions at the top of my head on how it could be improved. Either one of them would work, I don't ask for all of them Create an inline search that will let us search for the names of the template bits or add filters (Application | Location | Group | Template ) where we can easily pick and choose. Bonus points if the page is then simply updated with ajax to only show those templates that match. Instead of having all the columns (Application | Location | Group | Template ). Simply have a single column/header where all the text is written inline. It could be like: Application: Forums - Location: Front - Group: Global - Template: row (Then I could easily do ctrl+f "Template: row" in my browser. Simply Add .phtml to the end of the name in the Template-column
  15. Yes. IPBWI is available for IPS 4.1. There is also documentation on how to make these sort of integrations here and here.