[Qgis-developer] Project quality discussion

Ahmed Dassouki dassouki at gmail.com
Fri Nov 6 07:23:21 PST 2015 

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:


   1. How much time are contributors spending on a bug (understanding the
   problem, designing a solution, developing, testing, and deployment?
   2. How much time are contributors spending on exciting value-added
   projects vs. “this should’ve been done right the first time” projects
   3. 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.)
   4. 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?
   5. 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?
   6. 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 <http://imgur.com/kYnqnQ0.jpeg>


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
<http://i.imgur.com/iwT5zmG.jpeg>


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 <http://i.imgur.com/4wIuS57.jpeg>


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 <http://i.imgur.com/iXISWr4.jpeg>

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:*


   1. 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?”
   2. We then Analyze the data for trends and analysis such as ANOVA, cause
   and effect diagrams and Failure Modes and Effects Analysis (FEMA)
   3. 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20151106/4d61b084/attachment.html>

More information about the Qgis-developer mailing list