
<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<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 25 Nov 2019, at 11:14, Andreas Neumann <<a href="mailto:a.neumann@carto.net" class="">a.neumann@carto.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class=""><div style="font-size: 10pt; font-family: Verdana,Geneva,sans-serif" class=""><p class="">Hi Paolo,</p><p class="">Thanks for your suggestions for improvements.</p>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">About that secretary: do you want a permanent role for the secretary or would we define a "scribe"/secretary for each meeting? Of course, giving the nature of Google Docs, it would still be useful for everyone being able to write stuff into the document. And if the secretary is quite a lot involved in a certain discussion, it would be useful if someone else steps in for minuting. So we all should be a attentive and step in for others.</div></div></div></blockquote><div><br class=""></div><div>Yeah I quite like it when we all collaboratively edit the document - it results in something more balanced than just one person reaffirming their personal bias by putting what they thing is important into a document. It goes back a little to what I said in my previous email: we should all attend the meeting with our laptops in front of us so that we can see the agenda and contribute to the notes. Maybe the role of secretary could be more of a nominal role of someone who ensures the document is maintained in a consistent way (I like proposal, notes, votes) for each agenda item, and that each discussion point is documented and the doc link is added to the wiki page.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-size: 10pt; font-family: Verdana,Geneva,sans-serif" class=""><p class="">My comments are below:</p><p id="reply-intro" class="">On 2019-11-22 14:25, Paolo Cavallini wrote:</p>

<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0" class="">

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Hi all,<br class="">here my proposal to improve the functioning of the PSC.<br class=""><br class="">Decision making<br class="">=================<br class="">* one PSC member raise on the PSC mailing list a topic to be decided<br class="">* if the proponent believes the discussion in ML is sufficient, he calls<br class="">for a vote<br class="">* if not, he adds the point to the next PSC voice meeting, where it will<br class="">be discussed and voted<br class="">* once voted, he passes the decision to the Secretary, who adds the<br class="">resolution to the list of resolutions (see below)</div>

</blockquote>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Sounds all good to me.</div></div></div></blockquote><div><br class=""></div><div><br class=""></div><div>As noted before, I am -1 for recording holding votes in mailing lists. Can we not just test and use the voting platform we set up in projects (where the QGIS changelog is kept). I am happy to work to resolve any issues that may be preventing us from using it. We could also do similar work to what Richard did for the sustaining member feed and changelogs, to pull the summary of motions and decisions onto a PSC decisions page on the web site. This way we can remove all the manual drudge work from the process.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-size: 10pt; font-family: Verdana,Geneva,sans-serif" class="">

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0" class="">

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"><br class=""><br class="">Meetings<br class="">=========<br class="">* regular meeting once a month, at a fixed date<br class="">* ad hoc short meetings can be called anytime, to discuss single issues<br class="">and to have faster decisions and avoid too long regular meetings; only a<br class="">subset of the PSC members can be present at the ad hoc meetings, if they<br class="">are not interested in that specific topic; their vote will be counted as +0<br class="">* every meeting will have a Chair, normally the PSC Chair, and a<br class="">Secretary, who will have the responsibility for completing the minutes</div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

</blockquote>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Sounds good</div></div></div></blockquote><div><br class=""></div><div>Right this is no change from how things are already except for the last bullet where we formalise who is chair and scribe at the start of each meeting. If your connection is bad it is going to make it difficult for you to effectively chair the meetings, so may be good to think about Andreas’ previous comments. I’m afraid to suggest it, but maybe we should try one_more_time on doodle to find an optimal time for the call that works for everyone so that Paolo can be in a quiet place with a good connection?</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-size: 10pt; font-family: Verdana,Geneva,sans-serif" class="">

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0" class="">

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"><br class=""><br class="">List of resolutions<br class="">====================<br class="">* each resolution will be listed according to a simple template:<br class="">Date of voting<br class="">Proponent<br class="">Rationale<br class="">Votes<br class="">Decision<br class="">Notes<br class="">* all resolutions will be added to a single location#</div>

</blockquote></div></div></blockquote><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-size: 10pt; font-family: Verdana,Geneva,sans-serif" class=""><blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0" class=""><div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

</blockquote>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Public on our website? On Github or in a central Google Docs document?</div>

</div></div></blockquote><div><br class=""></div><div>I wonder if the resolutions in our minutes have a different significance to things we vote on formally? For me they kinda do. I don’t think we need to e.g. publish to the list of historical decisions the fact that we asked PSC member to go and speak to group A and report their findings back their findings to the PSC in the next meeting. So maybe we could have some kind of simple split of ‘public decisions’ e.g. PSC resolved to remove QGIS 1.x from the download archive (which we would vote for on project with a link to the vote from the minutes) and ‘house keeping’ decisions e.g. PSC ask Bob to speak to Joe about Al (which we would record in the google doc in a format like above).</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-size: 10pt; font-family: Verdana,Geneva,sans-serif" class=""><div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0" class="">

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"><br class=""><br class="">Reporting<br class="">==========<br class="">* for each expenditure, before payment, a report must be completed by<br class="">the proponent, according to a simple template:<br class="">Date of resolution<br class="">Date of delivery<br class="">Proponent<br class="">Description of results<br class="">Eventual links to full description, commit etc.<br class="">Evaluation (success, partial success, failure)<br class="">* for recurring costs, only the initial report should be done<br class="">* all reports will be added to a single location#</div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

</blockquote>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Again - here I think we need some flexibility. I very much agree for QGIS grant projects, other large projects or contributor meetings. But for other work, such as for packaging, bug queue management, PR + code reviews, etc. - I don't think we gain much with such reports.</div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0" class="">

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"><br class=""><br class="">To Do list<br class="">===========<br class="">* a list of tasks to be completed will be maintained and available on<br class="">the web#<br class="">* for each item it will be listed:<br class="">Date of proposal<br class="">Deadline<br class="">Proponent<br class="">Responsible<br class="">Description<br class="">Notes<br class="">Status (standby, in progress, completed)</div>

</blockquote>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">We already have todo lists in our meeting minutes. Do we need an additional one? Maybe a central one would be useful to avoid duplication in the meeting minutes. So the meeting minutes would point to the central TODO file - right?</div></div></div></blockquote><div><br class=""></div><div>Yeah we already keep a rolling TODO list in the PSC notes - TODO items get rolled forward if not done into the next meeting doc and I would prefer just one place to look. Using Paolo’s proposed TODO format sounds good to me.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-size: 10pt; font-family: Verdana,Geneva,sans-serif" class="">

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0" class="">

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"><br class=""><br class=""><br class=""># I propose to add all documents to<br class=""><a href="https://github.com/qgis/QGIS-Website/tree/master/source/site/getinvolved/governance" target="_blank" rel="noopener noreferrer" class="">https://github.com/qgis/QGIS-Website/tree/master/source/site/getinvolved/governance</a><br class="">and compiled into the main website, as this is simple and easy to<br class="">search, also in the long term.<br class="">Minutes IMHO can stay in a dynamic infrastructure, like GDocs, where the<br class="">advantages of communal editing are evident.</div></blockquote></div></div></blockquote><div><br class=""></div><div>-1 on this for me - its a lot of work unless we are using a feed system like my suggestion above for Voting. We already have an archive of all the meeting docs in the wiki here: <a href="https://github.com/qgis/QGIS/wiki#psc-meeting-minutes" class="">https://github.com/qgis/QGIS/wiki#psc-meeting-minutes</a> which I think many people are already aware of and the list is easy to maintain. We can just link to that page on the PSC pages if we haven’t already. Basically I would like to avoid anything that involves regular editing of our web site sphinx project :-P</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-size: 10pt; font-family: Verdana,Geneva,sans-serif" class=""><blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0" class="">

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

</blockquote>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">Sounds reasonable. So everything (TODO, decisions, etc.) would basically be public?</div></div></div></blockquote><div><br class=""></div><div>Yes I am big +1 for keeping everything public.</div><div><br class=""></div><div>Thanks for this Paolo!</div><div><br class=""></div><div>Regards</div><div><br class=""></div><div>Tim</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-size: 10pt; font-family: Verdana,Geneva,sans-serif" class="">

<div class="pre" style="margin: 0; padding: 0; font-family: monospace"> </div>

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">What to do the others think?</div><p class="">Greetings,</p><p class="">Andreas</p>


</div>

_______________________________________________<br class="">Qgis-psc mailing list<br class=""><a href="mailto:Qgis-psc@lists.osgeo.org" class="">Qgis-psc@lists.osgeo.org</a><br class="">https://lists.osgeo.org/mailman/listinfo/qgis-psc</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="B33D3E70-2155-4596-A933-6145CF63808A" 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=""></body></html>