[Qgis-psc] Toughts after November PSC

[Andreas Neumann]

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> wrote:

> Hi all,
> I think it is useful to point out some thoughts about 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).


> * 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?


> * 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.


> * 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.


> * 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.

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.

Thanks,
Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20191121/d11ab081/attachment.html>