On the other hand “bug” tag is in use by everyone. One who thinks he find a bug, one who just dont know how to setup something. So maybe it’s better to use “bug_report” tag, so only advanced users and the ones who will read a document about bug reporting would use that, and this will help to filter not proper bug reports out. And anyone would be able to change his tag to “bug_report” at any time.
But i’m waiting for an official opinion about this. Cause i have a lot of bug reports and it will take some time to change all my tags.
as Clearspace lists the tags when creating a new thread a random user may simply click on both tags without thinking about it.
One should create an XML schema with required fields to report a bug and use a web based XML editor (similar to JIRA, so the user does not know about the XML document behind the scene (not sure if JIRA uses XML)) to allow the user to report the bug. I know that this sounds like a lot of work for the CS(x) developers but it’s a very compatible way as it allows automated export / transport of the XML data to other applications.
I have no idea if CS(x) already uses a simple XML schema for every discussion, anyhow this could be the case as they offer RSS feeds.
While you all do have great points, might I propose that we just “go with it” for now and see how it goes? I’m sure Dawn’s proposal isn’t set in stone and if it turns out that things aren’t going smoothly, the process could be reevaluated! (but there’s also a good change it’ll be just fine!)
Crap, didn’t finish my thought. LOL One thing I might propose, if it’s possible, is to not have Derek and Gato as the primary monitors for multiple forums. I will admit that part of why I’m able to keep up with the IM Gateway forum is that it’s all in one place. =) Even if Derek and Gato are the primary for multiple projects, it might be helpful to assign someone else to be the main forum monitor for one of their projects. (then again this may all be moot with RSS feeds)
I do agree that the listing of the tags at the bottom which would list bug_report as a choice will likely cause a lot of “ooh, that’ll probably get some attention” clicks. I don’t know that there’s a way around that though. One of the things I had conceptualized previously and was considering writing a plugin for was some sort of alternate submission form that looked like a scaled down jira bug report. For example something that has other fields in it like operating system and java version and whatever… not -too- specific, but more than just a normal forum post. That could be auto-tagged with bug_report or something and would “look” like a bug report to the end user and could encourage gathering of more data and… that sort of thing. The problem there being, of course, that involves writing the code for it instead of just implementing it via a policy change. =) I will admit it’s hard for me to choose “something else” over the IM Gateway plugin pending release when I have free time.
But yeah, like I was saying before, I like the proposal and I would propose that we run with it for a time and see how it flies.
the proposal looks nice, but I wonder how much time the developers will spend in reviewing bug_report threads. Anyhow it would be nice if they would comment some more problems, some of them use the forum not very often to do this. But the reports should be detailed so one does not need to much time to verify this error and create a JIRA issue. The more detailed the reports are the more users can review it and create a JIRA issue while I’d prefer a button “Create JIRA issue” which one can modify later. So even you (; could verify an Openfire problem and create the issue.
As far as I can tell the guys in the USA do not have any holidays and go to work even if they are very ill, so there should be no problems with holidays or so. A single person for review and escalation may be not enough.
Maybe I should ask some very personal question:
Are you happy with the bug reports for the gateway plugin as they are currently?
Would you like to be the first one to introduce this process within the gateway forum?
I think the proposal is good. Having a defined process is a big plus and allows for incremental improvement.
Should only developers be allowed to create issues in Jira? I could very well think of experienced community members helping with evaluating bug reports, enriching them with steps on how to reproduce the problem (if not already included) and transforming the report into a Jira issue for further handling by the devs. This might solve the scaling problem and leverages community involvement.
Howdy LG! I actually am happy with how things are in the IM Gateway forum currently … I generally pay attention to every last thread that comes in. I certainly wouldn’t mind spearheading the process there though! I’ll wait just a bit though to see how this thread goes. =) To address something you said and also that srt said though, I would certainly not mind “deputizing” a few people that are active within my forum to be permitted to create JIRA issues. I mean right now I am good at keeping up but you never know what the future will hold!
One “problem” I could see with this bug_report tag though is there’s not really a good way to, how shall we say, stop considering it a bug. You’d have to pop in every thread and see if the associated jira issue was closed or not. (assuming of course a jira issue was created for all of them) Is that a real issue? I’m not sure.
Yes. I was thinking about this too. After migrating to CS i have similar problem, when all my questions became simple threads and i cant distinguish between answered and not answered questions. So, maybe there should be some other indicator, not a tag available for everyone. And then some members, who would have such right (power ) could turn that indicator on in the thread. And maybe there could be a rss for threads marked with that. But this feature is very specific to software development teams and common CS setup wount need this. So maybe this functionality could be provided by a plugin for CS.
This is all great feedback. We are trying to keep this process lightweight and easy to use, so we’re trying not to make it too complicated. I do like the suggestion of adding test cases, logs, etc. to the bug reports, so I’m working on the best way to add that info to the process. I should have another version of this process in a couple of days.
I wonder if you want to create a document this time and allow everyone (which does not really mean everyone) to edit it, if I remember right CS(x) is a collaboration tool. Users without edit rights may still add a comment like we did, but all replies to your first proposal were from users with edit rights. You may also add yourself as moderator so you can still reject or approve the changes.
Great feedback from everyone. I incorporated as much as I could. I also agree with jadestorm; we just need to run with something, try it out & see what works & what doesn’t. I expect that we’ll need to revise it along the way.
About logs and screenshots. I dont agree this is a MUST, not for the all reports. Especially if i report some GUI issues. Spark logs often doesnt contain any errors about that. Actually i dont remember any case when spark logs posted by me were useful for anyone. Screenshot could be useful to show something what is hard to describe. But i dont need to make a screenshot to say prove that Spark popups are showing wrong presence status. I think there should be some response from the devs anyway (asking for more info, asking fot some specific info, logs, screenshots) and not the demand for reporters to give tons of info in the first post. You know, we dont want to waste our time too.
I’ll tweak the process to say these are encouraged, but not required for every case. I do want to leave them in the process just to remind people to think about the fact that the logs might be useful
Also keep in mind that this process is more of a guideline than a rule. Include what makes sense, but don’t sweat it too much.
if one is sure that Spark is running fine one can always update empty logs. But one should look in the log files before reporting a bug, or at least upload them. I agree that this is not always necessary but it may help to upload them.
It’s usually better to do upload things initially than to get a “upload logs” response which is quite annoying. Every (bigger) vendor requires this as a problem or bug report alone usually helps no one. And if a customer wants a fix then a testcase is also required.
Do you want to add a second icon below the status bar to users which successfully report a bug as mentioned in http://wiki.igniterealtime.org/display/NINJA/HowtoBecomeaNinja to tag them as “Ninja Initiate” ?
No amount of outlining a process is going to magically turn forum software into bug tracking and reporting software. Forum software is just too free form. You can write up a process document that outlines that all bug reports need to be tagged a certain way and should include version of software in use, how to reproduce, error messages, platforms affected, severity level, etc BUT unless you actually use an html form that requires all these fields then it will never be done correctly.
It’s also way too easy for the developers to become busy and miss a bug reporting thread. Why should the reporter have to track down one Jive employee to bug another one in order to get the bug noticed? With real bug reporting software you can schedule report generation and automatically nag the developers. The Smack forum seems to be only loosely monitored as I’ve had to send emails in the past to get my threads noticed.
I fail to see why the community shouldn’t have the ability to directly file bug reports.
I think Jive needs more man-power. Spark forum is dead (speaking about developers involvement). Derek is not enough and actually i dont see him much lately. LG is filling some bug reports in JIRA sometimes, but even those dont get attention. Everything started from my thread which i have posted few months ago (about getting tired of unactive community/developers). Process outlining is done, tags are discussed and that’s all. Nothing is changing.
There probably is a lot of man-power that can be tapped just by lowering the barriers for helping. The top of this page says “A Jive Software COMMUNITY”. Why not actually allow the community to be more involved? Not only with bug reports but by creating documents too. Take Smack for example, there isn’t a single online doc at http://www.igniterealtime.org/community/community/developers/smack?view=document s. I’d create some if I could. The downloadable Smack docs don’t actually come with a runnable example. Guess what a lot of the questions are about on the Smack form… I’ve posted examples but they just get buried after a while.
Hey Jive! You’ve created something we like, now let us help already. And not just a few of us, all of us.
