25 Replies Latest reply on Oct 29, 2007 11:53 PM by Gaston Dombiak

    Proposed Process for Community Bug Reporting & Patches

      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.

       

      -


       

      Submitting Patches

       

      Process

      Community member: Sign the contributor agreement found at http://www.igniterealtime.org/ignite_contributor_agreement.pdf (for contributions by an individual) or http://www.igniterealtime.org/ignite_contributor_agreement_org.pdf (for contributions on behalf of an organization). Submit a discussion thread with a link to your patch and the tag "patch".

      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.

        • Re: Proposed Process for Community Bug Reporting & Patches

          Sounds great! I just added feed://www.igniterealtime.org/community/community/feeds/tags/bug_report to my bookmarks bar in Safari

          • Re: Proposed Process for Community Bug Reporting & Patches
            wroot

            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"?

              • Re: Proposed Process for Community Bug Reporting & Patches
                wroot

                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.

                  • Re: Proposed Process for Community Bug Reporting & Patches
                    LG

                    Hi Oleg,

                     

                    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.

                     

                    LG

                      • Re: Proposed Process for Community Bug Reporting & Patches

                        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!)

                          • Re: Proposed Process for Community Bug Reporting & Patches

                            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.

                              • Re: Proposed Process for Community Bug Reporting & Patches
                                LG

                                Hi Daniel,

                                 

                                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?

                                So we could get started today (;

                                 

                                LG

                                  • Re: Proposed Process for Community Bug Reporting & Patches

                                    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.

                                      • Re: Proposed Process for Community Bug Reporting & Patches
                                        wroot

                                        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.

                          • Re: Proposed Process for Community Bug Reporting & Patches
                            LG

                            Bug Reporting

                             

                            Hi Dawn,

                             

                            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

                            • Re: Proposed Process for Community Bug Reporting & Patches
                              LG

                              Submitting Patches

                               

                              Hi Dawn,

                               

                              how many lines may the patch have?

                              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?

                              • Re: Proposed Process for Community Bug Reporting & Patches
                                Stefan Reuter

                                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.

                                • Re: Proposed Process for Community Bug Reporting & Patches

                                  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.

                                    • Re: Proposed Process for Community Bug Reporting & Patches
                                      LG

                                      Hi Dawn,

                                       

                                      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.

                                       

                                      LG

                                    • Re: Proposed Process for Community Bug Reporting & Patches

                                      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.

                                       

                                      You can find the process in this document  Ignite Process for Community Bug Reporting & Patches

                                        • Re: Proposed Process for Community Bug Reporting & Patches
                                          wroot

                                          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.

                                        • Re: Proposed Process for Community Bug Reporting & Patches

                                           

                                          I hate to be the one negative voice here but....

                                           

                                           

                                          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.