[imac]

Dear friends,

We'd like to announce the official bug fixing timeframes:

• Minor issue, tweak, or typo—45 consecutive days
• Major issue or crash—3 working days

These figures indicate the maximal waiting time for an issue resolution depending on its severity.

These timeframe values naturally come from the 2-week Scrum cycle used by the CS-Cart & Multi-Vendor developer team.

According to the Scrum methodology, tasks are assigned to developers every 2 weeks on Monday and cannot be added during a 2-week sprint. Following this methodology, we can effectively use our developers' time and plan the CS-Cart & Multi-Vendor development.

So, if a bug is reported, say, on Tuesday (a day after the tasks have been assigned), an according task to resolve this bug will be assigned to a developer only 13 days later; the developer will then spend at most 2 weeks to resolve this issue.

This sums up to 4 weeks (~30 days) from the report to resolution. Other 2 weeks are added to this figure in case the issue requires some third-party assistance or the responsible developer can't finish the job on time.


Possible Exceptions
Seldom, a reported issue cannot be resolved due to the limitations of our software architecture in general. A situation may occur when to resolve a minor issue, a developer will have to make significant changes in the CS-Cart or Multi-Vendor core code, which will strongly affect the software.

Each of such cases will be treated individually; most probably, the resolution will be postponed until the next major release, and the client will get a quick fix.


Issue Severity
An issue severity is defined by a tech support team member or responsible developer.

The following points are taken into account:

• Can the issue be reproduced on an unmodified CS-Cart or Multi-Vendor store?
• Does the issue depend on some particular settings values?
• Is the core affected, or only an add-on?
• Has the issue been fixed in the latest CS-Cart or Multi-Vendor version?

[cscartrocks]

Great improvments! Thanks!

[tbirnseth]

And can you associate your listed issues with their corresponding severity?
Maybe you can better define what is a major issue and a minor issue. Obviously something that's minor to someone is major to someone else. Subjectivity should be eliminated/reduced wherever possible.

Example, I had a client who reported a bug in the bugtracker about not being able to accept an email address of a single character for the domain name (I.e. user@q.com). They reported the bug but were told it was minor. They complained that it was major to them since some of their customers could not submit orders. They were refereed to Simbrisk custom development who quoted $200usd for a fix.

So would this be major or minor? It prevents a customer from placing an order but albeit very few customers (overall) would fall into this category.

But I guess the jist of the statement is that all bugs will be fixed within 45 days of their being reported. Please confirm.

[mattcaswell]

I don't know where to post this.. CS-Cart V4.0.3 shows Paypal advanced can be used, but there isn't any documentation on how to configure it? I tried following the paypal PRO knowledgebase article but it's asking for info that paypal doesn't show on the API screen. Is there a secret KB article somewhere for setting up Paypal advanced in V4?

I appreciate the time your engineers spent fixing the quickbooks bugs as it's working great now in my store!

[StellarBytes]

Please consider a product roadmap, like Aha publish.

This would surely be a much more viable way than receiving tickets saying "I have X bug in my CS-Cart version. When will this be fixed?" "In the next version" "When is that released" "Next month". You could have saved both the CS-Cart customer and Support staff much valued time by publishing this info for us to see. After all, you likely publish roadmaps inhouse anyway, hopefully in a more user-friendly manner than a Gantt, so why not make it accessible for all to see? Interspire actively did this - during its marketing-push - very effectively which I found far more useful than the current CS-Cart Bug Tracker.

[imac]

And can you associate your listed issues with their corresponding severity?
Maybe you can better define what is a major issue and a minor issue. Obviously something that's minor to someone is major to someone else. Subjectivity should be eliminated/reduced wherever possible.

Example, I had a client who reported a bug in the bugtracker about not being able to accept an email address of a single character for the domain name (I.e. user@q.com). They reported the bug but were told it was minor. They complained that it was major to them since some of their customers could not submit orders. They were refereed to Simbrisk custom development who quoted $200usd for a fix.

So would this be major or minor? It prevents a customer from placing an order but albeit very few customers (overall) would fall into this category.

But I guess the jist of the statement is that all bugs will be fixed within 45 days of their being reported. Please confirm.

Hi Tony,

As you know the issue with one letter domains has not been confirmed as a bug.

We often take into account how many complains have we got regarding an issue.
Anyway this issue can not be major just becuase we use this script for emails check for a long time, and this is the first complain.

[imac]

Please consider a product roadmap, like Aha publish.

This would surely be a much more viable way than receiving tickets saying "I have X bug in my CS-Cart version. When will this be fixed?" "In the next version" "When is that released" "Next month". You could have saved both the CS-Cart customer and Support staff much valued time by publishing this info for us to see. After all, you likely publish roadmaps inhouse anyway, hopefully in a more user-friendly manner than a Gantt, so why not make it accessible for all to see? Interspire actively did this - during its marketing-push - very effectively which I found far more useful than the current CS-Cart Bug Tracker.

Hi StellarBytes,

Thank you for the idea. I agree that this would be usefull feature.
I will take a closer look to it next week.

[tbirnseth]

It is just meant to be an example. One could easily argue that anything that prevents a valid order with valid info from being submitted is indeed a major. issue But as I said, I recognize that it affects only a few.

The main inquiry I was making is:

• What is the criteria for major/minor
• Will major/minor be some setting that is visable to the submitter when a defect is confirmed?
• Will there be any mechanism to provide input as to whether an issue is major/minor?
• Can you confirm that all "confirmed" bugs will be fixed within the published 45 day window?

[StellarBytes]

What you have said in both posts only reiterates the need for a product roadmap. If you have (now, had) ever seen the roadmap ("tracking" as they put it) for Interspire, you would know what I mean. Your second and third points as above would be resolved in a roadmap solution.

Most roadmap software I have ever used or looked into produced the changelog at the click of a button. This would save some time for CS-Cart every time they release a new version so it's a no-brainer, but does CS-Cart currently have this system behind closed doors?

Users with the same issue caused by a bug can add their vote on the roadmap, thus, shows how many active users require a particular bug fix. Interspire had it set so that what was reported and scheduled as a "minor" bug by the developers, could receive enough attention from the software users that it would be upgraded to "major".

By and large, Interspire's development model worked well in resolving actual bugs in a quick manner to ensure their software was updated regularly as well as adding new features along the way. They used the 'scrum' development model too, so time will tell who did and did not do their project management homework properly!

It's infuriating knowing you have found a bug in CS-Cart which actually prevents you from developing a store any further and having to abandon a project until CS-Cart publish a fix for the bug. I'm sure there are many bugs which we all encounter but don't know it which allows us to believe it's of low priority, in reality, it's a show-stopper for many users including ourselves. A product roadmap would be a solution to this too for confirmed bugs. Unfortunately CS would have to improve on the "we were unable to replicate this issue" stance and investigate more thoroughly before publishing a bug on the roadmap.

Judging by the lack of "Marketplace", sadly I don't see this idea forthcoming either.

[chris102]

What you have said in both posts only reiterates the need for a product roadmap. If you have (now, had) ever seen the roadmap ("tracking" as they put it) for Interspire, you would know what I mean. Your second and third points as above would be resolved in a roadmap solution.

Shouldn't this post be removed StellarBytes?

When you walk into a BMW garage, you don't expect other customers to try and sell you an Audi, do you?

[tbirnseth]

He's using a competitive example which no one should object to.
I know of no real software development company that uses a forum to report/categorize/rank defects. It is ridiculous and gives zero visibility into the process.

[StellarBytes]

Shouldn't this post be removed StellarBytes?

When you walk into a BMW garage, you don't expect other customers to try and sell you an Audi, do you?

'Had' being the operative word here. The company no longer sell the product or provide any maintenance or support for it. If I had said "go to XYZ Cart's website, they do this, that, the next thing, better than CS-Cart" which amounts to directing CS-Cart customers to using another cart software, I would at least consider agreeing with you. In this instance, I won't.

[Flow]

What you have said in both posts only reiterates the need for a product roadmap. If you have (now, had) ever seen the roadmap ("tracking" as they put it) for Interspire, you would know what I mean. Your second and third points as above would be resolved in a roadmap solution.

Most roadmap software I have ever used or looked into produced the changelog at the click of a button. This would save some time for CS-Cart every time they release a new version so it's a no-brainer, but does CS-Cart currently have this system behind closed doors?

Users with the same issue caused by a bug can add their vote on the roadmap, thus, shows how many active users require a particular bug fix. Interspire had it set so that what was reported and scheduled as a "minor" bug by the developers, could receive enough attention from the software users that it would be upgraded to "major".

By and large, Interspire's development model worked well in resolving actual bugs in a quick manner to ensure their software was updated regularly as well as adding new features along the way. They used the 'scrum' development model too, so time will tell who did and did not do their project management homework properly!

It's infuriating knowing you have found a bug in CS-Cart which actually prevents you from developing a store any further and having to abandon a project until CS-Cart publish a fix for the bug. I'm sure there are many bugs which we all encounter but don't know it which allows us to believe it's of low priority, in reality, it's a show-stopper for many users including ourselves. A product roadmap would be a solution to this too for confirmed bugs. Unfortunately CS would have to improve on the "we were unable to replicate this issue" stance and investigate more thoroughly before publishing a bug on the roadmap.

Judging by the lack of "Marketplace", sadly I don't see this idea forthcoming either.

I agree this would be the way to go. It would make things much clearer for cs-cart users, and developers will have something to point at instead of having to write custom replies to inquiries. It will save cs-cart time, and make users happy. No-brainer.

[P-Pharma]

Please replace the bug tracker with something that allows us to easily see how many active bugs there are.
There are hundreds of confirmed bugs from years ago or ancient bugs stated to be fixed in a next version. Are these bugs all present in version 4?
The bug tracker does not have a simple overview of all outstanding bugs. Old bugs seem to go under the radar. The bug tracker is a handicap.
I think its a very good move by Simbirsk to improve product quality.

[imac]

He's using a competitive example which no one should object to.
I know of no real software development company that uses a forum to report/categorize/rank defects. It is ridiculous and gives zero visibility into the process.

Tony,

Can you be more specific what tasks can not be accomplished on forum bugraker comparing to other bugtrakers?

[tbirnseth]

Don't even know where to begin... That you ask, is somewhat disturbing.

• No list of notifications on discussion (should have visibility and or other way to identify who is following the issue - internal and customers).
• No rating of severity or impact or any other ranking.
• No documentation of the technical description of the problem, the solution nor the version where the fix will be released.
• No "patch verification" that the problem has been resolved to the satisfaction of the submitter. I.e. submitter should be able to verify that the fix is in fact complete before it is bundled into a release. An incomplete solution has no way to be detected or verified.
• No real documentation trail (developer input/feedback, QA, customer)
• No ability of customer to identify impact/severity and no mechanism for dispute resolution.
• After "can't reproduce in the cs-cart demo", there is no more responses from cs-cart after further input from submitter.
• No QA reporting or any indication of any real "release process" and verification.

That's just off the top of my head. Suggest you search/review feature/functionality of real defect management (key word is management) systems.

[imac]

Guys,

Here are some changes made on with the forum bugtracker.

1) We are working on arranging old issues on the bug tracker. There are a lot of old requests that have been solved or are irrelevant.

2) I enabled the "Fixed in" field. Now, you can see all bugs that will be fixed in v4.1.1 using report at the bottom of the items list page. See the "Generate report list for issues fixed in" selectbox.


3) Severity levels are now the same that we use internally during development: Text, Tweak, Minor, Major, and Crash. The "Severity" field is for information only and is set by CS-Cart architects team. This field cannot be edited during bug creation.

4) You can vote for each bug in case you faced it too. See the "Issue confirmation" section in the left column. If you have faced the problem, click "Yes".

[jimmyod]

Guys,

Here are some changes made on with the forum bugtracker.

1) We are working on arranging old issues on the bug tracker. There are a lot of old requests that have been solved or are irrelevant.

2) I enabled the "Fixed in" field. Now, you can see all bugs that will be fixed in v4.1.1 using report at the bottom of the items list page. See the "Generate report list for issues fixed in" selectbox.


3) Severity levels are now the same that we use internally during development: Text, Tweak, Minor, Major, and Crash. The "Severity" field is for information only and is set by CS-Cart architects team. This field cannot be edited during bug creation.

4) You can vote for each bug in case you faced it too. See the "Issue confirmation" section in the left column. If you have faced the problem, click "Yes".

Looks nice and nice added features.
Thanks for the consideration.

[tbirnseth]

Suggest you allow the submitter to set the severity when they submit the defect. You can change it, but you should address why it was changed in the description.

Don't like the 'voting' aspect. This is not a popularity of defect issue. Just like user voice is pretty much useless, voting is not the point. Someone should be able to subscribe to "watch" the defect and that list of subscribers should be visible.

Other than those minor points, a vast improvement.

tony

[P-Pharma]

Will the bug fixing time frames also apply to all old bugs? i.e. will all currently outstanding bugs be fixed within a certain time frame?

Please add a function to petition a closed / fixed bug to be reopened. This has proved very useful on other software projects. As you will be going trough hundreds of old bugs and define if bugs are fixed or not, its normal that some bugs will seem to be considered fixed or irrelevant while customers with specific setups will run into the bugs again.