[Qgis-developer] Project quality discussion

Fri Nov 6 08:27:01 PST 2015

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.mercier at 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.mercier at oslandia.com
>>> <mailto:hugo.mercier at 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 at lists.osgeo.org <mailto:Qgis-developer at lists.osgeo.org>
>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> 
> 
> -- 
> 
> Ahmed Dassouki 
> 
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20151106/77c4f21d/attachment.html>