[Qgis-psc] Documentation meeting? Was: Toughts after November PSC
Anita Graser
anitagraser at gmx.at
Tue Nov 26 07:43:40 PST 2019
Feel free to proceed without me. I'll try to make joining possible if it's
during office hours but I cannot guarantee that I'll make it.
Regards,
Anita
On Tue, Nov 26, 2019 at 4:29 PM Paolo Cavallini <cavallini at faunalia.it>
wrote:
> 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/
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20191126/712ae212/attachment.html>
More information about the Qgis-psc
mailing list