Announcement: Usable Mantis release 1.0.1.2

cckramer · Post by **cckramer** » 17 Mar 2006, 11:13

Usable Mantis 1.0.1.2 is based on Mantis 1.0.1.

Main focus of the project is usability improvement of Mantis. However a lot of bugs fixed and features improved too.

Currently, more than 30 bugfixes and improvements including:

* Improved Modify Issue page
* Improved issue list
* Unicode support for English UI
* Numerous fixes around the application

Get Usable Mantis at http://enargi.com

Post by **vboctor** » 17 Mar 2006, 23:45

Looks good. It will be a lot of work applying this to every release. I suggest you join the development team and we can roll the fixes and some of the UI changes into the Mantis core.

If interested, let me know.

Regards,
Victor
Mantis Blog
http://www.futureware.biz

cckramer · Post by **cckramer** » 19 Mar 2006, 12:30

We think it's better to join forces in open source development. Mantis is great product and joining our forces may make it much better.

Our problem is, we'd still have to keep Usable Mantis as separate product:

In Mantis there is no Issue type such as "Bug" "Change request", "Feature request" etc. But there is Priority as well as Severity. Which is quite redundant in real-world applications.
Usable Mantis has changed Priority attribute to "Issue Type".
Most probably Mantis team will not agree to change Priority to "Issue type" or add "Issue type" as new attribute.
So this leaves Usable Mantis keeping this modification as fork.
This means for us, if we contribute UI changes to Mantis core but still have to keep separate fork for our product.

We also couldn't use Mantis core as basis because Usable Mantis is used for serious projects and we make releases montly. This is to have constant feedback on quality. Not sure that goes with Mantis team, which have releases twice a year (CVS checkout don't count as release). So if we move our development entirely to Mantis core we'll lose control over quality.

We would like to know Mantis team better and find out what are the plans. Mantis Roadmap doesn't go beyond 1.0 and it doen't have end-user features planned, only internal refactoring / code improvement tasks.
Usable Mantis build work based on end-user features primarily.

Let's discuss. We hope we can find ground for collaboration with Mantis team.

Narcissus · Post by **Narcissus** » 19 Mar 2006, 16:43

Hi cckramer:

I don't want to come across as disparaging Usable Mantis, but I do want to comment on a couple of assumptions / things regarding the need to fork.

Firstly, using both priority and severity is not redundant in the real world:

Scenario 1) I have a product that is shipped to over 40,000 users and I can show (all but prove) that it will only crash on about a dozen of these users' computers. It's in a rarely used section of code and requires a specific combination of hardware, operating system, other preinstalled software and configuration settings of those preinstalled applications. To fix this issue would take weeks of development and more weeks of testing.
Severity? Crash.
Priority? Low.

Scenario 2) Another product has dummy HTML that was forgotten. It has bad language and name-calling in it. When it was written, it was done as a joke, but somehow it ended up in the product proper.
Severity? Well, this could be argued either way.
Priority? Definitely high.

As you can see, they are used for two different things. We actually use them in matrices to determine overall work priorities, in fact.

Let me also comment on "Usable Mantis is used for serious projects and we make releases montly". I don't know if you meant to or not, but that does imply that mainstream Mantis is not used for serious projects. I know that we don't advertise it very much but Mantis is definitely used for 'serious projects'. Our company has approximately 15 different applications that are distributed throughout Australia, New Zealand and the entire Pacific Rim and involves millions of R&D dollars every year. All in all, I'd say easily over a quarter of a million end users. I know large, well known gaming companies that use it and even at least one branch of a very well known mobile phone manufacturer. And that's just with my limited knowledge.

From our point of view, the 6 monthly releases are a good idea. As with any upgrade rollout, we do a fair amount of regression testing before implementing the Mantis upgrades and for our 'serious projects' we could not deal with a monthly release schedule anyway. But that's just from our point of view.

You'd be surprised at how many changes you'll be able to get in to the main branch, assuming you're happy to think about making your changes generic enough to be useful to everyone. Again, from my personal experience, when we first started submitting changes, our diff file was literally half the size of the entire Mantis project. Every single one of those changes has now made its way in to the main branch in some form or other.

Anyway, that's just the way I see it. I appreciate that you want to go your way with it and it's your absolute right to do so. I just thought that you'd like to see the other side of the coin of your experiences: mainly 'priority' and 'severity' are *not* redundant, monthly releases are *not* always desired for 'serious projects' and just because you have a lot of changes doesn't mean that your end result is inevitably 'forking'.

That's my experience and I look forward to the upcoming conversation!

Lincoln.

leblancma · Post by **leblancma** » 20 Mar 2006, 13:58

Hi Lincoln,

Talking about using both priority and severity, you said

We actually use them in matrices to determine overall work priorities, in fact.

Has anyone documented how you use these 2 issue attributes? Could you please give us additional information on these matrices, or point us to the relevant documentation.

The group I'm helping has chosen not to use severity for the time being. Just using Mantis represents a major shift in their work habits. Because it's their choice how they wish to organize their own work, I'm somewhat reluctant to try to get them to change.

That said, our testers have been asking for a tool like this for years.

Regards,

Maurice

Narcissus · Post by **Narcissus** » 20 Mar 2006, 15:58

Hi Maurice:

There is no documentation, no. It's something that one of the developers here added to the 'my view' page. Because I work remotely now, it will be harder to get the code, but I will see what I can do.

If you wanted a really, really simple way, just do a double sort (sort by priority and by severity). Unfortunately this is "the poor man's approach" as it makes a high priority text change more important than a normal priority block.

Even if I can't get the code, I'll see if I can work it out myself. In reality, it should be really simple... just give a score to each level of severity and a score to each level of priority, multiply the two then sort by the result. That's how I'd do it, anyway, and I daresay that's how it was done by the other guy, too :)

I'm sorry I can't be of much more help!
Lincoln.

stevietheman · Post by **stevietheman** » 23 Mar 2006, 21:24

cckramer wrote:We think it's better to join forces in open source development. Mantis is great product and joining our forces may make it much better.

Our problem is, we'd still have to keep Usable Mantis as separate product:

In Mantis there is no Issue type such as "Bug" "Change request", "Feature request" etc. But there is Priority as well as Severity. Which is quite redundant in real-world applications.
Usable Mantis has changed Priority attribute to "Issue Type".
Most probably Mantis team will not agree to change Priority to "Issue type" or add "Issue type" as new attribute.
So this leaves Usable Mantis keeping this modification as fork.
This means for us, if we contribute UI changes to Mantis core but still have to keep separate fork for our product.

We also couldn't use Mantis core as basis because Usable Mantis is used for serious projects and we make releases montly. This is to have constant feedback on quality. Not sure that goes with Mantis team, which have releases twice a year (CVS checkout don't count as release). So if we move our development entirely to Mantis core we'll lose control over quality.

We would like to know Mantis team better and find out what are the plans. Mantis Roadmap doesn't go beyond 1.0 and it doen't have end-user features planned, only internal refactoring / code improvement tasks.
Usable Mantis build work based on end-user features primarily.

Let's discuss. We hope we can find ground for collaboration with Mantis team.

There is a middle ground here.

How about just sending all your source additions to the Mantis team, and let them decide what to incorporate and what not to incorporate.

Then, as the Mantis team adds some of your changes, then perhaps the differences between Mantis proper and Usable Mantis could be kept minor in scope. The alternative is a wild divergence in the code sets over time.

ichthus · Post by **ichthus** » 23 Mar 2006, 21:34

cckramer, any comments on whether you will work with the team to try to get the UI changes into mantis core? I think that would be the majority of your changes, thus keeping your branch relatively easy to maintain.

cckramer · Post by **cckramer** » 24 Mar 2006, 15:38

ichthus:
plese see FAQ on http://enargi.com

ichthus · Post by **ichthus** » 24 Mar 2006, 16:13

:D Excellent.