[Qgis-psc] Documentation meeting? Was: Toughts after November PSC
Paolo Cavallini
cavallini at faunalia.it
Tue Nov 26 07:29:39 PST 2019
Hi all,
unfortunately it seems very difficult to have >5 people attending.
Should we postpone of another week? Would this make participation easier?
Cheers.
Il 25/11/19 13:28, Paolo Cavallini ha scritto:
> 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