[Qgis-psc] Documentation meeting? Was: Toughts after November PSC
Paolo Cavallini
cavallini at faunalia.it
Mon Nov 25 04:28:20 PST 2019
I prepared a Doodle, le't find a date:
https://doodle.com/poll/znd5ywwxtcwcmg49
cheers
Il 25/11/19 13:19, Tim Sutton ha scritto:
> Hi
>
>
>
>> On 23 Nov 2019, at 17:14, Alexandre Neto <senhor.neto at gmail.com
>> <mailto:senhor.neto at gmail.com>> wrote:
>>
>> Hi,
>>
>> Sorry for the thread hijacking.
>>
>> Regarding the Documentation, as Tim mentioned, video meetings are
>> probably much more productive (and clarifying about others opinions)
>> than enumerous threads and long messages in the mailing lists.
>>
>> This being said, can I suggest doing a special PSC meeting (or
>> something similar) together with the most active or interest members
>> of the documentation team, for us to agree on some strategies going
>> forward?
>
> +1 from me, great idea!
>
> Regards
>
> Tim
>
>>
>> Thanks,
>>
>> Alexandre Neto
>>
>> A sexta, 22/11/2019, 07:00, Tim Sutton <tim at kartoza.com
>> <mailto:tim at kartoza.com>> escreveu:
>>
>> Hi
>>
>>
>>> On 21 Nov 2019, at 16:36, Paolo Cavallini <cavallini at faunalia.it
>>> <mailto:cavallini at faunalia.it>> wrote:
>>>>
>>>> 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).
>>>
>>> of course cost is an issue. using and designing infrastructures
>>> that are
>>> complex, essentially in the hand of a single person, difficult or
>>> impossible to handle for others, is a major concern to me.
>>> the key point here is openness: I think we should avoid making the
>>> project less open than it could be.
>>
>>
>>
>> 8< ———— snip
>>
>>>
>>>>
>>>> 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?
>>>
>>> Of course, running costs, once approved, should not be discussed
>>> every
>>> time. I see a number of projects, however, that have been financed as
>>> special projects, and could be very well have been run through a
>>> public
>>> assessment.
>>> again, I'm talking about openness: directing things top down may seem
>>> more efficient at first, but I believe in the long run it is not.
>>
>>
>> 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.
>>
>> 8< —————snip ——————
>>>
>>>> * due to connection issues, I've not clear what the outcome
>>>> of the
>>>> Documentation discussion was; I made my proposal [0], I would
>>>> appreciate
>>>> further comments on it so we can start working on a clear
>>>> solution
>>>>
>>>>
>>>> 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.
>>>
>>> I see this issue keep on attracting little interest. I suggest
>>> keeping
>>> on discussing about this on the mailing list
>>
>> 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.
>>
>>
>>
>>>
>>>> * we need simple rules for adding news, even though a degree of
>>>> flexibility is useful; cen we agree on [1]?
>>
>>
>> From your original list:
>>
>> 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.
>>
>>
>>
>> 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 blog.qgis.org
>> <http://blog.qgis.org/> which is the ‘voice of the project’ - we
>> never really had any problem with what should and shouldn’t go on
>> there…..
>>
>>
>>
>>>>
>>>>
>>>> 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.
>>>
>>> IMHO we should decide whatever is possible here in the mailing list,
>>> leaving PSC meeting for the most complex issues, that require a
>>> proper
>>> discussion in voice. I think most issues can be solved in writing.
>>> I remember the good old IRC meetings, very good for many
>>> decisions, less
>>> so for general discussion.
>>
>>
>> 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.
>>
>>
>>> IMHO PSC meetings are lasting too long, and are not a very
>>> efficient way
>>> of making decisions. Having just one meeting once a month does
>>> not help
>>> taking timely and efficient decisions.
>>
>> 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’.
>>
>> 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.
>>
>> 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.
>>
>>
>>>
>>>> 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.
>>>
>>> I think we can vote here for most issues.
>>> In short, I propose to put forward all the issues here on the ML, and
>>> leave to the voice meetings what we were unable to solve during
>>> the month.
>>
>> 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.
>>
>> 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. :-)
>>
>>
>> Regards
>>
>> Tim
>>
>>
>>
>>>
>>> Cheers.
>>> --
>>> Paolo Cavallini - www.faunalia.eu <http://www.faunalia.eu/>
>>> QGIS.ORG <http://qgis.org/> Chair:
>>> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
>>> _______________________________________________
>>> Qgis-psc mailing list
>>> Qgis-psc at lists.osgeo.org <mailto:Qgis-psc at lists.osgeo.org>
>>> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>>
>>
>>
>>
>>
>>
>> ---
>>
>> *Tim Sutton*
>> tim at qgis.org <mailto:tim at qgis.org>
>>
>>
>>
>>
>> _______________________________________________
>> Qgis-psc mailing list
>> Qgis-psc at lists.osgeo.org <mailto:Qgis-psc at lists.osgeo.org>
>> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>>
>> <qgis-icon-60x60.png>_______________________________________________
>> Qgis-psc mailing list
>> Qgis-psc at lists.osgeo.org <mailto:Qgis-psc at lists.osgeo.org>
>> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>
> —
>
>
>
>
>
>
>
>
> *Tim Sutton*
>
> *Co-founder:* Kartoza
> *Ex Project chair:* QGIS.org <http://QGIS.org>
>
> Visit http://kartoza.com <http://kartoza.com/> to find out about open
> source:
>
> Desktop GIS programming services
> Geospatial web development
> GIS Training
> Consulting Services
>
> *Skype*: timlinux
> *IRC:* timlinux on #qgis at freenode.net <http://freenode.net>
>
> I'd love to connect. Here's my calendar link
> <https://calendly.com/timlinux> to make finding time easy.
>
>
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>
--
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
More information about the Qgis-psc
mailing list