As promised, I have been working on a process to better manage Community Bug Reporting & Patches for the Ignite Realtime Community. Here’s the proposed process - please post any feedback to this discussion. I’ll finalize this and put it in a document sometime next week. I tried to keep it simple & easy, but with a specific escalation process that community members can use for any issues.
Filing Bugs
Process for Community Members
Check to see if the bug has already been filed in JIRA
If not, post a discussion with the tag “bug_report”
Responsibility
Dawn to maintain JIRA access rights
Project Responsibilities: The people below should monitor their communities for items tagged with “bug_report” and respond to each thread with either the number of an issue in Jira or an explanation of why it is not a bug.
Openfire: Gato
Spark: Derek
IM Gateway: Jadestorm
Smack: Gato
XIFF: Derek
Asterix IM: srt
Escalation
If you do not see a response to your thread with either the number of an issue in Jira or an explanation of why it is not a bug within 7 days, send a private message to Dawn with a link to your original discussion thread. Dawn will harass the owner above to respond.
If accepted, owner (responsibilities below) will put it in Jira and then it will go into an appropriate release of the code.
If not accepted, owner will respond to the thread with an explanation.
Responsibility
The people below should monitor their communities for items tagged with “patch” and respond to each thread with either the number of an issue in Jira containing the patch or an explanation of why it was not accepted.
Openfire: Gato
Spark: Derek
IM Gateway: Jadestorm
Smack: Gato
XIFF: Derek
Asterix IM: srt
Escalation
If you do not see a response to your thread with either the number of an issue in Jira containing the patch or an explanation of why it was not accepted within 7 days, send a private message to Dawn with a link to your original discussion thread. Dawn will harass the owner above to respond.
About tags. Some time ago we were discussing it and slushpupie suggested to use “bug” tag. I think this is more simple and is already in use (check tags popularity). Or should i edit all my bug reports again and change the tag to “bug_report”?
this makes it far to easy to report a bug. If I have a random problem I add bug_report to make sure that a “Jiver” responds within 7 days even if this is not a bug. Quite often users report things which are named bug and sound like a bug but without a detailed test case no one can reproduce this, so it usually takes long to get one.
If a user wants to report a bug the user should supply a test case (or clarify why this is not possible), otherwise your developers will spend hours on asking for one to make sure to be able to reproduce the problem. And one should be forced to add the logs of Spark and Openfire and probably a screen shot *1. I hope that Francisco can offer a draft document for creating a test case, where one must enter all information one needs to enter in JIRA (version, operating system, LDAP, database, environment, …) and a test case.
LG
*1: Maybe you can add a moderated space where everyone can create documents with attachments, or create TODO for the CS(x) developers:
Allow the CS(x) administrators to select Create Document Attachment and then to specify the file types (which are checked after upload):
text, image pdf, exe, dmg, any, …
and if one can upload these within an archive, like zip, rar, tar.bz2, tar, tar.gz and tgz, jar
How critical must the problem be which is solved by the patch?
If I send 100 lines of code to a developer which improves speed a little bit then I’m sure that there is no time to review it. So one may want to limit the critically and the # lines of code a patch may have to be accepted.
.oO(I may feel free to post again my database connection pool patch which may be two years old now.)
LG
PS: Also within patches - what about a moderated area where one can post the patches?
I’m not so sure line count is a good way to handle it. I’ve made patches with huge line counts but very little complexity, and patches that change just a few things but have tons of testing implications.
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.