[Qgis-developer] Project quality discussion

Ahmed Dassouki dassouki at gmail.com
Fri Nov 6 06:30:40 PST 2015


Hi folks,


*preface: I wrote this on the fly so I didn't really review grammar or
structure. I am very passionate about GIS 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 projects on bugs in QGIS that
its results might be helpful to answer Paolo’s questions on time spent
through 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?


These are some of the questions 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 around 40 a month.

[image: Inline image 1]






The bugs closed, rejected, or revised varied between 15 and 45. 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.

[image: Inline image 2]





Similarly, in the graph below showing how many bugs are 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)

[image: Inline image 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 for not more
than 22 days.

dd

[image: Inline image 4]

*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.
   4.

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 9:21 AM, Hugo Mercier <hugo.mercier at oslandia.com>
wrote:

> Hi all,
>
> We had a discussion here in Las Palmas about the overall quality of the
> project.
>
> The main concerns / questions (I had) were:
>
> - big organizations are starting to fund QGIS. This is great but it is
> still a bit hard for a company to sell the development of a new feature,
> because it is hard to guarantee it will be integrated.
>
> - we still rely too much on volunteer work. And the situation becomes
> complicated when a paid development depends on volunteer work.
>
> These are my main conclusions.
> For people who attended, don't hesitate to complete if necessary. For
> the others, you are welcome to react of course.
>
> - every new feature introduced by a core developer should be sent as a
> Pull Request first. With a given "quarantine" delay after which the PR
> will be merged, even if no reaction. It will allow to share information
> and react in case of problems (and encourage people for good work as well
> :)
> -> should I create a QEP for that ?
>
> - if a company with no core developer wants to ensure a new feature is
> accepted, it should pay another core developer for the reviewing part.
> Ideally the money should go to the project and the project would decide
> what core developer(s) to pay.
> The details of this process are not very clear. It still has to be
> discussed. But the goal is to make clear for everyone that if you want
> guarantee: you have to pay for it and there is a clear process to handle
> that.
>
> - writing a QEP before adding a new feature is a good way to increase
> its acceptance. But some people have to review it. We may come to the
> same process to pay for QEP reviews.
>
> - at which point we rely on volunteer work is not yet clear. But the
> current guess is: still too much. Having a better idea of the ratio
> between free work and paid work would be profitable for the project: it
> would allow to make clear what the reality of an open source project
> like QGIS is and that too much free work is not sustainable. Paolo's
> mail is about that. The goal is to (begin to) separate clearly what is
> the part of free work and the part of paid work in the project.
>
> - see on the PSC side if it is possible to pay some people to handle
> global maintenance : PR triage, reviews, small bug fixes and so on. It
> does not have to be only one developer.
>
> Thanks for participating in this discussion.
>
> _______________________________________________
> Qgis-developer mailing list
> 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/3adb0ba9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 35542 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20151106/3adb0ba9/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 41313 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20151106/3adb0ba9/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 16186 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20151106/3adb0ba9/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 24531 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20151106/3adb0ba9/attachment-0007.png>


More information about the Qgis-developer mailing list