[Qgis-psc] Next meeting and some thoughts on our approach to project governance

[Tim Sutton]

Hi All

(with apologies for the length of this mail)

1) Next meeting

According to our consensus (thanks Anita) our next meeting is on Mon 7 March. I have started an agenda here:

https://docs.google.com/a/qgis.org/document/d/1arzcgoU0NErm8yiqDvCeasFUdr9zt-8JUx15f3ivTdw/edit?usp=sharing

(you should all be able to edit that doc since the folder is shared with you)

2) Proposed change in the meeting format

I am proposing to add a new item on the agenda which is a 3 minute per person round table update. The thinking behind this is that we spend a lot of time in meetings diving into one specific topic usually and not enough time on more high level stuff (like what is happening in the different spheres of the project). I think it would be very good to use the meeting as an opportunity to rather focus on the general state of QGIS and our governance efforts and encourage breakouts into special purpose meetings when some deep diving into a topic is needed. So for example if Otto wanted to go into detail on some documentation plans or issues he would just advertise on the PSC meeting that he would like to have an offline meeting about it. Then the participants would go off and make their decisions and report back to the PSC about it, or if they can’t agree, come back to the PSC for help in deciding it.

I’ve been doing a lot of reflection these last weeks about what constitutes good governance for the project and how we can do a better job as a PSC (prompted by some very good discussions with Andreas and Richard - thanks!). I think we have somehow made our decision making processes much more cumbersome than they need to be - very often there is someone already with a clear idea of what needs to be done and a few of us that have some ideas to contribute and a few that don’t have much to add to a particular decision. It will be IMHO much better if we could step back a bit and rather use the PSC meeting as a platform to identify what decisions need to be made, then delegate those decisions to our members. Assuming others agree, adding more of a roundtable approach to our meeting format could be a valuable first step in achieving a shift toward a more devolved decision making process.

3) Keeping / restoring the balance of community vs. commercial activity, coders vs non coders

I’ve also been thinking a lot about what we can do to maintain a good sense of community while still embracing the increasing amount of commercial activity that happens around the QGIS project. It seems like we are at risk that the commercial activity around QGIS will drive down and eventually out community based contributions. As Marco and others have pointed out, the overhead for ‘just for fun’ hacking on QGIS and subsequent contributions from the community is becoming higher all the time - and not just in the areas of coding, but in other areas too. Also there is I think some inequality in the way that we treat coders vs. non coders in the community. If you just look for example at the proportion of our funds that go to coders versus non coders you can see this. I think generally coders get more exposure and accolades that other contributors. This is one of the reasons I was initially opposed to e.g. acknowledging specific people in the changelogs for a long time - it effectively ignores all of the contributions made by other community members and focusses only on the world done by coders and their funders. Perhaps on this latter point we should start inviting the translators, documentation writers, forum helpers, sysadmin etc. teams to add entries to the changelog outlining the major activities that have taken place over the release - though I appreciate it is often hard to quantify how some of those activities have contributed to the release.

In our last meeting we discussed the idea of ‘QGIS Grants’ (thanks Paolo for coming up with the name for it), and I was wondering if we could extend this idea out away from purely developer focussed grants to cover other areas:

* bug triage
* translation work
* documentation
* infrastructure 
* QA
* UX
* etc.

I was thinking one way to address this might be to actually create budgets per major role (docs, QA, release management, infrastructure etc.) and then allow the PSC representative to identify the best way to use their part of the budget (still in a transparent way). So for example, Jurgen as release manager might want to spend some funds on better build hardware or something, Otto as documentation manager might want to fund documentation cleanup work via a small grant… and so on… I know our budget is not large, and doing this will also reduce the amount of funds available for bug fixing, but it would ensure that we get a more even spread of funded activity and perhaps de-emphasis the kind of thinking that goes:  ‘why should I fix bugs, there are already others being paid to do it’.

Perhaps the ideas above do not sit well, but I am happy enough if they get shot down if you all get you thinking about other ways we could find a good balance between community and commercial activity and perhaps can offer better alternatives.



Regards

Tim






Tim Sutton
QGIS Project Steering Committee Member
tim at qgis.org




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20160217/6665686a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 9882 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20160217/6665686a/attachment.tiff>