Hi, As a user and not (yet) a voting member or developer I can just agree with Andreas and Vincent. The QGIS grant program, at least now, should focus on QGIS 3 release, broad under the hood structural changes that moves QGIS into a better and more stable platform and not narrow or local features more easily funded in other ways.
Regards Karl-Magnus Jönsson Kristianstads kommun -----Ursprungligt meddelande----- Från: Qgis-user [mailto:qgis-user-boun...@lists.osgeo.org] För Vincent Picavet (ml) Skickat: den 22 september 2016 10:10 Till: Neumann, Andreas; QGIS Developers List; QGIS User List Ämne: Re: [Qgis-user] [Qgis-developer] Discussion on the QGIS grant proposals 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@lists.osgeo.org List info: > http://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: > http://lists.osgeo.org/mailman/listinfo/qgis-user > _______________________________________________ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user _______________________________________________ Qgis-user mailing list Qgis-user@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-user
