<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi<div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 21 Nov 2019, at 16:36, Paolo Cavallini <<a href="mailto:cavallini@faunalia.it" class="">cavallini@faunalia.it</a>> wrote:</div><div class=""><div class=""><blockquote type="cite" class=""><br class="">Right. If possible and doesn't trigger a lot of followup costs.<br class="">Sometimes it is better to outsource to a proprietary solution, if it<br class="">saves us a lot of time and efforts (think about our usage of Google<br class="">docs, as an example).<br class=""></blockquote><br class="">of course cost is an issue. using and designing infrastructures that are<br class="">complex, essentially in the hand of a single person, difficult or<br class="">impossible to handle for others, is a major concern to me.<br class="">the key point here is openness: I think we should avoid making the<br class="">project less open than it could be.<br class=""></div></div></blockquote><div><br class=""></div><div><br class=""></div><div><br class=""></div><div>8< ———— snip</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><br class="">What do you think about this proposal. Do you still think there is a<br class="">need to run all of our expenses around our IT infrastructure through the<br class="">voting members?<br class=""></blockquote><br class="">Of course, running costs, once approved, should not be discussed every<br class="">time. I see a number of projects, however, that have been financed as<br class="">special projects, and could be very well have been run through a public<br class="">assessment.<br class="">again, I'm talking about openness: directing things top down may seem<br class="">more efficient at first, but I believe in the long run it is not.<br class=""></div></div></blockquote><div><br class=""></div><div><br class=""></div><div>Right but I think you are mischaracterising Andreas’ approach as ’not open’. The budget and cost renters would be clear, open and agreed with the community, as would the post spending reporting. It just means that for certain cases there is not a 3 month lead up needed before money could be spent. Denis’ recent request for addition support with the python API docs was maybe a good example of this.</div><div><br class=""></div><div>8< —————snip —————— </div><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""> * due to connection issues, I've not clear what the outcome of the<br class=""> Documentation discussion was; I made my proposal [0], I would appreciate<br class=""> further comments on it so we can start working on a clear solution<br class=""><br class=""><br class="">Tim presented his platform for training lessons. That's was mainly<br class="">discussed. Sorry, we haven't discussed or came up with a solution for<br class="">the documentation problem yet.<br class=""></blockquote><br class="">I see this issue keep on attracting little interest. I suggest keeping<br class="">on discussing about this on the mailing list<br class=""></div></div></blockquote><div><br class=""></div><div>I think the case is more that the issue is complex and perplexing as we are trying to serve many different needs. Discussing it on the mailing list is fine but honestly this (like many discussions on the mailing list) is just circular with many thread hijackings, cross issues etc. it becomes difficult to know where we even are in the discussions. For example your proposed approach to documentation, Harrisou already responded that he would be really upset to lose translations, asking for example of a platform where documentation can allow commenting and user augmentation etc. and his request went unanswered IIRC. This is an example where it would be better to go off in a huddle with Harrisou and other interested parties and come up with a proposal which they are invested in, then bring it back to the mailing list as a proposal that already has the buy-in from key role-players.</div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""> * we need simple rules for adding news, even though a degree of<br class=""> flexibility is useful; cen we agree on [1]?<br class=""></blockquote></div></div></blockquote><div><br class=""></div><div><br class=""></div><div>From your original list:</div><div><br class=""></div><div><pre style="white-space: pre-wrap; caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);" class="">1. global Contributors Meetings announcements (local ones only if geofenced)
2. global QGIS Days (local ones only if geofenced)
3. requests for sponsorship of specific projects
4. crowdfunding announcements
5. callouts for testing of upcoming qgis releases
6. new release announcements when changelog is published (after we get
rid of the small banner)
7. survey announcements.</pre><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I just wonder why we need all these rules? We could also just rely on common sense, ensuring that anything posted is of broad interest, and ask the authors to float anything up to the PSC if they are not sure. For me it is similar to the <a href="http://blog.qgis.org" class="">blog.qgis.org</a> which is the ‘voice of the project’ - we never really had any problem with what should and shouldn’t go on there…..</div></div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""><br class=""><br class="">That wasn't discussed. What I suggest: please put it into the PSC<br class="">meeting document for next meeting. These meeting documents are our<br class="">central log for our discussions and decisions. Everything else is lost<br class="">quite easily. So if you want a decision on that, please suggest a text<br class="">in our next meeting document and formulate it there.<br class=""></blockquote><br class="">IMHO we should decide whatever is possible here in the mailing list,<br class="">leaving PSC meeting for the most complex issues, that require a proper<br class="">discussion in voice. I think most issues can be solved in writing.<br class="">I remember the good old IRC meetings, very good for many decisions, less<br class="">so for general discussion.<br class=""></div></div></blockquote><div><br class=""></div><div><br class=""></div><div>I think your memory of IRC meetings is clouded by geek nostalgia :-) I have very clear memories of being in meetings and waiting for ages for each person to respond because they had basically wondered away from the computer / opened another app and were not focussed on the IRC channel. In a voice meeting you can clearly know if the participants are present and engaged. IRC was frankly awful and is no substitute for a well run voice meeting. Of course a badly run voice meeting is not much better than a badly run IRC meeting :-) But in general you can put a lot of nuanced information across much more quickly in voice than you can typing in an IRC channel. There is another thing that I find voice / video meetings really good for: Email / IRC discussions can often sound much more heated than they really are, voice calls carry a lot of extra context over in the conversation and we get to hear tone and sentiment portrayed much more accurately. Speaking in voice reminds us that we are humans, gives us a sense of shared endeavour and rapport that simply don’t manifest in the rather functional and faceless platform of email / irc. </div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">IMHO PSC meetings are lasting too long, and are not a very efficient way<br class="">of making decisions. Having just one meeting once a month does not help<br class="">taking timely and efficient decisions.<br class=""></div></div></blockquote><div><br class=""></div><div>I’m fine with discussing things on the mailing list, but they are really bad places for actual decisions. People call for votes too quickly, or vote on things when no call has been made, votes come through in bits in pieces, there is no clarity on who should actually be voting, it is difficult to know when votes are finished, new threads emerge soon after one finishes where new votes are made and it is basically impossible to track any decisions. Also in email, people are extremely selective about which parts of an email they respond to so many concerns often go unaddressed. In voice it is much easier to dig and get the specific information you need. An example of this is Anita’s recent comment in an off list chat about putting out one-liner emails with little context leaving the reader to puzzle out what is intended - in a conversation you can just ask the person ‘please clarify’.</div><div><br class=""></div><div>In terms of our meetings lasting long, yes we should try to time-cap meetings, but I also think (as I was alluding to above) that there is huge merit in us actually spending time together thrashing things out rather than rushing in, rushing out of meetings. Ideally our meetings should be run in a way that the document agenda contains a list of clear ‘yes/no’ proposals, with an opportunity for the proposer to give some background to the proposal in voice and the PSC to ask any questions to inform their vote, then the execution of a quick vote directly in the google doc. All of that can be time capped to e.g. 1 hour. Whatever doesn’t get covered gets carried over to the top of the next meetings agenda. </div><div><br class=""></div><div>I really like the chance to hang out before / after the meetings to dig into topics a little more. You also get a good sense of where people are in their private lives and can use that to understand tone in subtext in emails over the subsequent month. Frankly some of the exchanges we have on email these days worry me that people are getting unhappy and that we are losing cohesion. Spending time together and getting on the same page about things is a good fix for that…I think this is especially important for you Paolo - as project chair you should be working hard to have a deep sense of rapport with the team (first to arrive, last to leave) so that you can get the most possible enthusiasm and collaboration from everyone in the PSC and in the community, and set the general direction of how the project is going.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">It would be valuable and more efficient if all of our discussions and<br class="">decisions really end up in these meeting documents. Everything else is<br class="">just discussion to me, and not a formal decision.<br class=""></blockquote><br class="">I think we can vote here for most issues.<br class="">In short, I propose to put forward all the issues here on the ML, and<br class="">leave to the voice meetings what we were unable to solve during the month.<br class=""></div></div></blockquote><div><br class=""></div><div>Ok, again I say that ML is a terrible place to find decisions and we should use them for discussing things and record the decisions on something like loomio on a wiki or somewhere discoverable and canonical.</div><div><br class=""></div><div>Anyway good discussion folks, rock on QGIS! Lets be human and remember that talking to each other is a key part of being a good team for providing the much needed governance to the QGIS project. :-)</div><div><br class=""></div><div><br class=""></div><div>Regards</div><div><br class=""></div><div>Tim</div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Cheers.<br class="">-- <br class="">Paolo Cavallini - <a href="http://www.faunalia.eu" class="">www.faunalia.eu</a><br class=""><a href="http://QGIS.ORG" class="">QGIS.ORG</a> Chair:<br class=""><a href="http://planet.qgis.org/planet/user/28/tag/qgis%20board/" class="">http://planet.qgis.org/planet/user/28/tag/qgis%20board/</a><br class="">_______________________________________________<br class="">Qgis-psc mailing list<br class="">Qgis-psc@lists.osgeo.org<br class="">https://lists.osgeo.org/mailman/listinfo/qgis-psc</div></div></blockquote></div><br class=""><div class="">
<span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none; font-size: 18px;"> </span><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;"><span><img apple-inline="yes" id="B796F67D-3498-41E5-BFA1-6E2E66BC9655" src="cid:B67F6A36-B856-4FD5-91BC-5BDE8990D373" class=""></span><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none; font-size: 12px; font-variant-ligatures: normal; font-variant-position: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; line-height: normal; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div style="font-weight: normal;" class=""><br class="Apple-interchange-newline"><br class="Apple-interchange-newline"><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">---</div><div style="font-weight: normal;" class=""><br class=""></div><div class=""><b class="">Tim Sutton</b></div><div style="font-weight: normal;" class=""><a href="mailto:tim@qgis.org" class="">tim@qgis.org</a></div><div style="font-weight: normal;" class=""><br class=""></div></div><br class="Apple-interchange-newline" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none; font-size: 12px; font-variant-ligatures: normal; font-variant-position: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; line-height: normal;"><br class="Apple-interchange-newline" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none; font-size: 12px; font-variant-ligatures: normal; font-variant-position: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal;">
</span></div>
<br class=""></div></body></html>