Re: [Qgis-developer] Discussion on the QGIS grant proposals
On 22/09/2016 12:15, Paolo Cavallini wrote: [..] > > One other important point: the reason I originally proposed the grant > programme was to recognize the huge volunteer work several people are > donating to the project, and to help keeping their motivation high. > > My suggestion is therefore to prioritize the projects by the people you > feel/know have contributed most to the project until now. I disagree with this. A grant application is meant to give money for a certain work. The background of the person applying for a grant has to be taken into account for selection, for sure. But the grant itself should be related to a work, and not to previous contributions. If we want to recognize volunteer work and previous donations to the project, then let's create a "QGIS contributor of the year prize" with a dedicated amount of money offered, and vote for one every year. This would be a nice way to keep people motivated. But misusing a grant for work in this sense seems unfair to me. Vincent ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Discussion on the QGIS grant proposals
Hi Andreas, thanks again for raising these important points. My notes (also personal opinion, not to be intended as a PSC position) below: Il 22/09/2016 08:14, Neumann, Andreas ha scritto: > -- > > Now comes my personal position/opinion - note that this is not the > official opinion of the QGIS.ORG board. > > I would personally welcome, if this round of the QGIS grants program > could focus on the QGIS 3.0 release. Agreed, a critical point for QGIS future. > 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. Agreed, that's one of the reasons we started this program. > 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. It makes sense to me. > 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. Fully agreed. One other important point: the reason I originally proposed the grant programme was to recognize the huge volunteer work several people are donating to the project, and to help keeping their motivation high. My suggestion is therefore to prioritize the projects by the people you feel/know have contributed most to the project until now. All the best. -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Discussion on the QGIS grant proposals
>> 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. Just to clarify (since I'm not sure if it was explicitly noted in the proposal) - this is more or less a happens-during-api-break or doesn't happen at all type change. To do it and maintain existing api would result in 1.5-2x the work required, and a horrible mixed api with many deprecated methods for the lifecycle of 3.x. Nyall ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [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 all
[Qgis-developer] Discussion on the QGIS grant proposals
Dear QGIS users, developers, voting members and user group representatives, As you may have noticed, there is a first round of a QGIS grant program, fueled by the donations and sponsorship money we received in the past months. Tim Sutton, chair of the QGIS project, has publicized this program repeatedly on several channels. The good thing is that we got some very good proposals. In total 18 proposals, adding up to a total grant sum of 101 k EUR. You can see all proposals at https://drive.google.com/file/d/0B__vDnQXCKiwYTIyWmRSbi1hMWM/view?usp%3Dsharing&sa=D&ust=1474526025402000&usg=AFQjCNFhp43Lkxw3aBCed9-9luJpnR0oWg Please note that we can only spend 20k EUR in this first round. So there are tough decisions to make. Note that proposals that can't make it in the first round, can be kept in a waiting list and may apply again in the next round of a grants program. If a proposal can't be accepted in the first round, this doesn't mean it isn't valuable and useful to the QGIS.ORG project. The QGIS PSC will honor the opinion of the voting members, the OSGEO representative and the user group representatives on how to spend this limited money wisely. Alltogether a group of currently 27 people (13 qgis user group represenatives, 13 community voting members, 1 OSGEO representative). This is kind of the "parliament" of the QGIS project when it comes to such decisions. -- Now comes my personal position/opinion - note that this is not the official opinion of the QGIS.ORG board. I would personally welcome, if this round of the QGIS grants program could focus on the QGIS 3.0 release. 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. 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. 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. --- Here is my own personal list of priorities: 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. 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. 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. 14) Project / Map layer registry refactoring Similar reasoning like item 2) above. Under the hood, necessary API improvements. Also time critical,
