<div dir="ltr"><p class="MsoNormal">Hi folks,</p>
<p class="MsoNormal"><br></p><p class="MsoNormal"><i>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.</i></p><p class="MsoNormal"><br></p><p class="MsoNormal">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?</p><p class="MsoNormal"></p>
<p class="MsoNormal"><br></p><p class="MsoNormal">These are some of the questions that matter to me when
looking at the question at hand:</p>
<p class="" style="text-indent: -18pt;"></p><ol><li><span style="font-family:Symbol">·<span style="font-stretch:normal;font-size:7pt;font-family:'Times New Roman'">
</span></span><span style="text-indent: -18pt;">How much time are contributors spending on a bug
(understanding the problem, designing a solution, developing, testing, and
deployment?</span><br></li><li><span style="font-family:Symbol">·<span style="font-stretch:normal;font-size:7pt;font-family:'Times New Roman'">
</span></span><span style="text-indent: -18pt;">How much time are contributors spending on exciting
value-added projects vs. “this should’ve been done right the first time”
projects</span><br></li><li><span style="font-family:Symbol">·<span style="font-stretch:normal;font-size:7pt;font-family:'Times New Roman'">
</span></span><span style="text-indent: -18pt;">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.)</span><br></li><li><span style="font-family:Symbol">·<span style="font-stretch:normal;font-size:7pt;font-family:'Times New Roman'">
</span></span><span style="text-indent: -18pt;">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?</span><br></li><li><span style="text-indent: -18pt;"> 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?</span><br></li><li><span style="font-family:Symbol">·<span style="font-stretch:normal;font-size:7pt;font-family:'Times New Roman'">
</span></span><span style="text-indent: -18pt;">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?</span><br></li></ol><p></p>
<p class="" style="text-indent: -18pt;"></p>
<p class="" style="text-indent: -18pt;"></p>
<p class="" style="text-indent: -18pt;"></p>
<p class="" style="text-indent: -18pt;"></p>
<p class="MsoNormal"><b>Some of the analysis
that I’ve done looking at bug data up to May, 2015:</b></p>
<p class="MsoNormal">Between 2014 and 2015, bugs came in relatively steady and
predictive manner of around 40 a month.</p>
<p class="MsoNormal"></p>
<span style="font-size:11pt;line-height:115%;font-family:Calibri,sans-serif"><img src="cid:ii_150dd2bbe4d7e835" alt="Inline image 1" width="441" height="255"><br clear="all">
</span>
<p class="MsoNormal"> </p><p class="MsoNormal"><br></p><p class="MsoNormal"><br></p><p class="MsoNormal"><br></p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"></p>
<p class="MsoNormal"><img src="cid:ii_150dd2c39f0ef4f1" alt="Inline image 2" width="482" height="279"><br></p><p class="MsoNormal"><br></p><p class="MsoNormal"><br></p><p class="MsoNormal"><br></p><p class="MsoNormal"><br></p><p class="MsoNormal">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)</p>
<p class="MsoNormal"><img src="cid:ii_150dd2c72fcb6f6d" alt="Inline image 3" width="482" height="244"><br clear="all">
</p><p class="MsoNormal"><br></p><p class="MsoNormal"><br></p><p class="MsoNormal"><br></p>
<p class="" style="text-indent: -18pt;"><span style="font-family:Symbol">·<span style="font-stretch:normal;font-size:7pt;font-family:'Times New Roman'">
</span></span>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.</p><p class="" style="text-indent: -18pt;">dd</p><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><p class="" style="text-indent: -18pt;"></p><p class="" style="text-indent: -18pt;"><img src="cid:ii_150dd2df33f86941" alt="Inline image 4" width="482" height="374"></p><p></p></blockquote><p class="MsoNormal"><b>When it comes to the Lean Six Sigma stuff, it is important
to:</b></p>
<p class="" style="text-indent: -18pt;"></p><ol><li><span style="font-family:Symbol">·<span style="font-stretch:normal;font-size:7pt;font-family:'Times New Roman'">
</span></span><span style="text-indent: -18pt;">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?”</span><br></li><li><span style="font-family:Symbol">·<span style="font-stretch:normal;font-size:7pt;font-family:'Times New Roman'">
</span></span><span style="text-indent: -18pt;">We then Analyze the data for trends and analysis
such as ANOVA, cause and effect diagrams and Failure Modes and Effects Analysis
(FEMA)</span><br></li><li><span style="font-family:Symbol">·<span style="font-stretch:normal;font-size:7pt;font-family:'Times New Roman'">
</span></span><span style="text-indent: -18pt;">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.</span></li><li><span style="text-indent: -18pt;"><br></span></li></ol><span style="text-indent: -18pt;">If you folks are interested in I’ll be willing to lead
a project for QGIS as my contribution to the project</span><br><p></p>
<p class="" style="text-indent: -18pt;"></p>
<p class="" style="text-indent: -18pt;"></p>
<p class="MsoNormal"></p></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 6, 2015 at 9:21 AM, Hugo Mercier <span dir="ltr"><<a href="mailto:hugo.mercier@oslandia.com" target="_blank">hugo.mercier@oslandia.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
We had a discussion here in Las Palmas about the overall quality of the<br>
project.<br>
<br>
The main concerns / questions (I had) were:<br>
<br>
- big organizations are starting to fund QGIS. This is great but it is<br>
still a bit hard for a company to sell the development of a new feature,<br>
because it is hard to guarantee it will be integrated.<br>
<br>
- we still rely too much on volunteer work. And the situation becomes<br>
complicated when a paid development depends on volunteer work.<br>
<br>
These are my main conclusions.<br>
For people who attended, don't hesitate to complete if necessary. For<br>
the others, you are welcome to react of course.<br>
<br>
- every new feature introduced by a core developer should be sent as a<br>
Pull Request first. With a given "quarantine" delay after which the PR<br>
will be merged, even if no reaction. It will allow to share information<br>
and react in case of problems (and encourage people for good work as well :)<br>
-> should I create a QEP for that ?<br>
<br>
- if a company with no core developer wants to ensure a new feature is<br>
accepted, it should pay another core developer for the reviewing part.<br>
Ideally the money should go to the project and the project would decide<br>
what core developer(s) to pay.<br>
The details of this process are not very clear. It still has to be<br>
discussed. But the goal is to make clear for everyone that if you want<br>
guarantee: you have to pay for it and there is a clear process to handle<br>
that.<br>
<br>
- writing a QEP before adding a new feature is a good way to increase<br>
its acceptance. But some people have to review it. We may come to the<br>
same process to pay for QEP reviews.<br>
<br>
- at which point we rely on volunteer work is not yet clear. But the<br>
current guess is: still too much. Having a better idea of the ratio<br>
between free work and paid work would be profitable for the project: it<br>
would allow to make clear what the reality of an open source project<br>
like QGIS is and that too much free work is not sustainable. Paolo's<br>
mail is about that. The goal is to (begin to) separate clearly what is<br>
the part of free work and the part of paid work in the project.<br>
<br>
- see on the PSC side if it is possible to pay some people to handle<br>
global maintenance : PR triage, reviews, small bug fixes and so on. It<br>
does not have to be only one developer.<br>
<br>
Thanks for participating in this discussion.<br>
<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Ahmed Dassouki<br></div>
</div>