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

Tue Feb 16 23:48:15 PST 2016

Hi, 

Tim, thank you for raising these issues. 

I agree with point 2) where you propose to delegate some decisions to
the PSC members who work on a certain part of the project. They can do
ad-hoc meetings with other people in the community (not necessarily only
board members) to come up with a decision, if they are unsure about
their decision. 

about 3) 

My personal take on this is that I am not a talented coder. I dedicate
my time and partially also personal funds to the project so the ones who
are talented core developers can dedicate their time fully to bug fixing
and coding and don't have to deal with stuff they are less interested
in. So my personal goal is to get a better QGIS from release to release
- and therefore in my personal view it is quite ok if more funds go into
bug fixing, coding, QA, etc. because other areas in the project can more
easily be filled by volunteers. There are potentially more people who
can contribute to documentation, UI and graphics work, community work,
marketing, website, project management, etc. than there are talented
core developers who have a good overview of the whole code base. 

Note - that this is my own personal opinion - and maybe not the majority
view of the board. 

I totally agree with Tim that funds should be spread in different areas
of the project. But the people working in these different areas need to
come up with a clear proposal how to spend these funds. They can
approach the board with a project. We should encourage that more. 

A while back we did a survey and asked our users (who are also our
funders) how they want the funds to be spent. Unfortunately we did not
really discuss the results of this survey - which I regret. I post some
of the results here
(https://docs.google.com/forms/d/1G6p3QFUJBfxv3ySnryDRGMmF-e7PHWUOwrGo9OH2Yog/viewanalytics):

1. Important features that are missing: 50%
2. More bug fixing: 24.1%
3. Improved user documentation: 12.4%
4. Automated tesing when new features are added: 8.7%
5. Improved programmer documentation: 4.9% 

Now we - as the board - know that we also need to also spend our funds
on the server infrastructure, dev meetings, etc. - which we already do.
But our users also have their opinion that they want a majority of the
funds go into coding and QA. Currently, we don't spend anything on 1),
most of our funds go into 2), a little bit into 3) (mainly due to a lack
of requests for funded documentation work - we have more budgeted for
documentation than we spend), we did fund the Processing testsuite (4))
and unfortunately 5) did not materialize due to a lack of interest of
people wanting to dedicate their work on API and Python documentation. 

The "QGIS grant" idea can probably help to support 1-2 people to
concentrate on the above listed 5 issues. To avoid a lot of
dicussion/steering work/bureaucracy, etc. we can select people we trust
that they use their time for the best of the project. 

I think it makes sense to focus our funds a bit on fewer projects or
only 1-2 grant people rather than using the "Giesskannenprinzip"
(watering-can principle ?) We do that in the Swiss QGIS user group. We
select two projects each year to support and for the other projects that
don't get selected we either try to get different volunteers/sponsors or
delay the project. 

------------------------- 

There was also the idea to spend some of our funds into UI work - UI
review. I think this would be a very good idea. We would just have to
overcome the following issues: 

- it should be a long-term commitment, otherwise it doesn't help too
much. A good UI designer needs to accompany the core devs over many
months/years, not just in a single review. 

- a UI group should probably first list our major issues - similar to
https://community.kde.org/Kdenlive/UI_Review [1]- again - I think
focusing on a part of the UI helps more than trying to fix everything at
once and then probably fail 

- good UI people are quite expensive - so we should find either a
volunteer or partial volunteer as we do with the bug fixers. We could
partially pay the efforts so a person can fully dedicate a week or two
to UI reviewng - but the remaining work has to be done voluntarily.
Unless we can find a good sponsor. 

------------- 

Greetings, 

Andreas 

On 2016-02-16 23:34, Tim Sutton wrote: 

> 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 
> 
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-psc

Links:
------
[1] https://community.kde.org/Kdenlive/UI_Review
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20160217/9b180b29/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/9b180b29/attachment.tiff>