<div dir="ltr"><div dir="ltr">Hi Anita, PSC,<div><br></div><div>That sounds a very good way forward.</div><div><br></div><div>Thanks for considering my suggestion and came up with a more balanced approach.</div><div><br></div><div>Kind regards</div><div>Saber</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 4 Jun 2020 at 13:13, Anita Graser <<a href="mailto:anitagraser@gmx.at">anitagraser@gmx.at</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
We discussed this issue in this week's PSC meeting and have come to the<br>
following decision:<br>
<br>
Instead of using the old system of ranked voting for top 6 proposals (6<br>
points to the highest ranked to 1 point to the lowest ranked), this year<br>
each voting member will be asked to select his/her favorite 6 proposals<br>
and each of these proposals gets 1 point.<br>
<br>
Concerning ideas to limit who can vote on which proposal (e.g. no voting<br>
on proposals by "own company"), we have decided against implementing any<br>
such rules. The reasoning follows many of the concerns raised in this<br>
tread: it is highly complicated to define who gets to vote on what and<br>
this could be a potentially big source of conflict every year.<br>
Furthermore, the PSC thinks that what we have seen so far shows that<br>
voting members can be trusted to vote in the best interests of the QGIS<br>
project.<br>
<br>
We already shared the results of the PSC's review of formal proposal<br>
requirements, as well as the decision to fund two documentation<br>
proposals directly from the documentation budget in an earlier email.<br>
The remaining eligible proposals result in a total requested budget of<br>
EUR 45,400 while the grant programme budget has EUR 40,000 available.<br>
Therefore, we can expect a high accept rate.<br>
<br>
Regards,<br>
<br>
Anita<br>
<br>
<br>
On 02.06.2020 12:46, Andreas Neumann wrote:<br>
> Hi all,<br>
><br>
> Interesting discussion - and difficult to find a good solution.<br>
><br>
> I agree with Martin that the voting process where the first selected<br>
> entry gets 6 points, the next 5, etc. is broken. Just like the PSC<br>
> voting (I mean the mechanism to decide who will be on the PSC) is<br>
> broken (which has a very similar setup). A person, or a proposal isn't<br>
> (at least normally) not 6 times as useful to the project than others.<br>
><br>
> Both need to be overhauled and made more transparent. I like the idea<br>
> where all proposals could be scored and then we will accept the ones<br>
> with the highest scores as long until the grant proposal budget is<br>
> allowing acceptance.<br>
><br>
> I would also favor the idea that the PSC could select out some of the<br>
> proposals and finance them through the regular budget - e.g. we have a<br>
> documentation budget that is never fully used. If we get entries in<br>
> the QGIS grant proposal around documentation, PSC should be able to<br>
> accept these right away through the documentation budget, thus leaving<br>
> more room toward other grant proposals. Infrastructure is another<br>
> category where we already have a budget for.<br>
><br>
> We have a PSC meeting tonight at 8pm (middle European Summer time).<br>
> This topic is certainly on the agenda, if someone would like to join<br>
> the discussion you are welcome to join the PSC meeting.<br>
><br>
> Greetings,<br>
><br>
> Andreas<br>
><br>
> Am 02.06.20 um 11:35 schrieb Martin Dobias:<br>
>> Hi all<br>
>><br>
>> Very good discussion and good points are being made.<br>
>><br>
>> Like Denis, I also have various concerns about grants this year:<br>
>> - which grants are actually features (which we wanted to exclude)<br>
>> - what is the overall value that<br>
>> - how good is the plan<br>
>> - whether the budget looks appropriate<br>
>> - how much trust we have in the developer<br>
>><br>
>> Voting members need to somehow consider all of the above (and more!)<br>
>> for all proposals and then create a list of 6(?) which seem to be the<br>
>> best. Which is incredibly hard, especially with so many projects we<br>
>> have this year. I feel uneasy that as a voting member can only assign<br>
>> some rating to 6(?) proposals, and with very limited options - the<br>
>> proposal I choose as the first will get 6 points, the last one gets<br>
>> just one point - it feels like as if the first proposal was six times<br>
>> better...<br>
>><br>
>> What I would like to suggest is whether we could move towards a<br>
>> scoring process that is common in public bids... QGIS.org would define<br>
>> criteria that would be scored 0 to 10 and voting members would score<br>
>> those criteria separately, for example:<br>
>> 1. fit to the grant call - something that looks like a feature if we<br>
>> don't want features could be scored low<br>
>> 2. value to the project - is this something really important that will<br>
>> help lots of users / developers? Or something more obscure that few<br>
>> users would benefit from?<br>
>> 3. proposal quality - is it clear what would be done and how it would<br>
>> be done? Or is the proposal brief and missing important details?<br>
>> 4. price - is the expected budget reasonable?<br>
>> 5. author's track of record - this could be scored low if the author<br>
>> is unknown to the project or it is unclear if they have the right<br>
>> skills<br>
>><br>
>> The criteria could have either equal weights or adjusted according to<br>
>> what we think is the right balance.<br>
>><br>
>> This system would place a greater burden on voting members to analyze<br>
>> the proposals and score them, but it may help fairness of the whole<br>
>> process and various of the biases voting members have would dissolve<br>
>> as there would be more data coming from each voting member.<br>
>><br>
>> Or if we skip the criteria, but at least allow voting members to score<br>
>> _all_ proposals, each with a single number 0-10 ?<br>
>><br>
>> Regards<br>
>> Martin<br>
>><br>
>> On Tue, Jun 2, 2020 at 10:06 AM Denis Rouzaud<br>
>> <<a href="mailto:denis.rouzaud@gmail.com" target="_blank">denis.rouzaud@gmail.com</a>> wrote:<br>
>>> Hi all,<br>
>>><br>
>>> It's indeed an interesting discussion and I feel very well concerned…<br>
>>> I have been personally influenced by the corporate voting during<br>
>>> last session.<br>
>>><br>
>>> While I understand this concerns, I would remind that the voting<br>
>>> member is something personal and not tight to a company.<br>
>>> I have mixed feelings. As far as I can see, elected voting members<br>
>>> have proven real engagement towards QGIS project.<br>
>>><br>
>>> Again, voting rights are personal. But the money allowed money for<br>
>>> grants will generally go to the company rather than the individual.<br>
>>> Thereby, I would rather try to restrict the number of allowed grants<br>
>>> per entity rather than restricting the voting rights.<br>
>>><br>
>>> But we'll fall into the same point Matthias was mentionning earlier:<br>
>>> what's an entity. Some devs are more or less coupled, without being<br>
>>> hold literally in a company.<br>
>>><br>
>>> So, my order of preference of action would be<br>
>>> 1: try to make voting members aware of the conflict of interest and<br>
>>> trust them<br>
>>> 2: if needed, restrict per company<br>
>>><br>
>>> Now, looking at this year proposal, I am far more concerned about<br>
>>> what we propose to vote on rather than the voting process:<br>
>>><br>
>>> 1. Many of the grants are features, while we call for a refactoring<br>
>>> / infrastructure round<br>
>>> 2. Some are made by unknown people from the community, and I have<br>
>>> mixed feelings about this (openess vs rewarding of involvment)<br>
>>><br>
>>> I don't have a perfect solution to propose but I think we should<br>
>>> maybe re-think the process more globally. What is the goal of the<br>
>>> grants proposal?<br>
>>> * Is it to fund projects that are difficult to fund otherwise? But,<br>
>>> then shouldn't it be a kind of ongoing budget?<br>
>>> * Are we trying to attract devs?<br>
>>> * Are we trying to replace a crowd-funding operations for nice-to-have?<br>
>>><br>
>>> Best wishes,<br>
>>> Denis<br>
>>><br>
>>> Le mar. 2 juin 2020 à 09:16, Matthias Kuhn <<a href="mailto:matthias@opengis.ch" target="_blank">matthias@opengis.ch</a>> a<br>
>>> écrit :<br>
>>>> Hi all<br>
>>>><br>
>>>> On 5/30/20 1:21 AM, Nyall Dawson wrote:<br>
>>>>> In general, I'd propose that we consider introducing (in the official<br>
>>>>> statutes) a limit of one-voting-member-per-organisation. This would<br>
>>>>> bring the community voting membership into line with the user group<br>
>>>>> membership, where user groups have one single voting member who<br>
>>>>> represents the group's view as a single vote. This would also limit<br>
>>>>> the potential for (god forbid) a "hostile takeover" situation,<br>
>>>>> where a<br>
>>>>> coalition of organisations (commercial or user group) could dominate<br>
>>>>> voting. (I think it would be wise to apply the same<br>
>>>>> one-member-per-org<br>
>>>>> limit to PSC/board membership too!).<br>
>>>> A very good discussion.<br>
>>>><br>
>>>> How would a one-member-per organisation rule work in reality?<br>
>>>><br>
>>>> If someone is a very active and respected member of the community with<br>
>>>> all the skills required to judge and discuss a QEP (or other<br>
>>>> motion) and<br>
>>>> has voting rights. And then gets employed by a company which<br>
>>>> already has<br>
>>>> someone with voting rights, will his voting rights be withdrawn? I<br>
>>>> would<br>
>>>> expect that this will have an effect on his choice of employer and<br>
>>>> could<br>
>>>> impact his engagement within community processes.<br>
>>>><br>
>>>> Also, how would we deal with loosely coupled groups of developers<br>
>>>> which<br>
>>>> are legally not an organisation/company but still share business,<br>
>>>> communication and opinions?<br>
>>>><br>
>>>> Best regards<br>
>>>><br>
>>>> Matthias<br>
>>>><br>
>>>> _______________________________________________<br>
>>>> Qgis-psc mailing list<br>
>>>> <a href="mailto:Qgis-psc@lists.osgeo.org" target="_blank">Qgis-psc@lists.osgeo.org</a><br>
>>>> <a href="https://lists.osgeo.org/mailman/listinfo/qgis-psc" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-psc</a><br>
>>> _______________________________________________<br>
>>> Qgis-psc mailing list<br>
>>> <a href="mailto:Qgis-psc@lists.osgeo.org" target="_blank">Qgis-psc@lists.osgeo.org</a><br>
>>> <a href="https://lists.osgeo.org/mailman/listinfo/qgis-psc" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-psc</a><br>
>> _______________________________________________<br>
>> Qgis-psc mailing list<br>
>> <a href="mailto:Qgis-psc@lists.osgeo.org" target="_blank">Qgis-psc@lists.osgeo.org</a><br>
>> <a href="https://lists.osgeo.org/mailman/listinfo/qgis-psc" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-psc</a><br>
> _______________________________________________<br>
> Qgis-psc mailing list<br>
> <a href="mailto:Qgis-psc@lists.osgeo.org" target="_blank">Qgis-psc@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/qgis-psc" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-psc</a><br>
_______________________________________________<br>
Qgis-psc mailing list<br>
<a href="mailto:Qgis-psc@lists.osgeo.org" target="_blank">Qgis-psc@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/qgis-psc" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-psc</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Saber Razmjooei<br></div><div><a href="http://www.lutraconsulting.co.uk" target="_blank">www.lutraconsulting.co.uk</a><br><br></div></div></div></div></div></div></div></div></div></div></div>