Disappointed over bad communications!!!

Discussion and feedback on Construct 2

Post » Tue Apr 21, 2015 7:26 am

zenox98 wrote:So now it's turned into attacks on both personnel and product support!

#I'mashamed

I don't really like the word "attacks". Its like you are implying something.
ImageImageImageImage
B
28
S
8
G
7
Posts: 624
Reputation: 6,399

Post » Tue Apr 21, 2015 9:37 am

The bug report guidelines are there to help you too! They exist because bug reports that don't follow them are generally completely useless, and we cannot do anything to help you. People very often do things like report a bug which is nothing but a screenshot of an error message. There is usually nothing at all we can do about that. I actually want to help, but bug reports which don't provide the necessary information are impossible to do anything about. It's also common that users blame the wrong thing in their bug reports, e.g. that audio is broken but really some other bug was breaking an event that played audio, so I need the actual .capx project to investigate what is really going on since if I dutifully went off looking for problems in audio I wouldn't find anything and the bug would not be fixed. I know it can be tricky to follow the guidelines, but it's important to be able to actually resolve the problem. It's also very common that bug reports turn out to just be mistakes in events, and the engine was working correctly. It's very costly to developer time to spend several days picking through someone's 1000-event project, only to find their events are wrong and the engine was working correctly all along. We simply cannot afford to be doing that over and over again with every bug report, since we'd simply never have time to actually fix all the issues that are reported, let alone develop new features that other people are asking for. So the minimal project requirement is important to prove the problem is not in your own project logic. Performance bugs can be an exception to this since it depends on the full project; I have several in my email inbox at the moment which I will investigate in due course.

I think the goalposts just moved: we were talking about physics running at 1 FPS, which is a severe performance issue that is really obvious and does not take any particular skill to demonstrate. Now people are talking about jank, which lately has been more to do with Chrome's frame scheduling, which is unrelated to the physics engine. So if I'm right, that's not actually a physics issue.
Scirra Founder
B
378
S
220
G
84
Posts: 23,863
Reputation: 188,019

Post » Tue Apr 21, 2015 3:37 pm

@Ashley

I see you mention "we" here and there on occasion in reference in work needing to be done on Scirra's behalf ... but not to nag or anything, isn't it just you atm ?

I mean, we hardly ever see Tom .. which is supposedly busy with the new arcade/site for over a year.
That is taking some serious time, perhaps have him develop some fully deploy-able games for all platforms instead and outsource the web development.


Because you, Ashley, read/post, write blogs, bug check, develop, give email/forum support, and keep your tech knowledge up to date ....
You seem to be running the show alone. (not meant negatively)

How is 'getting the new help' coming along ?

You have a couple very capable moderators here, would it not it be an idea to look at them for some paid assistance on professional level ?
Even if it was for official forum support, capx file checking etc ... some of these things can take up enormous amounts of time.

Things like, primarily bug checking, case studies with games with lag/jank/overall performance issues, etc, all the things the developer really should not be doing. They (hired moderators/new function) could be the front line, (first line) for most of these problems, and if they filtered through it, recognizing a problem being more then a users mistaken logic ... then they could pass it to you ... I am guessing that could free up at least 1 day a week on your development time.
Who dares wins
B
53
S
13
G
11
Posts: 1,757
Reputation: 13,828

Post » Tue Apr 21, 2015 3:46 pm

lennaert wrote:@Ashley

I see you mention "we" here and there on occasion in reference in work needing to be done on Scirra's behalf ... but not to nag or anything, isn't it just you atm ?

I mean, we hardly ever see Tom .. which is supposedly busy with the new arcade/site for over a year.
That is taking some serious time, perhaps have him develop some fully deploy-able games for all platforms instead and outsource the web development.


Because you, Ashley, read/post, write blogs, bug check, develop, give email/forum support, and keep your tech knowledge up to date ....
You seem to be running the show alone. (not meant negatively)

How is 'getting the new help' coming along ?

You have a couple very capable moderators here, would it not it be an idea to look at them for some paid assistance on professional level ?
Even if it was for official forum support, capx file checking etc ... some of these things can take up enormous amounts of time.

Things like, primarily bug checking, case studies with games with lag/jank/overall performance issues, etc, all the things the developer really should not be doing. They (hired moderators/new function) could be the front line, (first line) for most of these problems, and if they filtered through it, recognizing a problem being more then a users mistaken logic ... then they could pass it to you ... I am guessing that could free up at least 1 day a week on your development time.

Image
ImageImageImageImage
B
28
S
8
G
7
Posts: 624
Reputation: 6,399

Post » Tue Apr 21, 2015 5:16 pm

Scirra has been growing slowly for a while. We're just not making public announcements about it as we go along, but maybe we should. We have people helping with support, software development, business development, and more. There's also a whole raft of stuff you never see from your side like figuring out how the tax arrangements work for the third party sales in the Store, or managing the increasing number of education subscriptions, or optimising the database caching so the site can scale with the increasing number of visitors, much of which I have little involvement in so I can focus on the technical stuff. But none of that changes what a reasonable bug report is!

FWIW Tom is actively working on the new Arcade now - a ton of stuff has meant it's been put off way longer than we originally hoped (ranging from prioritising the new Store with third-party content, to customer-invisible things like adapting to the new EU tax laws). But I think he's full-steam-ahead on that now and I'm hopeful we can have the new Arcade running within a month or two.

We're not coding in our bedrooms any more! Things have come a long way :)
Scirra Founder
B
378
S
220
G
84
Posts: 23,863
Reputation: 188,019

Post » Tue Apr 21, 2015 5:21 pm

The bug report guidelines are there to help you too! They exist because bug reports that don't follow them are generally completely useless, and we cannot do anything to help you. People very often do things like report a bug which is nothing but a screenshot of an error message.

Already having expressed my disappointment in how bugs reports are handled. I do however understand that you would like a Capx to test out things when bugs are reported.
However regardless of them adding a capx, the impression you get when bug reports are handled, is that its more a matter of getting them closed than looking into the report it self.
Just because a bug is closed or a bug report is not filled out as you would like them, doesn't mean that it have been solved. Its of great frustration to put together a bug report trying to highlight and explain exactly how and what is going on. To just see it being moved to the closed section as if that would solve it. In a lot of cases (speaking for my self), if the way to recreate the problem is to do 3-4 steps which takes less than a minute to do. Why should the bug report be closed? Even when a screenshot is applied showing that the capx doesn't contain anything other than a single event.

In other cases bugs are not as simple as they can be or would make sense if reported on there own, because they depend on each other. But again these are just moved to closed bugs section, because the bugs shouldn't be like that. Only one bug per report.
But if some actions lead to something else which causes the bug, and you as user don't know where things go wrong, you report it as you have experienced it. And if you during you test notice other things, then it makes perfect sense to report that as well, because how should you as user know whether that is relevant for the bug or not? But to you it might seem like a different issue, which I don't blame you for, but that doesn't mean that I know it and that I intentionally try to add as many bugs to one report as humanly possible, to just make things as complicated for you as possible.

The whole workflow of you just closing bug reports, could be compared to two people speaking on the phone.
Person 1: Expresses a problem
Person 2: I don't agree, its because you are not doing it correctly.
Person 1: But......(Person 2 hangs up.)

I think the general way that you handle bug reports are very ineffective. Instead of just closing them, it would be a lot better approach I think. To add a system of how you handle them, in the sense:

1. If you don't understand the problem / can recreate it.
Don't assume that the problem is solved by moving it to the closed section.

2. Write a reply to the person:
a. Based on your description in the report, Im not able to recreate the problem. Can you apply a Capx?, if there is none
b. I checked you capx and weren't able to recreate the issue you are referring to. <Ask for more information if possible>
c. I don't understand your description (Not all people speak English), can you try to elaborate the problem?

3. Finally
Don't close the reports as if it was solved or not relevant. Instead maybe wait 4-7 days and if the person making the report haven't answers to your comment then close it. People making these reports, simply write what they experience, not specifically where in the C2 code things are going wrong.

If you under no circumstances can recreate the problem, leave the bug report open to see if others might report something similar and write that you simply can't recreate it, but you will keep an eye on it and the person making it should as well or close it, but at least tell the person that you cant recreate it, after gathering as much information as possible. Following the 3 steps above.

And I fully agree that in a lot of cases I would also assume that some bug reports are due to bad code, but in that case simply ask them to provide a capx, if the problem or description in the bug report doesn't explain how to recreate it correctly or it is a more advance description etc. People adding bug reports doesn't do it to annoy you, but to help you. But the impression you get is that you would rather that people didn't based on the way you do it now, and that's sad I think
B
44
S
11
G
2
Posts: 1,181
Reputation: 6,801

Post » Tue Apr 21, 2015 5:46 pm

@Ashley wrote:Scirra has been growing slowly for a while. We're just not making public announcements about it as we go along, but maybe we should. We have people helping with support, software development, business development, and more. There's also a whole raft of stuff you never see from your side like figuring out how the tax arrangements work for the third party sales in the Store, or managing the increasing number of education subscriptions, or optimising the database caching so the site can scale with the increasing number of visitors, much of which I have little involvement in so I can focus on the technical stuff. But none of that changes what a reasonable bug report is!

FWIW Tom is actively working on the new Arcade now - a ton of stuff has meant it's been put off way longer than we originally hoped (ranging from prioritising the new Store with third-party content, to customer-invisible things like adapting to the new EU tax laws). But I think he's full-steam-ahead on that now and I'm hopeful we can have the new Arcade running within a month or two.

We're not coding in our bedrooms any more! Things have come a long way :)


Haha, I would imagine you actually started out that way ;P

I have heard 'the Arcade is coming' for a while now, so I'll believe it when I see it :P I still say its one of the most crucial aspects, and foretelling features this site has/had regarding potential game development; come one, what better showcase could a game dev site like construct have :D

In any case. More information through the forum/facebook/etc regarding growth and participants in Scirra's path to a business success would definitely improve transparency of Scirra's going on's.

You mention you have people helping with support, I am guessing none of these handle bugs reports or perform case studies / test cases with potential problems and workings ?
Seeing as I generally see you replying to things hinting at performance/bug/engine problems.

Take some of the replies in this thread for instance, at one point you ask/point out lack of for material with possible performance related issues; then someone sends you some as a reply, and you mention that it will take a few weeks before you would have time to look :P sorry, I lol-ed

I meant with these kinds of things. One of the things you would do is start checking the capx ...
You could have passed those files the same day to someone who knows what he or she is doing, and if they conclude the same as the complaint (not logic issue), I bet you would instantly want to know what the actual cause was/is, so you can work on it in your code.
Who dares wins
B
53
S
13
G
11
Posts: 1,757
Reputation: 13,828

Post » Tue Apr 21, 2015 6:03 pm

Ashley wrote:The bug report guidelines are there to help you too! They exist because bug reports that don't follow them are generally completely useless, and we cannot do anything to help you. People very often do things like report a bug which is nothing but a screenshot of an error message. There is usually nothing at all we can do about that. I actually want to help, but bug reports which don't provide the necessary information are impossible to do anything about. It's also common that users blame the wrong thing in their bug reports, e.g. that audio is broken but really some other bug was breaking an event that played audio, so I need the actual .capx project to investigate what is really going on since if I dutifully went off looking for problems in audio I wouldn't find anything and the bug would not be fixed. I know it can be tricky to follow the guidelines, but it's important to be able to actually resolve the problem. It's also very common that bug reports turn out to just be mistakes in events, and the engine was working correctly. It's very costly to developer time to spend several days picking through someone's 1000-event project, only to find their events are wrong and the engine was working correctly all along. We simply cannot afford to be doing that over and over again with every bug report, since we'd simply never have time to actually fix all the issues that are reported, let alone develop new features that other people are asking for. So the minimal project requirement is important to prove the problem is not in your own project logic. Performance bugs can be an exception to this since it depends on the full project; I have several in my email inbox at the moment which I will investigate in due course.


I agree that you need guidelines for bugs but I think Scirra treats this as an open-source type of project instead of a paid software. Even if a 'bug' is an error in my part I expect support for a product I paid for to help me resolve it without having to re-code some tech demo or dismiss the issue altogether. Usually the way other companies do it is that if steps to reproduce are provided they'll try those steps in that project and see if it's something simple. Other times they'll have some profiling or debugging tool or instruction for the customer. So if the Bug forum isn't the right place for this, then a Scirra Support Forum should open and issues that don't follow the Bug format can be looked at there. As I said, usually when I buy a software package and I run into a problem with it, there is some support that helps me figure that out without a huge investment of rebuilding something from scratch, or at least specifically prompting with the steps useful to the developer to figure out waht's going on, e.g. "have you tried X, Y or Z?", which ends up determining if it's a bug or of if there's some other solution. So yeah I guess as purely bug submission the strict guideline can be good, but only if there's some alternative to solve issues with the product in general. Looking at people's projects is unfortunately part of what providing support for this type of software means. At least all other packages like this I've owned if the developer can't figure out the issue from my description, they do ask for and look into my specific project to figure out what's wrong. Maybe it's time to start beefing up Support in forums and personnel, at least for customers who bought the product, which can cut down on the number of support requests :) Good to hear that you're growing as a company though!
B
11
S
2
G
3
Posts: 283
Reputation: 1,968

Post » Tue Apr 21, 2015 6:13 pm

@nimos100 wrote:.....
If you under no circumstances can recreate the problem
.....



Closed bugs 4,055 Topics .....

If each would take just an half hour to do ... it would already take 253 8 hour work days to make them all ...

... and I was pleading for Ashley to get more dev time :lol:




Aside from all this ... I think a closed bug reporting environment, like Juryiel mentions, might be a good thing.

The whole recreating capx thing takes time ... and I am guessing quite a few people are reluctant to post their capx files as they ponder content might get stolen.
If people could use their own 'trimmed down' versions of their capx, I would think that the user would require far less time to make the files needed for a decent report, without fearing someone might steal images/audio/idea etc.

Trimming down is one thing, but creating a whole new capx can be very time consuming ....
Plus, trimming down could have the benefit of the user suddenly ending up with a working variant of his game, realizing its his or her own logic causing problems. But I think users would only post this if only Support are able to see their files, as they would definitely not take their material for personal use.

As an alternative, @Scirra could set the resulting Capx upload in the bug section to be only viewable/downloadable by mods/admins :)
to give the users some privacy.
Who dares wins
B
53
S
13
G
11
Posts: 1,757
Reputation: 13,828

Post » Tue Apr 21, 2015 8:28 pm

Yes, better support for people who paid for the software, easy to check by the medal icon of forum avatar. :)

But at same time, I want to see dev time.. It is simply needed that Scirra has a team of at least 6 people... I love Construct 2 and the concept and the site itself, it has a little sense of action (the contest and the badges) but I think that the copies/buyers/fans has outgrown the team size. I feel like Scirra still treat C2 as a tiny indie project (the small 1 developer 1 pr/website) but still business/paid license seriousness at same time. You can't have both.

I am not dissing the guys. Ashley and Tom are awesome! It is just the going way....
Last edited by helena on Tue Apr 21, 2015 8:33 pm, edited 4 times in total.
B
56
S
18
G
13
Posts: 447
Reputation: 10,665

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: arthurtomazz and 5 guests