[Qgis-psc] Voting for grants

Thu Jun 4 06:56:39 PDT 2020

Hi Anita, PSC,

That sounds a very good way forward.

Thanks for considering my suggestion and came up with a more balanced
approach.

Kind regards
Saber

On Thu, 4 Jun 2020 at 13:13, Anita Graser <anitagraser at gmx.at> wrote:

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

-- 
Saber Razmjooei
www.lutraconsulting.co.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20200604/5a0b5ffa/attachment-0001.html>