Hi Ahmed,
Well - there is an easy explanation of the spikes on bug fixing: prior to each release (in the feature freeze month) we pay 2-3 devs to work one week each on bug fixing. There is not a sudden increase of volunteers - it is simply the paid work. And there is increased testing in this period - and thus also more bugs reported. You'll find similar patterns for donations. After each release there is a spike of donations (currently, there is one such peak). Maybe we should increase our release interval and release every month --> would probably result in more donations ;-) just kidding. Andreas On 2015-11-06 16:23, Ahmed Dassouki wrote: > Hi folks, > > _preface: I wrote this on the fly so I didn't really review the grammar or > structure. I am very passionate about QGIS as I've been using it since 2007 > and I'm also extremely passionate about traffic/transportation issues and > Continuous improvement culture within organizations._ > > Back in June, I had started a small analysis project on bugs in QGIS. The > question I was interested in was "Are we fixing bugs in a controlled and > predictable manner; while keeping the end user and volunteer developers > happy?" I didn't go far beyond my personal analysis as It was primary a fun > project. > > Some of the results and thoughts might be helpful to answer Paolo's questions > on time spent based on my experience in continuous improvement and lean six > sigma best practices. Six Sigma is all about involving and invoking the team > to find areas of "waste" from money, time, morale, to redundancies. How can > we make things better for the business, end users, and volunteer > contributors? > > Some of the thoughts and concerns that matter to me when looking at the > question at hand: > > * How much time are contributors spending on a bug (understanding the > problem, designing a solution, developing, testing, and deployment? > * How much time are contributors spending on exciting value-added projects > vs. "this should've been done right the first time" projects > * What is the motivation or objective of the contributor to work on a certain > matter? (Subject matter expert in the area, making things more efficient, > Computer-bug-phobia, etc.) > * Is the process of adding a new feature or closing a bug "predictable" and > "controllable"? I.e. if a new bug comes in the system, can we successfully > predict the time and effort it will take to solve or close it? > * What is the current waste in operations? are we spending too much time > discussing something instead of "doing"? are there too many people approving > the same thing? is there a bottlekneck in the process? Are we catering to > what the volunteers and core developers want to do? Do we find ourselves > spinning our wheels? How long is the end user waiting for their product to be > patched / fixed? > * What is the cost of doing nothing? What is the cost to the end user if no > contributors fix a bug on time or work on a feature. Conversely, what' the > cost to the end user and QGIS community if users don't submit bugs. What's > the cost to QGIS if you have contributors working on mundane (to the > individual contributor) vs. exciting issues, i.e. how to keep the positive > momentum going in a predictive and creative way in an environment where the > core are volunteers doing this for fun? > > SOME OF THE ANALYSIS THAT I'VE DONE LOOKING AT BUG DATA UP TO MAY, 2015: > > Between 2014 and 2015, bugs came in relatively steady and predictive manner > of ~40 a month. Bugs Created Chart [1] > > The bugs closed, rejected, or revised varied between 15 and 45 per month. I > assume the "spike" is due to an anticipated release or freeze. However, one > can notice that in April and May, the process was not predictable and a large > number of bugs were fixed in two months. It'll be interesting to see if the > trend continued between June and November. Closed Bugs Chart [2] > > Similarly, in the graph below showing how many bugs are still open per month, > it seems that there is some correlation between the number of bugs opened and > closed per month. (graph looks different as I did it in R instead of Excel). > Bugs Open Chart [3] > > 75% of the bugs were closed in less than 31 days with 50% closed between 15 > and 31 days. Conversely 75% of the bugs have been open for not more than 22 > days. Boxplot Charts [4] > > Overall, great results so far! but this was just based on a dump from the > issues db. > > WHEN IT COMES TO THE LEAN SIX SIGMA STUFF, IT IS IMPORTANT TO: > > * Define and the problem, understand the process and see where the "waste" is > generated. Another way of looking at this is "Do we have a problem, and is > our process predictable and capable?" > * We then Analyze the data for trends and analysis such as ANOVA, cause and > effect diagrams and Failure Modes and Effects Analysis (FEMA) > * Finally, a recommendation is made by saying, this is what is working right > now, this is where it's failing, and here's the effect on the end user and > volunteer contributor. > > If you folks are interested in I'll be willing to lead a project for QGIS as > my contribution to the project > > On Fri, Nov 6, 2015 at 11:00 AM, Hugo Mercier <hugo.merc...@oslandia.com> > wrote: > >> Hi, >> >> Are you registered to the list ? >> It might be that your mail contains images. If you try to replace them >> by external links, that might work better. >> >> On 06/11/2015 14:39, Ahmed Dassouki wrote: >>> I replied to this thread with a lengthy email that requires moderator >>> approval. >>> >>> On Nov 6, 2015 10:37 AM, "Hugo Mercier" <hugo.merc...@oslandia.com >>> <mailto:hugo.merc...@oslandia.com>> wrote: >>> >>> >>> >>> On 06/11/2015 14:00, Yves Jacolin wrote: >>>> Hugo, >>>> >>>> This is mainly focus on development of new features but we can add >>>> documentation and translation in the same way :) >>>> >>>> Does new feature shold imply documentation? >>> >>> The original plan was to talk about that, but we did not. >>> >>> I would be in favor of that ideally. A new feature = code + tests + >>> documentation. >>> But one step at the time. We could start by inviting developers of new >>> features to include documentation as well. And if it does not work, try >>> to enforce it somehow. >>> _______________________________________________ >>> Qgis-developer mailing list >>> Qgis-developer@lists.osgeo.org <mailto:Qgis-developer@lists.osgeo.org> >>> http://lists.osgeo.org/mailman/listinfo/qgis-developer >>> > > -- > > Ahmed Dassouki > > _______________________________________________ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer Links: ------ [1] http://imgur.com/kYnqnQ0.jpeg [2] http://i.imgur.com/iwT5zmG.jpeg [3] http://i.imgur.com/4wIuS57.jpeg [4] http://i.imgur.com/iXISWr4.jpeg
_______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
