Using JIRA for Minkata test shard bugs

[Dot]

A thread for questions and (hopefully) helpful answers...

1. Should there be a project specifically for the Minkata shard? Or should we set up issues someplace else? If the latter, where?
2. Is there a gentle, step-by-step, non-techie guide on using JIRA?

[rarified]

My original thought was that issues entered into JIRA would be categorized into the specific component where the issue occurred. Obviously this requires a bit of knowledge of the structure of the game to decide whether it is in the client programming (category CWE), game play programming, e.g. actions of the avatar and behavior of objects in ages (MOULSCRIPT), or a server issue (category MOSS).

Do you think that's asking too much even for the more sophisticated game player/reporting person? We could set up Minkata as a project unto itself, but would then have to reassign the bug to the correct category as part of our work on it, and that might be just as confusing to have the bug disappear from the Minkata project for the original submitter.

_R

[Dot]

Being honest, I'd find it difficult to know how to categorise the issues like that. I was thinking of volunteering to help transfer stuff from the helpdesk to the JIRA system, but I now know that I don't have the required level of expertise or understanding. Hopefully there are others who DO have that in-depth knowledge and a willingness to help.

From what you are saying, creating another JIRA project specifically for the Minkata shard would be a redundant layer and hence pointless.

So it looks like the best thing for us less-techie testers (if not those actually doing the hard work behind the scenes) is to continue to use the Hesk ticket system to report on issues seen within the shard. Then those who do understand the JIRA project/category structure can copy them across and categorise them correctly. Much as was originally suggested, in fact!

[JWPlatt]

For people like Dot, which may be most people willing to help, it might help them best to have a Minkata project in which to transscribe those issues. That at least gets the issues from Hesk to JIRA simply and quickly with a basic knowledge of both. Then folks who would do the tech anyway can categorize it. Having it already in JIRA is a big help and we can't expect the developers, whose greater value is in developing, to be spending their time on this work when most community members could. Though the developers can surely do some of it themselves if they are willing and have the time. Also, we can expect folks to become more competent as they gain more knowledge of the issues and could begin to categorize things themselves over time.

[rarified]

Mac and I were chatting offline about this, and thought perhaps it would be best to let issues sit in Hesk while a developer initially evaluates it. The volunteer can ride herd on asking the right questions from the submitter, it doesn't do much harm to stay in Hesk until it's known where to place it in JIRA. Then we don't have to play "who's on first" over on JIRA.

Thoughts?

[JWPlatt]

That's how it works normally in DeskPro, for example. Devs and other techs can be contacted for comment in the background, invisible to the user, while customer support communicates in the foreground with the user. Hesk is more simple. My thoughts here question how the developer will be contacted and how Hesk support will know who to contact. Otherwise, the devs will have to monitor everything in Hesk as well as JIRA so they can jump in at the right time. That could be a burden until Hesk volunteers are more experienced. I'm also thinking developer exchanges will be loaded onto Hesk instead of JIRA where it will be more important.

I'm not opposed. It's a good idea, and does appear to help Hesk volunteers, but may place more venues of responsibilty on the devs.

[Dot]

Having just had a go at copying an existing ticket from Hesk to JIRA, using the category that a kindly dev suggested in the ticket, I'm wondering whether JWPlatt's suggestion would be the way to go: a Minkata shard category in JIRA as a staging post that devs could quickly review and redirect individual entries to the correct area.

Why? If it would help, I think I could group and summarise observations within Hesk tickets and set up a general description of them within the JIRA system that could then be refined by others doing the work behind the scenes.

[Marten]

After today's conference between JW, rarified, Mac, Hoikas and myself, this seemed like a good time to bump this thread and clarify the role of Hesk and JIRA. This is a general explanation and may not cover every little detail. I'll correct any glaring errors or omissions if others will kindly PM me what to edit.

Testers are encouraged to file their tickets into Hesk. Hesk provides a clear workflow and spaces for ticket necessities that might be forgotten when working in JIRA. It also does not require an account.

The OpenUru Staff, Hoikas, and I are all tasked with funnelling Hesk reports into JIRA. There are now four areas where we can file issues discovered on Minkata:

CYAGE - Cyan's MOUL Ages. Issues that are believed to be PRP (Age file) issues go here. While developers might investigate these issues, under the current license for Age data only Cyan can resolve these problems.

MOULSCRIPT - Scripts (Python). Related to Age data, but the scripts are open sourced so developers can fix them. Certain types of security fixes, Unicode support, and KI functions and most objects that can be interacted with via the mouse cursor are MOULSCRIPT items.

CWE - CyanWorlds.com Engine. This is the client software that testers are running on their computers. Examples of CWE tasks include improving overall portability, and security, and crash-proofness; physics engine implementation; networking; and graphics performance, such as faster rendering of shadows.

MOSS - The Myst Online Server Software. Networking changes and the player database live here. and Certain games such as Ayoheek and the Gahreesen Wall also require server support.

When an issue is moved into JIRA and marked "Resolved" in Hesk, this only means that we've "resolved where it's going to be filed." For example, a Minkata texture bug sat in Hesk until today when rarified created the CYAGE category to handle issues of that type.

There is no separate JIRA bucket for Minkata shard configuration issues. Rarified is trying to resolve those on an as-discovered basis and close the issues in Hesk without moving them into JIRA. In these rare cases, "Resolved" should truly mean "Resolved."

Edit: 25-Jan-2012 - Remove reference to Minkata spark as issue is too complicated to use as example