[Qgis-psc] Toughts after November PSC

[Paolo Cavallini]

Hi Andreas,

Il 21/11/19 09:12, Andreas Neumann ha scritto:
> Hi Paolo,
> 
> Thanks for sharing your thoughts. I have some comments inline.
> 
> On Wed, 20 Nov 2019 at 13:34, Paolo Cavallini <cavallini at faunalia.it
> <mailto:cavallini at faunalia.it>> wrote:
> 
>     Hi all,
>     I think it is useful to point out some thoughts about QGIS.ORG
>     <http://QGIS.ORG>, stemming
>     from yesterday PSC meeting, out for general discussion.
>     My considerations:
>     * we should always prefer for our infrastructure simple and libre
>     solutions over complicated and proprietary ones, to promote openness and
>     cooperation within the community and keep the entry barrier low
> 
> 
> Right. If possible and doesn't trigger a lot of followup costs.
> Sometimes it is better to outsource to a proprietary solution, if it
> saves us a lot of time and efforts (think about our usage of Google
> docs, as an example).

of course cost is an issue. using and designing infrastructures that are
complex, essentially in the hand of a single person, difficult or
impossible to handle for others, is a major concern to me.
the key point here is openness: I think we should avoid making the
project less open than it could be.

>     * we should prefer to finance projects useful for the advancement of the
>     project through our very successful Grant programme, leaving direct
>     financing of special projects by PSC to really special cases; on the
>     other hand, I propose the PSC can give its recommendations as to which
>     grant proposals are most useful for the project, leaving the discussion
>     and the final decision to the community
> 
> 
> Here I clearly disagree with you. I think the grant program is wonderful
> for how we use it now. But not all of our projects need or should go
> through this grant program. The grant program is a way for our community
> members and contributors to suggest a project from their own ideas.
> Typically these ideas come from outside of the PSC.
> 
> I think it is very useful to set aside a significant amount of our
> income to these grant projects. It helps our community and allows for
> contributors outside the PSC to be better involved and often enables
> projects that otherwise would be hard to get funding for. The whole
> grant process takes at the very least 2-3 months to process. So it isn't
> well suited for stuff that needs to be decided quickly.
> 
> On the other hand we have infrastructure projects that, if implemented,
> make our life as PSC or certain core contributors easier. Such projects
> would not trigger a lot of popularity or excitement among our community
> or wider user base. Yet - they are really useful
> 
> If you run a government or small municipality (more comparable to our
> QGIS community), you typically have several budgets: one for recurrent
> expenses that you know or can estimate upfront, one kind of a "buffer"
> budget for expenses around PSC and our QGIS IT infrastructure that you
> kind of know and expect but don't know much upfront when these expenses
> have to be made and how much they will cost upfront, and a third part
> for long-term strategic investments and extra projects (like a new
> school in a municipality or a new sports infrastructure, new waste-water
> treatment plant, etc.).
> 
> My idea of these different types of budgets is:
> 
> - First budget of recurring expenses: proposed by PSC based on
> experience from past years and suggestions from the community. QGIS
> voting member approve budget and final accounting with the help of our
> two auditors.
> - Second one "the buffer budgets for unexpected expenses around PSC and
> our QGIS IT infrastructure" that arise and often need to be spent rather
> quickly: should be at the discretion of the PSC. I don't see a need to
> run these projects through QGIS grants. If the PSC decides that these
> are useful and necessary, there is no big value to first run them
> through our voting members. Of course there need to be limits on such
> expenses.
> - Third one: extra projects and long-term strategic investments. For
> these expenses it clearly is the right thing to run those through our
> grants program and let voting members decide on them, ideally with some
> discussion upfront.
> 
> What do you think about this proposal. Do you still think there is a
> need to run all of our expenses around our IT infrastructure through the
> voting members?

Of course, running costs, once approved, should not be discussed every
time. I see a number of projects, however, that have been financed as
special projects, and could be very well have been run through a public
assessment.
again, I'm talking about openness: directing things top down may seem
more efficient at first, but I believe in the long run it is not.

>     * all payments (grants, projects, travel reimbursements, documentation
>     work, etc.) should be done only after a report has been published in a
>     central stable place (a single web page, a collection of it): it should
>     be easy for anybody to check what has been done, how much it costed,
>     etc.
> 
> 
> That is partially already the case, but maybe not at a central case.
> 
> - For bug fixing we publish all of our paid fixes in our visual changelog.
> - Outcome of grants is often documented somewhere, but often at a
> company's webpage or blog. I agree that it would be more useful to
> publish those results e.g. in our official QGIS blog.
> - Travel reimbursements: Ideally there could be a curated blog post
> after each contributor meeting. The difficult thing is to find a
> volunteer to coordinate this. But I see the value more to have it
> documented what happened at the meeting rather than knowing how these
> were been financed exactly and who got reimbursements and who not. Most
> of our expenses for contributor meetings go into the dinners, venue and
> catering anyway, parts of the funds go to individual people for travel
> expenses.
> - Projects: like grant projects they can be published in our blog post.

the point to me is to have everything in a single location; in the
current situation the information may be there, but it is difficult to
have a general picture, and to find what one is looking for. so I'm
suggesting at the completion of each work, before paying for it, a
report should be put in a predictable place, easy to find. then this can
be echoed in blog posts, over social networks, more details can be
added, including nice screenshots atc, but the essentials should be there

>     * due to connection issues, I've not clear what the outcome of the
>     Documentation discussion was; I made my proposal [0], I would appreciate
>     further comments on it so we can start working on a clear solution
> 
> 
> Tim presented his platform for training lessons. That's was mainly
> discussed. Sorry, we haven't discussed or came up with a solution for
> the documentation problem yet.

I see this issue keep on attracting little interest. I suggest keeping
on discussing about this on the mailing list

>     * we need simple rules for adding news, even though a degree of
>     flexibility is useful; cen we agree on [1]?
> 
> 
> That wasn't discussed. What I suggest: please put it into the PSC
> meeting document for next meeting. These meeting documents are our
> central log for our discussions and decisions. Everything else is lost
> quite easily. So if you want a decision on that, please suggest a text
> in our next meeting document and formulate it there.

IMHO we should decide whatever is possible here in the mailing list,
leaving PSC meeting for the most complex issues, that require a proper
discussion in voice. I think most issues can be solved in writing.
I remember the good old IRC meetings, very good for many decisions, less
so for general discussion.
IMHO PSC meetings are lasting too long, and are not a very efficient way
of making decisions. Having just one meeting once a month does not help
taking timely and efficient decisions.

> It would be valuable and more efficient if all of our discussions and
> decisions really end up in these meeting documents. Everything else is
> just discussion to me, and not a formal decision.

I think we can vote here for most issues.
In short, I propose to put forward all the issues here on the ML, and
leave to the voice meetings what we were unable to solve during the month.

Cheers.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/