[Qgis-developer] Project quality discussion

[Ahmed Dassouki]

I sent this to Alessandro only instead of the whole list by accident!

>From the discussion so far, it seems that there is no common and well
understood "standard operating procedure" or "policies" for such issues.
QGIS, QGIS Core group, clients, paid and unpaid developers by clearly
outlining each person's role and responsibility and minimizing friction
could benefit everyone.

For this issue, two tools come to mind:
----------------------------------------------------
1. A project selection matrix based on the "triple bottom line" (TBL)
principles as they relate to QGIS's project and executive vision. For a
hypothetical example, the main variables could be "Increase in usage of
QGIS by different users", "Reduce errors and inconsistencies",
"addin/plugin helps solve an environmental problem and therefore can
contribute to GHG emissions reductions", "plugin could generate outside
revenue through consulting, hiring of staff, etc", "add in / plugin could
help QGIS be implemented at the corporate level", "add in / plugin lines up
with QGIS corporate and open source goals".
With this tool a group of technical experts an QGIS board would form a a
committee and meet to discuss potential projects, let's say once a month.
In that two hour online meeting, they would score each projects based on
all the variables at hand.
These scores would be combined into a matrix such as the following
http://bestbusinessprocess.com/wp-content/uploads/2014/03/Matrix.jpg .

2. When projects are scored through the TBL and plotted in the quadrant
chart, QGIS committee can then take them through a project selection flow
chart that would determine whether this will be done for free, money,
expected timelines,what are the benefit to cost ratio, etc.. For example,
if a project is a "quick-win", the core committee might decide to take
someone off an existing project and assign them to that; On the other hand,
if the project / add in is considered a "fill-in" as in a low priority for
the client, QGIS, community, and vision, then the prospective client can
pay to get the plug-in developed.

I think there is an opportunity here to develop some "Standard Operating
Procedures" in QGIS to make the process capable and predictable, as in if
at any point in time, someone submits a new idea, the path to development,
for hire, or rejection is clearly understood and replicable.

These are my two cents.

On Tue, Nov 10, 2015 at 4:05 AM, Alessandro Pasotti <apasotti at gmail.com>
wrote:

> 2015-11-10 8:52 GMT+01:00 Hugo Mercier <hugo.mercier at oslandia.com>:
>
>> Yes, that would be ideal.
>>
>> But do we have enough money for that ?
>> And is it a full time job ?
>>
>> Or to put it another way: what is the budget we can assign for this task ?
>>
>>
> The only concern I have with QGIS.ORG hiring a full/part-time dev is that
> could be hard to find a single developer that can review all parts of the
> code.
>
> I'd prefer if QGIS.ORG does the coordination part with internally
> financed resources and delegates/outsource the code review to a pool of
> core-devs.
>
>
>
>
>> On 09/11/2015 23:59, Nathan Woodrow wrote:
>> > The main problem I see in having a formal pay to review/merge model, no
>> > matter the scale, is that it is a pay to win model no matter how to
>> > goes.  If you have the money you can pay someone to push it though
>> > quicker which doesn't give others the same ability if they don't have
>> > the cash.
>> >
>>
>
>
> It depends on the individual PR, if it's the amazing cool new feature that
> everybody was waiting for, I suspect that some volunteers code reviewer
> will show up anyway.
>
>
>
>> > Personally the only way I can see this model working is if we have a
>> > full time dev for the project that can review most PRs, or the QGIS.ORG
>> > <http://QGIS.ORG> board can allocate funds to a core dev to review a
>> set
>> > of PRs. This way the project is in control and not "Hey X, I have a
>> > stack of cash here. Be a buddy and merge my stuff for me will ya"
>> >
>>
>
>
> What we need to avoid is that somebody pays for a feature and that it's
> included no matter how it is. But the quarantine for the core-devs and the
> QEP+code review for all others should work in that case.
>
> The advantages in having the PR queue managed by QGIS.ORG is that it's
> more neutral if compared with just hiring a core-dev to bypass the whole
> process.
>
>
>
> --
> Alessandro Pasotti
> w3:   www.itopen.it
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: 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/20151110/afb49178/attachment.html>