[Qgis-developer] Discussion on the QGIS grant proposals

Thu Sep 22 01:09:35 PDT 2016

Hello,

Thanks Andreas for raising this topic and clearing up facts and giving
your position.
I agree 100% with what you stated, and I do think this is something
which should be emphasized much more, if not even constrained.

Some more notes below.

On 22/09/2016 08:14, Neumann, Andreas wrote:
> [..] Now comes my personal position/opinion - note that this is not
> the official opinion of the QGIS.ORG board.
Same here

> I would personally welcome, if this round of the QGIS grants program 
> could focus on the QGIS 3.0 release.

This is indeed the main challenge for QGIS in the coming months.
Focusing on all aspects of making QGIS3 a real thing should be our top
priority when confronted to choices.

> I personally also think that the QGIS grants program, at least at
> the current time, should not pay for development of new features (at
> least not features visible in the GUI for the users). These features
> can be "relatively easy" funded by companies and government
> organizations out there. So our limited QGIS.ORG funds should be
> rather spent a) to community work or b) infrastructure work or c)
> development work in the core of QGIS, such as API modifications, code
> redesign - stuff that isn't really visible to the users, but
> essential for the success of the project.

>From a developer's company point of view, I can only applause to this.
We have numerous demands for new features with paid contract, and the
global pace of feature development in QGIS is really fast. The very
large majority of them are funded by clients.
Meanwhile, all tasks like refactoring, code cleaning, bug triaging,
infrastructure and long term core development efforts are really
difficult to get funded. Public sector organization generally can't pay
for this due to public tender bid constraints, and generally end-users
do not realize that this kind of work is at the same time necessary and
time consuming.
In my opinion, the role of QGIS organization, hence the QGIS Grant
program, is to compensate for this disequilibrium.

> Documentation and PyQT documentation work is already budgeted in our 
> annual budget. The money for 2016 hasn't even been spent for both
> items. So I think we should first use the budgeted money for such
> work. I think that user and developer documentation should be an
> ongoing effort and should be supported every year, und budgeted every
> year as such. We can increase the documentation budget positions next
> year, should it be necessary. In reality, it was more a lack of
> people willing to do the work, rather than a lack of funding. So, I
> am happy to see some proposals around documentation and developer
> documentation - so it seems that we have some volunteers. I just
> suggest that we consider documentation work separately and do it
> anyway - regardless of the outcome of the voting on these items.

Documentation is crucial, and I am also fully in favor of having a
dedicated yearly budget to improve it. It should be stated in the QGIS
grant application call too.

> Several proposals have a very limited local focus, only useful to
> one single country, or a very limited subset of our users. I suggest
> that such proposals could best be financed by local user groups or
> interest groups. It can't be the purpose of the QGIS grants program
> to finance such projects.

+1 also

Since I have more or less the same priority list as Andreas, I will also
add a few comments below.

> -----------------------------------------------------------
> 
> Here is my own personal list of priorities:

In my own priority order :

> 11) Introduce everything necessary for QGIS3 to OSGeo4W
> 
> The majority of our users are on Windows (like it or not). This is
> the platform that matters most in our user base. The introduction of
> QGIS 3.0 means porting everything to newer libraries and means a lot
> of work. This should be one of our main priorities. Jürgen does it
> works silently in the background many days of work each year that go
> unnoticed. Jürgen usually only hears complaints if something fails -
> maybe not so much praise. Having Windows nightly builds and releases
> early on in the life cycle of QGIS 3.x means that it can be well
> tested. So - also really important to our project.

This is to me the most important item for QGIS3. Jef does a huge work,
something difficult and not the most passionating thing to work on. We
do need to have the platform stable and ready as soon as possible to
have feedback on QGIS 3 very early in the release process.

> 18) QGIS 3 ticket handling and API refactoring
> 
> This is really time critical, and past discussions around QGIS 3.0
> has shown that there is a lack of project management work and
> coordination. I regard this proposal as very useful for the QGIS 3.0
> release.

Disclaimer : This proposal is by Oslandia
We proposed this item exactly because we observed that we were lacking
project management efforts, and especially regarding the QGIS3 release.
Having time allocated for project management would improve developer's
coordination, and help better define the release roadmap, by having a
clearer view of required efforts, and risk analysis.

> 14) Project / Map layer registry refactoring
> 
> Similar reasoning like item 2) above. Under the hood, necessary API 
> improvements. Also time critical, to be done as soon as possible.
> Early in the 3.x life cycle when API changes are still possible.

This is a long needed change, for which we have a good timeframe with
QGIS3. It opens to new features later on. I trust Martin to do a very
good work on this one.

> 2) Implement a flexible properties framework in QGIS
> 
> This is the kind of under-the-hood API changes and improvements I 
> mentioned above. Stuff that brings our project forward, but under
> the hood - not visible for the user. This is the basis that later
> follow-up work can than build upon and benefit from. Stuff that later
> can also be funded by organizations/companies. Also time critical, to
> be done as soon as possible. Early in the 3.x life cycle when API
> changes are still possible.

I also consider this one important, but it may be introduced later on.

> --------------------------------
> 
> Now, the documentation items:
> 
> 1) 2.16 Documentation
> 
> 16) PyQGIS Developer Cookbook update and maintenance
> 
> 15) PyQGIS Cookbook Review
> 
> They add up in total to € 14k. I believe that all of the three
> deserve to be supported financially. We have budgeted 10k € in 2016
> for documentation and PyQT documentation. 1.5k € have been spent so
> far. So still 8.5k remaining. Together with the new 2017 budget I
> believe that all of the three above items can be easily handled
> outside of the QGIS grants program. Documentation should be an
> ongoing, continuous and budgeted accordingly, outside of the grants
> program.
> 
> -------------------------------

+1

> What are your opinions?

Again, I am really in favor of having a strong rule for QGIS.ORG where
we state that the main priorities for the budget should be all work
related to lowering the (now high) technical debt of the project, and
improving the technical quality of the project ( code & infrastructure),
as well as documentation.

I remember that the poll showed that users wanted new features, but I
really think that the poll was biased :
- to a question "what do you want to get funded in next QGIS versions",
users will always prefer new features, it is shinier and easier to
comprehend since it is also easier to understand and actually see the
results
- generally, users have very little understanding of what technical debt
represent, and its impact on the long run for a software project
- they are usually not directly concerned by everything related to
software deployment & infrastructure, etc

There is still work to do to inform our users and funders on these
topics, and push forward all initiatives going in this direction.

Regards,
Vincent

> 
> Greetings,
> 
> Andreas
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________ Qgis-user mailing
> list Qgis-user at lists.osgeo.org List info:
> http://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe:
> http://lists.osgeo.org/mailman/listinfo/qgis-user
> 