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.
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.
Triage means:
- See if this issue has already been reported. If it has, link it to the other issue as a duplicate and close.
- An initial pass to make sure the issue has enough data to take action on. For example “Openfire is crashing” is not very helpful and needs more info.
- Assign the issue to a developer if you know who should work on it
- Assign the issue to a particular release if there’s enough data plus a priority. For example, a security bug should be a P0 to be fixed for the next release.
I’m fairly familiar with JIRA (not so much with adminstrating JIRA, but I’ll manage. I’ll be happy to help out.
Slush’s resolutions work for me, with a couple of sidenotes:
- There already is a resolution called “won’t fix” in the default JIRA installation.
- I’d rename the ‘need-a-developer’ resolution into “postponed (indefinately)”, which in my opinion is more of a resolution than the former. The reason for postponing should be documented in a JIRA comment. This way, we could resolve other issues using this resolution as well.
Hi Matt,
please refer to my initial message starting this thread
daryl
Daryl,
Excellent – you’re now an administrator. Let’s start a separate thread to discuss configuration ideas. Or, feel free to ping me directly.
Thanks,
Matt
matt wrote:
Triage means:
…
Ok. I get it. The first two is what we are currently doing in the forums. Though with the JIRA it will be more obligating.
Anyway. Slush and Guus have already agreed to step in. Maybe also Daryl is willing? How many people we need? Maybe 2 will be enough? At least so far, as there are not many spamers in JIRA
- I’d rename the ‘need-a-developer’ resolution into “postponed (indefinately)”, which in my opinion is more of a resolution than the former. The reason for postponing should be documented in a JIRA comment. This way, we could resolve other issues using this resolution as well.
I added a “Patches Welcome” ticket state, what do you think about that?
daryl
Sounds good. We should check if / make sure that people are able to attach patches, after we’ve resolved the issue using that resolution. Probably won’t be a problem.
Hi Benjamin and Chris,
Jive SBS needs to be setup to highlight these new Openfire tickets
OF-1
daryl
TINDER-1 also
JIRA hilighting enabled for projects OF-2 and TINDER-2 .