Grant application suggestions for next time

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Grant application suggestions for next time

Nyall Dawson
Hi PSC,

Denis and I were discussing the current grant system and we came up
with a couple of suggestions which could be made for the next round of
applications. Given that the current round of grant voting is closing
today it's good timing to start these discussions early so that any
changes we want to make could be in place well before the next round.

Our suggestions are:

1. Create a new github repo for submission of the grant proposals -
much like the current QGIS Enhancement Proposal (QEP) repo (
https://github.com/qgis/QGIS-Enhancement-Proposals/issues ). If we
structured the applications this way then it allows people to ask
questions and provide public feedback on individual proposals --
something we currently lack the ability to do. It would also make it
quite easy for a proposal to be "reopened" for a future round of
grants (if it was not successful in a prior round), and all these
comments and discussion would be retained.

2. Require that code-related proposals be accompanied by a QEP filed
at least xx days in advance of the grant application. The current
setup could potentially result in a very awkward situation if a grant
application is voted in by the members and paid for by PSC, yet when
the feature/enhancement is submitted as a pull request for inclusion
in QGIS and the technical/UX details of the proposal first made
available, it may THEN be deemed an unsatisfactory approach/unwanted
change and prevented from being merged. Then we'd have a conflict
between the project paying for changes vs maintainers deeming these
changes unfit for merging. This situation would reflect very badly on
the project's organisation and communication, so I think we need some
safeguard in place to minimise the chance that it could happen.
Opening a QEP prior to a grant request would mean that interested
maintainers will already have had an opportunity to discuss and assess
the changes, before they are introduced to the wider voting community
as an option.

Thanks again for all you hard work making these grants possible...
it's exciting to see what will be funded as a result once again!

Nyall
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Grant application suggestions for next time

ginetto
This can be also useful to "filter" proposal... IMHO GEarth Plugin shouldn't have access to grant program for reasons that can be discussed previously.

Luigi Pirelli

**************************************************************************************************
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS 2nd Edition:
* https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
* Hire me: http://goo.gl/BYRQKg
**************************************************************************************************


On Sun, 17 Jun 2018 at 03:38, Nyall Dawson <[hidden email]> wrote:
Hi PSC,

Denis and I were discussing the current grant system and we came up
with a couple of suggestions which could be made for the next round of
applications. Given that the current round of grant voting is closing
today it's good timing to start these discussions early so that any
changes we want to make could be in place well before the next round.

Our suggestions are:

1. Create a new github repo for submission of the grant proposals -
much like the current QGIS Enhancement Proposal (QEP) repo (
https://github.com/qgis/QGIS-Enhancement-Proposals/issues ). If we
structured the applications this way then it allows people to ask
questions and provide public feedback on individual proposals --
something we currently lack the ability to do. It would also make it
quite easy for a proposal to be "reopened" for a future round of
grants (if it was not successful in a prior round), and all these
comments and discussion would be retained.

2. Require that code-related proposals be accompanied by a QEP filed
at least xx days in advance of the grant application. The current
setup could potentially result in a very awkward situation if a grant
application is voted in by the members and paid for by PSC, yet when
the feature/enhancement is submitted as a pull request for inclusion
in QGIS and the technical/UX details of the proposal first made
available, it may THEN be deemed an unsatisfactory approach/unwanted
change and prevented from being merged. Then we'd have a conflict
between the project paying for changes vs maintainers deeming these
changes unfit for merging. This situation would reflect very badly on
the project's organisation and communication, so I think we need some
safeguard in place to minimise the chance that it could happen.
Opening a QEP prior to a grant request would mean that interested
maintainers will already have had an opportunity to discuss and assess
the changes, before they are introduced to the wider voting community
as an option.

Thanks again for all you hard work making these grants possible...
it's exciting to see what will be funded as a result once again!

Nyall
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc

_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Grant application suggestions for next time

Anita Graser
​Hi Nyall​,

Thank you for your feedback on the grant proposal process!
 
On Sun, 17 Jun 2018 at 03:38, Nyall Dawson <[hidden email]> wrote:
1. Create a new github repo for submission of the grant proposals -

​​The main difference to the current approach would be that submissions are immediately visible instead of them being secret until after the submission period has ended. 
While I don't think that people would be stealing other's ideas, that might cause some issues. ​
On the other hand, a general feedback round after the submissions and before the voting could be useful. 
 
2. Require that code-related proposals be accompanied by a QEP filed
at least xx days in advance of the grant application.

​Yes, it's a good sign that many proposals this year already included a QEP and I think that voting members also considered the existence of a QEP when ranking the submissions. 
What amount of days would you consider sufficient for discussing the QEP? If we introduce a general feedback period for all submissions, could we relax the requirement and just use that time window instead of having another deadline for QEPs to manage? 

Regards,
Anita







_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Grant application suggestions for next time

pcav
Hi all,

Il 18/06/2018 11:56, Anita Graser ha scritto:

> Thank you for your feedback on the grant proposal process!
>  
>
>     On Sun, 17 Jun 2018 at 03:38, Nyall Dawson <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>         1. Create a new github repo for submission of the grant proposals -
>
>
> ​​The main difference to the current approach would be that submissions
> are immediately visible instead of them being secret until after the
> submission period has ended. 
> While I don't think that people would be stealing other's ideas, that
> might cause some issues. ​

what kind of issues you expect?

> On the other hand, a general feedback round after the submissions and
> before the voting could be useful. 

agreed fully - we always promoted openness, so this looks appropriate.

>         2. Require that code-related proposals be accompanied by a QEP filed
>         at least xx days in advance of the grant application.
>
>
> ​Yes, it's a good sign that many proposals this year already included a
> QEP and I think that voting members also considered the existence of a
> QEP when ranking the submissions. 
> What amount of days would you consider sufficient for discussing the
> QEP? If we introduce a general feedback period for all submissions,
> could we relax the requirement and just use that time window instead of
> having another deadline for QEPs to manage? 

agreed, we should balance between tighter rules and the need to keep
admin work as light as possible.

All the best.

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Grant application suggestions for next time

Martin Dobias
In reply to this post by Nyall Dawson
Hi all

On Sun, Jun 17, 2018 at 3:38 AM, Nyall Dawson <[hidden email]> wrote:
>
> Our suggestions are:
>
> 1. Create a new github repo for submission of the grant proposals -
> much like the current QGIS Enhancement Proposal (QEP) repo [...]
>
> 2. Require that code-related proposals be accompanied by a QEP filed
> at least xx days in advance of the grant application. The current [...]

I very much support these suggestions! Having a discussion in public
about grant proposals prior to voting would be definitely useful and
it would help voting members make their decisions how to best spend
the money.

Cheers
Martin
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Grant application suggestions for next time

Richard Duivenvoorde
On 19-06-18 11:34, Martin Dobias wrote:

> Hi all
>
> On Sun, Jun 17, 2018 at 3:38 AM, Nyall Dawson <[hidden email]> wrote:
>>
>> Our suggestions are:
>>
>> 1. Create a new github repo for submission of the grant proposals -
>> much like the current QGIS Enhancement Proposal (QEP) repo [...]
>>
>> 2. Require that code-related proposals be accompanied by a QEP filed
>> at least xx days in advance of the grant application. The current [...]
>
> I very much support these suggestions! Having a discussion in public
> about grant proposals prior to voting would be definitely useful and
> it would help voting members make their decisions how to best spend
> the money.

A little late on the table, but +1 for this idea's too. I think this
make QGIS stronger, when we discuss ideas more broadly.

One think I would like to add in a proposal, is a definition on what is
to be the 'end product'. That is something written what can be used to
'check' if the proposal is finished or not.

Maybe some 'check mark questions' like (all fake, but getting more
difficult to accomplish):

- the Foo provider will provide a base for running Foo scripts in future
- the Foo provider can run the following basis Foo scripts (or tests)
- the Foo provider is able to run all scripts the old provider did
- ...

Based on that it is easier to decide to pay out or partially or not.

At this moment some proposals contain rather broad end products like:
"this will be implemented for QGIS 3.4"

OR am I talking to too many managers recently :-)

Regards,

Richard
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Grant application suggestions for next time

Andreas Neumann-4

good ideas. I am also in favour of discussing proposals upfront and openly (on Github). Also, I am in favour of more specific results (some proposals do that, some don't).

At the same time, voting members, are probably smart enough to not favour a proposal that is very vague about the results.

Andreas

On 2018-06-20 11:59, Richard Duivenvoorde wrote:

On 19-06-18 11:34, Martin Dobias wrote:
Hi all

On Sun, Jun 17, 2018 at 3:38 AM, Nyall Dawson <[hidden email]> wrote:

Our suggestions are:

1. Create a new github repo for submission of the grant proposals -
much like the current QGIS Enhancement Proposal (QEP) repo [...]

2. Require that code-related proposals be accompanied by a QEP filed
at least xx days in advance of the grant application. The current [...]

I very much support these suggestions! Having a discussion in public
about grant proposals prior to voting would be definitely useful and
it would help voting members make their decisions how to best spend
the money.

A little late on the table, but +1 for this idea's too. I think this
make QGIS stronger, when we discuss ideas more broadly.

One think I would like to add in a proposal, is a definition on what is
to be the 'end product'. That is something written what can be used to
'check' if the proposal is finished or not.

Maybe some 'check mark questions' like (all fake, but getting more
difficult to accomplish):

- the Foo provider will provide a base for running Foo scripts in future
- the Foo provider can run the following basis Foo scripts (or tests)
- the Foo provider is able to run all scripts the old provider did
- ...

Based on that it is easier to decide to pay out or partially or not.

At this moment some proposals contain rather broad end products like:
"this will be implemented for QGIS 3.4"

OR am I talking to too many managers recently :-)

Regards,

Richard
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc



_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Grant application suggestions for next time

pcav
In reply to this post by Richard Duivenvoorde
Il 20/06/2018 11:59, Richard Duivenvoorde ha scritto:

> A little late on the table, but +1 for this idea's too. I think this
> make QGIS stronger, when we discuss ideas more broadly.
>
> One think I would like to add in a proposal, is a definition on what is
> to be the 'end product'. That is something written what can be used to
> 'check' if the proposal is finished or not.
>
> Maybe some 'check mark questions' like (all fake, but getting more
> difficult to accomplish):
>
> - the Foo provider will provide a base for running Foo scripts in future
> - the Foo provider can run the following basis Foo scripts (or tests)
> - the Foo provider is able to run all scripts the old provider did
> - ...
>
> Based on that it is easier to decide to pay out or partially or not.
>
> At this moment some proposals contain rather broad end products like:
> "this will be implemented for QGIS 3.4"
>
> OR am I talking to too many managers recently :-)

+1

BTW, now that we are ready to announce the outcome of the grant
programme, we should prepare an announcement saying something like "a
number of interesting and useful proposal didn't make it because of our
limited budget; we encourage organizations to pick up one of their
choice and sponsor it"
Maybe it wold be useful to add this to the announcement.
All the best.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Grant application suggestions for next time

Anita Graser
In reply to this post by Andreas Neumann-4
Hi,

On Wed, Jun 20, 2018 at 12:03 PM Andreas Neumann <[hidden email]> wrote:

good ideas. I am also in favour of discussing proposals upfront and openly (on Github). Also, I am in favour of more specific results (some proposals do that, some don't).

At the same time, voting members, are probably smart enough to not favour a proposal that is very vague about the results.


​I've started documenting the grant process and added notes about your recommendation:​

​The document should be open for comments. So please feel free to add your thoughts here or in the doc.

Regards,
Anita​

 


 

_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc