<div dir="ltr"><div dir="ltr"><div>Hi Paolo,</div><div><br></div><div>Thanks for sharing your thoughts. I have some comments inline.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 20 Nov 2019 at 13:34, Paolo Cavallini <<a href="mailto:cavallini@faunalia.it">cavallini@faunalia.it</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>
I think it is useful to point out some thoughts about <a href="http://QGIS.ORG" rel="noreferrer" target="_blank">QGIS.ORG</a>, stemming<br>
from yesterday PSC meeting, out for general discussion.<br>
My considerations:<br>
* we should always prefer for our infrastructure simple and libre<br>
solutions over complicated and proprietary ones, to promote openness and<br>
cooperation within the community and keep the entry barrier low<br></blockquote><div><br></div><div>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).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* we should prefer to finance projects useful for the advancement of the<br>
project through our very successful Grant programme, leaving direct<br>
financing of special projects by PSC to really special cases; on the<br>
other hand, I propose the PSC can give its recommendations as to which<br>
grant proposals are most useful for the project, leaving the discussion<br>
and the final decision to the community<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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</div><div><br></div><div>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.).<br></div><div><br></div><div>My idea of these different types of budgets is:</div><div><br></div><div>- 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.</div><div>- 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.<br></div><div>- 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.<br></div><div><br></div><div>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?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* all payments (grants, projects, travel reimbursements, documentation<br>
work, etc.) should be done only after a report has been published in a<br>
central stable place (a single web page, a collection of it): it should<br>
be easy for anybody to check what has been done, how much it costed, etc.<br></blockquote><div><br></div><div>That is partially already the case, but maybe not at a central case.</div><div><br></div><div>- For bug fixing we publish all of our paid fixes in our visual changelog.</div><div>- 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.</div><div>- 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.<br></div><div>- Projects: like grant projects they can be published in our blog post.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* due to connection issues, I've not clear what the outcome of the<br>
Documentation discussion was; I made my proposal [0], I would appreciate<br>
further comments on it so we can start working on a clear solution<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* we need simple rules for adding news, even though a degree of<br>
flexibility is useful; cen we agree on [1]?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>Thanks,</div><div>Andreas<br></div></div><div class="gmail_quote"><br></div></div>