I’d like to suggest dropping the JM- Jira tickets and starting a new OF- for tickets. I’d be happy to be in charge of triaging tickets and be the default assignee.
daryl
Matt: please look at: JM-1519
This begs the question then, is there value in having past ticket history? If so, we would want to somehow keep the old data (maybe just turn the JM issues read-only?) Personally, I think its good to have the ticket history, and the ‘JM’ tag, while confusing to new users, is just an identifier.
I would like to see the tickets cleaned out though. There are some old bug reports that should just get closed so when we look at the open bugs for openfire (and Spark/Smack/etc) we have a realistic idea of what the current issues are. We need a “WONTFIX” status option for some, Im sure, but that might be worth it to manage the task.
How about we create OF and leave JM alone to preserve history (moving bugs into OF as we see fit). We can then move bugs over as necessary. If that sounds good, I’ll make it so.
-Matt
Yes please, I wrongly implied deleting the old JM tickets. I tried going through all the old open tickets twice and didn’t yield many comments back asking for more info / current validity.
daryl
If we do a poll in this private group, can others see it? Or is it hidden like the discussions?
Poll options:
Keep it as-is
Migrate all JM issues into OF
Migrate only key JM issues into OF
Start over with clean OF (open new issues as-needed)
Any polls would be only for this group.
Slush – I should also add that a poll is probably not necessary in this case given the small number of people we’ve kicked off this group with. If you think we shouldn’t create an OF JIRA target then I’d suggest they two of you guys work out a proposal and then present it. That way we’ll keep things moving as quickly as possible.
Then I suggest an Ultimate Fighting Championship-style deathmatch to determine the right way to do this 
Ok, seriously, I dont deal with Jira that much. As long as the old tickets are around for nostalgia, I yield to the ones who will be using it more. It might be worth getting a few more people’s input before acting, but even of the options I posted I have no strong attachments to any of them, and I bet most people dont care much either. Since Daryl seems to be leading the charge on ticket tracking, Im ok with going that way too
Yeah, probably best to let this vett for a while as I am probably missing a complication with doing this.
I’m plowing through old tickets again! hehe
daryl
This is now done. You guys should be able to access OF the same way as JM. Do you guys have access to create release targets and such?
I dont think we need a poll as forum visitors dont really care much about the polls and project managing. I think so far we all agree to save/archive the old ones and move important tickets to the new sub category OF. I hope forums will be tweaked to generate links to OF-** automatically, so forum visitors won’t get too much confused as the links will work.
While i’m here, can i ask for a bit more powers in JIRA too? At least i want to be able to close my own tickets if i see that it is a mistake, won’t fix or already resolved. And i want to be able to delete attachments. Cause now i can’t and i have to attach another and another file while the patch is updating. Choosing the version for fix is not so important to me, i’ll leave that to Daryl to judge
While i’m here, can i ask for a bit more powers in JIRA too? At least i want to be able to close my own tickets if i see that it is a mistake, won’t fix or already resolved. And i want to be able to delete attachments. Cause now i can’t and i have to attach another and another file while the patch is updating. Choosing the version for fix is not so important to me, i’ll leave that to Daryl to judge
I dont think I can grant those rights (though, maybe I can… Ive never looked). But I think all of us in this group should have those rights.
Also, what do we think about relating the svn “mentoring” with Jira? Such as you start out with basic access (can create new issues reports, comment, etc) and as you prove yourself access privs is gained. We would need to have some documented policy for this as well. Any ideas?
Maybe we should create two documents in this group: SVN Commit Guidelines and JIRA Access Guidelines.
One thing that i think should be in JIRA doc, is that a ticket author should add a link to a forum where this bug was reported (if available). So the power user closing the ticket should also post in that forum thread. I mean, that this is just to much for a simple user to have to create a JIRA account to be able to watch the ticket. Most of the users think JIRA is a restricted area and won’t even try, so the forums is the best place to notify about the ticket status. Personally i’m doing this when it’s possible.
Slush mentioned about the mentoring system in JIRA. So simple users won’t be able to create accounts? Or maybe we should leave that option with only Comment right. Then the second level would be Ticket Creation, File Attachment (maybe just in one product category). And then the third level - All Access - Create/Close tickets, Delete Attachments, Change fix version. What about the right to give rights? Maybe this should be reserved to some single user or the small group of mentors as we are here (3-4 persons)?
As for ‘closing’ bugs not only in JIRA, but also in a forum thread where it got reported, I agree that this is good practice. We should keep doing this.
I’m not sure if we need seperate documents to describe the “good practice” applicable to every subsystem: maybe we can avoid a bit of overdocumentation by combining them into one document.
I’m in favor of keeping JIRA open to this extend that anyone can create an account and report a bug. It’s up to a limited group (us?) to resolve these bugs. Only these people should have the corresponding JIRA privileges.
Is it possible to link SBS and JIRA users to the same set of credentials? This might lower the bar for community members to make use of JIRA to report bugs there?
Linking of SBS and JIRA accounts is what i was thinking about 4 years ago, when i had to create a separate account in JIRA Would be great, but maybe this is just too complicated.
As about opening JIRA to everyone to create tickets, i think at least Matt (and Gato) will disagree and i’m leaning more towards this position. I’m currently seeing a lot of “bug reports” in forums where people are just too novice to configure program, they dont read documentation, etc. Also, when a person is providing a patch to what he thinks is a bug, then another replies in that thread and says that different piece of code should be patched. So, with the free access to everyone there could be some conflicting tickets or arguing in the ticket’s comments, though i think discussion should be going in the forums.
I’m not that worried about JIRA mis-use. I think things will work out automatically, as people tend to use tools that they like to report bugs:
People that will make use of the opportunity to report in JIRA directly will be used to working with bugtrackers: these people tend to give you more valid (or less crappy) bug reports. Us giving them access to JIRA indirectly indicates that we take them serious. In my former job, co-workers (developers) always frowned on having to report a bug in a forum. I’m sure that there are developers out there (I’ve talked to a couple of them) that won’t report bugs to the forum. For some reason, having to sign up for a community is more of a burden to them than to sign up for JIRA (something they’re more comfortable with)
The type of people that is likely to give you inaccurate, or plain false bug reports, are often more comfortable with a forum-type of thingy. They’ll keep reporting bugs there.
In any case, both JIRA and SBS would be complementary.
If we’d like to turn on the ability for end-users to report bugs directly in JIRA then I’d support that. But, that system needs fairly constant gardening to keep the issues well-managed. Would someone from this group be willing to step-up to be a JIRA administrator (in addition to Gato and myself)? They would:
- Ideally already be reasonably familiar with JIRA. Especially helpful would be experience with the admin side.
- Be responsible for controlling which users should have access to the system and how.
- Ensure that bugs are getting triaged by putting in triaging time or recruiting other community members to help out.
Any takers?
Thanks,
Matt
Im torn- End users must have a way to report bugs, and I feel that the forums is an ineffective place for that. But on the flip side Ive seen enough bugzilla installs full of untouched bugs, duplicates, and non-issue reports to make me somewhat wary of giving “easy” access to all.
I like the idea of having some process to be given a “bug reporter” status. It dosnt have to be a high bar, but something. Maybe something as simple as you need to have an account on the forums and 50 points before you can request an account (and you must request it, its not automatic). It stops the drive-by bug reporting, but makes it easy for people to report things.
As we open up the bug reporting (and feature requests, etc) I think we need more options of what to do with them. I only see “resolve” and “close” options. To be able to handle some of the junk that comes from opening it up, I would like to see some other options for an issue status such as:
wont-fix: Its a known issue/bug, but for some reason we cant/wont fix it. Might apply better to feature requests (we wont implement XEP-9999, etc) but sometimes a bug is so weird, and there just isnt the manpower to fix it. The oddball OCSP problem I ran into would be an example. If I personally was not willing to fix it, it never would have happened.
not-a-bug: Someone reports a bug, and it isnt. Im not a fan of deleting things unless there is strong cause for it. Spam can be deleted (but with a vetting process we hopfully wont have too much), but sometimes keeping these other not-a-bug reports around can be useful (25 people report the same not-a-bug; maybe we should look at it closer)
need-a-developer: A bug/feature that is highly desired, but there simply isnt the manpower to fix it, and no one is assigned the task. Think like the virtual hosting request- we all want it. No one has the time. By giving it this status, people will understand why no progress is being made. I dont like just assigning bugs/features to a person if there is no intention of working on it. Maybe this is a placeholder account instead of a status, or maybe its a status with “UNASSIGNED” as the developer.
Is anyone in the group familiar enough with Jira to help “take over” some of these changes? Im not terribly familiar with Jira, but in the absence of anyone else, I would be willing to step up to the plate.
I have no experience with JIRA administration, but i can try if there will be noone else willing. Shouldnt be very hard i hope But i didnt quite understand about the “triage”. Do you mean setting the time when a bug should be fixed? With the current manpower it could be hard to estimate.
Slush, there is such status as Won’t Fix in Jive JIRA already.
P.S. Btw, i’m already monitoring JIRA (Spark and Openfire) for the new issues per day for some time.