Toughts after November PSC

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Toughts after November PSC

pcav
Hi all,
I think it is useful to point out some thoughts about QGIS.ORG, stemming
from yesterday PSC meeting, out for general discussion.
My considerations:
* we should always prefer for our infrastructure simple and libre
solutions over complicated and proprietary ones, to promote openness and
cooperation within the community and keep the entry barrier low
* we should prefer to finance projects useful for the advancement of the
project through our very successful Grant programme, leaving direct
financing of special projects by PSC to really special cases; on the
other hand, I propose the PSC can give its recommendations as to which
grant proposals are most useful for the project, leaving the discussion
and the final decision to the community
* all payments (grants, projects, travel reimbursements, documentation
work, etc.) should be done only after a report has been published in a
central stable place (a single web page, a collection of it): it should
be easy for anybody to check what has been done, how much it costed, etc.
* 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
* we need simple rules for adding news, even though a degree of
flexibility is useful; cen we agree on [1]?
Your thoughts will be greatly appreciated.
All the best.

[0] https://lists.osgeo.org/pipermail/qgis-psc/2019-November/007849.html
[1] https://lists.osgeo.org/pipermail/qgis-psc/2019-October/007796.html
--
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Toughts after November PSC

Andreas Neumann-3
Hi Paolo,

Thanks for sharing your thoughts. I have some comments inline.

On Wed, 20 Nov 2019 at 13:34, Paolo Cavallini <[hidden email]> wrote:
Hi all,
I think it is useful to point out some thoughts about QGIS.ORG, stemming
from yesterday PSC meeting, out for general discussion.
My considerations:
* we should always prefer for our infrastructure simple and libre
solutions over complicated and proprietary ones, to promote openness and
cooperation within the community and keep the entry barrier low

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).
 
* we should prefer to finance projects useful for the advancement of the
project through our very successful Grant programme, leaving direct
financing of special projects by PSC to really special cases; on the
other hand, I propose the PSC can give its recommendations as to which
grant proposals are most useful for the project, leaving the discussion
and the final decision to the community

Here I clearly disagree with you. I think the grant program is wonderful for how we use it now. But not all of our projects need or should go through this grant program. The grant program is a way for our community members and contributors to suggest a project from their own ideas. Typically these ideas come from outside of the PSC.

I think it is very useful to set aside a significant amount of our income to these grant projects. It helps our community and allows for contributors outside the PSC to be better involved and often enables projects that otherwise would be hard to get funding for. The whole grant process takes at the very least 2-3 months to process. So it isn't well suited for stuff that needs to be decided quickly.

On the other hand we have infrastructure projects that, if implemented, make our life as PSC or certain core contributors easier. Such projects would not trigger a lot of popularity or excitement among our community or wider user base. Yet - they are really useful

If you run a government or small municipality (more comparable to our QGIS community), you typically have several budgets: one for recurrent expenses that you know or can estimate upfront, one kind of a "buffer" budget for expenses around PSC and our QGIS IT infrastructure that you kind of know and expect but don't know much upfront when these expenses have to be made and how much they will cost upfront, and a third part for long-term strategic investments and extra projects (like a new school in a municipality or a new sports infrastructure, new waste-water treatment plant, etc.).

My idea of these different types of budgets is:

- First budget of recurring expenses: proposed by PSC based on experience from past years and suggestions from the community. QGIS voting member approve budget and final accounting with the help of our two auditors.
- Second one "the buffer budgets for unexpected expenses around PSC and our QGIS IT infrastructure" that arise and often need to be spent rather quickly: should be at the discretion of the PSC. I don't see a need to run these projects through QGIS grants. If the PSC decides that these are useful and necessary, there is no big value to first run them through our voting members. Of course there need to be limits on such expenses.
- Third one: extra projects and long-term strategic investments. For these expenses it clearly is the right thing to run those through our grants program and let voting members decide on them, ideally with some discussion upfront.

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?
 
* all payments (grants, projects, travel reimbursements, documentation
work, etc.) should be done only after a report has been published in a
central stable place (a single web page, a collection of it): it should
be easy for anybody to check what has been done, how much it costed, etc.

That is partially already the case, but maybe not at a central case.

- For bug fixing we publish all of our paid fixes in our visual changelog.
- Outcome of grants is often documented somewhere, but often at a company's webpage or blog. I agree that it would be more useful to publish those results e.g. in our official QGIS blog.
- Travel reimbursements: Ideally there could be a curated blog post after each contributor meeting. The difficult thing is to find a volunteer to coordinate this. But I see the value more to have it documented what happened at the meeting rather than knowing how these were been financed exactly and who got reimbursements and who not. Most of our expenses for contributor meetings go into the dinners, venue and catering anyway, parts of the funds go to individual people for travel expenses.
- Projects: like grant projects they can be published in our blog post.
 
* 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.
 
* we need simple rules for adding news, even though a degree of
flexibility is useful; cen we agree on [1]?

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.

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.

Thanks,
Andreas


_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Toughts after November PSC

pcav
Hi Andreas,

Il 21/11/19 09:12, Andreas Neumann ha scritto:

> Hi Paolo,
>
> Thanks for sharing your thoughts. I have some comments inline.
>
> On Wed, 20 Nov 2019 at 13:34, Paolo Cavallini <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi all,
>     I think it is useful to point out some thoughts about QGIS.ORG
>     <http://QGIS.ORG>, stemming
>     from yesterday PSC meeting, out for general discussion.
>     My considerations:
>     * we should always prefer for our infrastructure simple and libre
>     solutions over complicated and proprietary ones, to promote openness and
>     cooperation within the community and keep the entry barrier low
>
>
> 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.

>     * we should prefer to finance projects useful for the advancement of the
>     project through our very successful Grant programme, leaving direct
>     financing of special projects by PSC to really special cases; on the
>     other hand, I propose the PSC can give its recommendations as to which
>     grant proposals are most useful for the project, leaving the discussion
>     and the final decision to the community
>
>
> Here I clearly disagree with you. I think the grant program is wonderful
> for how we use it now. But not all of our projects need or should go
> through this grant program. The grant program is a way for our community
> members and contributors to suggest a project from their own ideas.
> Typically these ideas come from outside of the PSC.
>
> I think it is very useful to set aside a significant amount of our
> income to these grant projects. It helps our community and allows for
> contributors outside the PSC to be better involved and often enables
> projects that otherwise would be hard to get funding for. The whole
> grant process takes at the very least 2-3 months to process. So it isn't
> well suited for stuff that needs to be decided quickly.
>
> On the other hand we have infrastructure projects that, if implemented,
> make our life as PSC or certain core contributors easier. Such projects
> would not trigger a lot of popularity or excitement among our community
> or wider user base. Yet - they are really useful
>
> If you run a government or small municipality (more comparable to our
> QGIS community), you typically have several budgets: one for recurrent
> expenses that you know or can estimate upfront, one kind of a "buffer"
> budget for expenses around PSC and our QGIS IT infrastructure that you
> kind of know and expect but don't know much upfront when these expenses
> have to be made and how much they will cost upfront, and a third part
> for long-term strategic investments and extra projects (like a new
> school in a municipality or a new sports infrastructure, new waste-water
> treatment plant, etc.).
>
> My idea of these different types of budgets is:
>
> - First budget of recurring expenses: proposed by PSC based on
> experience from past years and suggestions from the community. QGIS
> voting member approve budget and final accounting with the help of our
> two auditors.
> - Second one "the buffer budgets for unexpected expenses around PSC and
> our QGIS IT infrastructure" that arise and often need to be spent rather
> quickly: should be at the discretion of the PSC. I don't see a need to
> run these projects through QGIS grants. If the PSC decides that these
> are useful and necessary, there is no big value to first run them
> through our voting members. Of course there need to be limits on such
> expenses.
> - Third one: extra projects and long-term strategic investments. For
> these expenses it clearly is the right thing to run those through our
> grants program and let voting members decide on them, ideally with some
> discussion upfront.
>
> 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.

>     * all payments (grants, projects, travel reimbursements, documentation
>     work, etc.) should be done only after a report has been published in a
>     central stable place (a single web page, a collection of it): it should
>     be easy for anybody to check what has been done, how much it costed,
>     etc.
>
>
> That is partially already the case, but maybe not at a central case.
>
> - For bug fixing we publish all of our paid fixes in our visual changelog.
> - Outcome of grants is often documented somewhere, but often at a
> company's webpage or blog. I agree that it would be more useful to
> publish those results e.g. in our official QGIS blog.
> - Travel reimbursements: Ideally there could be a curated blog post
> after each contributor meeting. The difficult thing is to find a
> volunteer to coordinate this. But I see the value more to have it
> documented what happened at the meeting rather than knowing how these
> were been financed exactly and who got reimbursements and who not. Most
> of our expenses for contributor meetings go into the dinners, venue and
> catering anyway, parts of the funds go to individual people for travel
> expenses.
> - Projects: like grant projects they can be published in our blog post.

the point to me is to have everything in a single location; in the
current situation the information may be there, but it is difficult to
have a general picture, and to find what one is looking for. so I'm
suggesting at the completion of each work, before paying for it, a
report should be put in a predictable place, easy to find. then this can
be echoed in blog posts, over social networks, more details can be
added, including nice screenshots atc, but the essentials should be there

>     * 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

>     * we need simple rules for adding news, even though a degree of
>     flexibility is useful; cen we agree on [1]?
>
>
> 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.
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.

> 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.

Cheers.
--
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Toughts after November PSC

Anita Graser
Hi, 

On Thu, Nov 21, 2019 at 5:36 PM Paolo Cavallini <[hidden email]> wrote:
Il 21/11/19 09:12, Andreas Neumann ha scritto:
> On Wed, 20 Nov 2019 at 13:34, Paolo Cavallini <[hidden email]
> <mailto:[hidden email]>> wrote:
   * we should always prefer for our infrastructure simple and libre solutions ...
> Right. If possible and doesn't trigger a lot of followup costs...
... I think we should avoid making the project less open than it could be.

I agree on the general sentiment. However, which specific topic from this week's meeting is making us potentially less open?

> My idea of these different types of budgets is:
>
> - First budget of recurring expenses: ...
> - Second one "the buffer budgets for unexpected expenses around PSC and
> our QGIS IT infrastructure" ...
> - Third one: extra projects and long-term strategic investments. ...

+1 to this budget structure based on all the arguments Andreas already provided.

The budget is approved by voting members. If they think think that the grant budget should be bigger and the buffer budget should be smaller, they have the opportunity to decide on this issue every year.

> I agree that it would be more useful to
> publish those results e.g. in our official QGIS blog.

I can prepare a template that we can send to people who received grants as an optional help for structuring their report. It shouldn't be long, just a few lines and links to relevant resource.

the point to me is to have everything in a single location;

Do have have a suggestion? More folders in Google Drive? Everything on the blog or wiki? 
One option could be that a link to the report has to be put on a certain wiki page.

> 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. 
 
That's a bit unfair assessment. We were waiting for you to bring up the topic and the meeting already ran over time as is.

>     * we need simple rules for adding news, even though a degree of
>     flexibility is useful; cen we agree on [1]?

I suggest making a motion to vote on it. As far as I can see, the last post ended with "Anything to add?" - Nobody replied, so there's nothing to add. Therefore, after a couple of days, a motion to vote should be made.

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.

I'm in favor of shorter meetings. To get there, however, we need people to follow up on their threads and make timely calls for votes instead of leaving discussions open ended. Whoever starts the thread should usually make the motion to vote when the discussion is done.

Regards,
Anita







 

_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Toughts after November PSC

Tim Sutton-6
In reply to this post by pcav
Hi


On 21 Nov 2019, at 16:36, Paolo Cavallini <[hidden email]> 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 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
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc

 




---

Tim Sutton





_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Documentation meeting? Was: Toughts after November PSC

Alexandre Neto
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?

Thanks,

Alexandre Neto

A sexta, 22/11/2019, 07:00, Tim Sutton <[hidden email]> escreveu:
Hi


On 21 Nov 2019, at 16:36, Paolo Cavallini <[hidden email]> 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 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
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc

 




---

Tim Sutton




_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc

_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc

qgis-icon-60x60.png (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Documentation meeting? Was: Toughts after November PSC

pcav
OLa Alexandre,

Il 2019-11-23 18:14 Alexandre Neto ha scritto:
> 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?

agreed, let's make a list of interested people and we'll find a time
slot for it.
Cheers.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Documentation meeting? Was: Toughts after November PSC

ghtmtt
In reply to this post by Alexandre Neto
Hi Alexandre,

sounds like a good idea. I'm available this week. Feel free to propose a
datetime

Cheers and thanks

Matteo
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Documentation meeting? Was: Toughts after November PSC

Alexandre Neto
Hi Matteo,

Let's see what the PSC members say. AFAIK they have their own set of meetings (and jobs) to go to. Besides, my current week is a bit messy.

To me the PSC presence is very important, as we already had our share of "isolated" meetings/discussions.

Looking forward for it.

Alexandre Neto

_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Documentation meeting? Was: Toughts after November PSC

Tim Sutton-6
In reply to this post by Alexandre Neto
Hi



On 23 Nov 2019, at 17:14, Alexandre Neto <[hidden email]> 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 <[hidden email]> escreveu:
Hi


On 21 Nov 2019, at 16:36, Paolo Cavallini <[hidden email]> 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 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
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc

 




---

Tim Sutton




_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
<qgis-icon-60x60.png>_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc









Tim Sutton

Co-founder: Kartoza
Ex Project chair: QGIS.org

Visit 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

I'd love to connect. Here's my calendar link to make finding time easy.


_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Documentation meeting? Was: Toughts after November PSC

pcav
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 <[hidden email]
>> <mailto:[hidden email]>> 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 <[hidden email]
>> <mailto:[hidden email]>> escreveu:
>>
>>     Hi
>>
>>
>>>     On 21 Nov 2019, at 16:36, Paolo Cavallini <[hidden email]
>>>     <mailto:[hidden email]>> 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
>>>     [hidden email] <mailto:[hidden email]>
>>>     https://lists.osgeo.org/mailman/listinfo/qgis-psc
>>
>>      
>>
>>
>>
>>
>>     ---
>>
>>     *Tim Sutton*
>>     [hidden email] <mailto:[hidden email]>
>>
>>
>>
>>
>>     _______________________________________________
>>     Qgis-psc mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     https://lists.osgeo.org/mailman/listinfo/qgis-psc
>>
>> <qgis-icon-60x60.png>_______________________________________________
>> Qgis-psc mailing list
>> [hidden email] <mailto:[hidden email]>
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Documentation meeting? Was: Toughts after November PSC

pcav
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 <[hidden email]
>>> <mailto:[hidden email]>> 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 <[hidden email]
>>> <mailto:[hidden email]>> escreveu:
>>>
>>>     Hi
>>>
>>>
>>>>     On 21 Nov 2019, at 16:36, Paolo Cavallini <[hidden email]
>>>>     <mailto:[hidden email]>> 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
>>>>     [hidden email] <mailto:[hidden email]>
>>>>     https://lists.osgeo.org/mailman/listinfo/qgis-psc
>>>
>>>      
>>>
>>>
>>>
>>>
>>>     ---
>>>
>>>     *Tim Sutton*
>>>     [hidden email] <mailto:[hidden email]>
>>>
>>>
>>>
>>>
>>>     _______________________________________________
>>>     Qgis-psc mailing list
>>>     [hidden email] <mailto:[hidden email]>
>>>     https://lists.osgeo.org/mailman/listinfo/qgis-psc
>>>
>>> <qgis-icon-60x60.png>_______________________________________________
>>> Qgis-psc mailing list
>>> [hidden email] <mailto:[hidden email]>
>>> 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
>> [hidden email]
>> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Documentation meeting? Was: Toughts after November PSC

Anita Graser
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 <[hidden email]> 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 <[hidden email]
>>> <mailto:[hidden email]>> 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 <[hidden email]
>>> <mailto:[hidden email]>> escreveu:
>>>
>>>     Hi
>>>
>>>
>>>>     On 21 Nov 2019, at 16:36, Paolo Cavallini <[hidden email]
>>>>     <mailto:[hidden email]>> 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
>>>>     [hidden email] <mailto:[hidden email]>
>>>>     https://lists.osgeo.org/mailman/listinfo/qgis-psc
>>>
>>>      
>>>
>>>
>>>
>>>
>>>     ---
>>>
>>>     *Tim Sutton*
>>>     [hidden email] <mailto:[hidden email]>
>>>
>>>
>>>
>>>
>>>     _______________________________________________
>>>     Qgis-psc mailing list
>>>     [hidden email] <mailto:[hidden email]>
>>>     https://lists.osgeo.org/mailman/listinfo/qgis-psc
>>>
>>> <qgis-icon-60x60.png>_______________________________________________
>>> Qgis-psc mailing list
>>> [hidden email] <mailto:[hidden email]>
>>> 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
>> [hidden email]
>> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc

_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Documentation meeting? Was: Toughts after November PSC

pcav
Hi Anita, all
maybe a different schedule will improve participation.
Alexandre, as first proponent, would you like to consult with key people
and propose a different timing?
Cheers.

Il 26/11/19 16:43, Anita Graser ha scritto:

> 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 <[hidden email]
> <mailto:[hidden email]>> 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 <[hidden email]
>     <mailto:[hidden email]>
>     >>> <mailto:[hidden email] <mailto:[hidden email]>>>
>     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 <[hidden email]
>     <mailto:[hidden email]>
>     >>> <mailto:[hidden email] <mailto:[hidden email]>>> escreveu:
>     >>>
>     >>>     Hi
>     >>>
>     >>>
>     >>>>     On 21 Nov 2019, at 16:36, Paolo Cavallini
>     <[hidden email] <mailto:[hidden email]>
>     >>>>     <mailto:[hidden email]
>     <mailto:[hidden email]>>> 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>
>     >>>     <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>
>     <http://www.faunalia.eu/>
>     >>>>     QGIS.ORG <http://QGIS.ORG> <http://qgis.org/> Chair:
>     >>>>     http://planet.qgis.org/planet/user/28/tag/qgis%20board/
>     >>>>     _______________________________________________
>     >>>>     Qgis-psc mailing list
>     >>>>     [hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>
>     >>>>     https://lists.osgeo.org/mailman/listinfo/qgis-psc
>     >>>
>     >>>      
>     >>>
>     >>>
>     >>>
>     >>>
>     >>>     ---
>     >>>
>     >>>     *Tim Sutton*
>     >>>     [hidden email] <mailto:[hidden email]> <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     >>>
>     >>>
>     >>>
>     >>>
>     >>>     _______________________________________________
>     >>>     Qgis-psc mailing list
>     >>>     [hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>
>     >>>     https://lists.osgeo.org/mailman/listinfo/qgis-psc
>     >>>
>     >>> <qgis-icon-60x60.png>_______________________________________________
>     >>> Qgis-psc mailing list
>     >>> [hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>
>     >>> 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>
>     <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
>     >> [hidden email] <mailto:[hidden email]>
>     >> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>     >>
>     >
>
>     --
>     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
>     [hidden email] <mailto:[hidden email]>
>     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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Documentation meeting? Was: Toughts after November PSC

Alexandre Neto
Hi all,

I think key people are those that have pronounced in the past in regards to documentation and those that work on it regularly.

This being said, maybe we can redo the doodle for the next two weeks.

What is the normal time and week day of psc meetings? That may help.

Thanks,

Alexandre Neto


A terça, 26/11/2019, 16:09, Paolo Cavallini <[hidden email]> escreveu:
Hi Anita, all
maybe a different schedule will improve participation.
Alexandre, as first proponent, would you like to consult with key people
and propose a different timing?
Cheers.

Il 26/11/19 16:43, Anita Graser ha scritto:
> 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 <[hidden email]
> <mailto:[hidden email]>> 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 <[hidden email]
>     <mailto:[hidden email]>
>     >>> <mailto:[hidden email] <mailto:[hidden email]>>>
>     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 <[hidden email]
>     <mailto:[hidden email]>
>     >>> <mailto:[hidden email] <mailto:[hidden email]>>> escreveu:
>     >>>
>     >>>     Hi
>     >>>
>     >>>
>     >>>>     On 21 Nov 2019, at 16:36, Paolo Cavallini
>     <[hidden email] <mailto:[hidden email]>
>     >>>>     <mailto:[hidden email]
>     <mailto:[hidden email]>>> 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>
>     >>>     <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>
>     <http://www.faunalia.eu/>
>     >>>>     QGIS.ORG <http://QGIS.ORG> <http://qgis.org/> Chair:
>     >>>>     http://planet.qgis.org/planet/user/28/tag/qgis%20board/
>     >>>>     _______________________________________________
>     >>>>     Qgis-psc mailing list
>     >>>>     [hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>
>     >>>>     https://lists.osgeo.org/mailman/listinfo/qgis-psc
>     >>>
>     >>>      
>     >>>
>     >>>
>     >>>
>     >>>
>     >>>     ---
>     >>>
>     >>>     *Tim Sutton*
>     >>>     [hidden email] <mailto:[hidden email]> <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     >>>
>     >>>
>     >>>
>     >>>
>     >>>     _______________________________________________
>     >>>     Qgis-psc mailing list
>     >>>     [hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>
>     >>>     https://lists.osgeo.org/mailman/listinfo/qgis-psc
>     >>>
>     >>> <qgis-icon-60x60.png>_______________________________________________
>     >>> Qgis-psc mailing list
>     >>> [hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>
>     >>> 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>
>     <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
>     >> [hidden email] <mailto:[hidden email]>
>     >> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>     >>
>     >
>
>     --
>     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
>     [hidden email] <mailto:[hidden email]>
>     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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc

_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Documentation meeting? Was: Toughts after November PSC

Andreas Neumann-4

Hi Alex,

The normal time for PSC meetings is 20:00 CET. This allows people who work voluntary on QGIS (I guess the majority) and who have a day job to participate.

However, this fits everyone except Paolo. Tim also prefers an hour earlier, as far as I know.

Andreas

Am 27.11.19 um 23:18 schrieb Alexandre Neto:
Hi all,

I think key people are those that have pronounced in the past in regards to documentation and those that work on it regularly.

This being said, maybe we can redo the doodle for the next two weeks.

What is the normal time and week day of psc meetings? That may help.

Thanks,

Alexandre Neto


A terça, 26/11/2019, 16:09, Paolo Cavallini <[hidden email]> escreveu:
Hi Anita, all
maybe a different schedule will improve participation.
Alexandre, as first proponent, would you like to consult with key people
and propose a different timing?
Cheers.

Il 26/11/19 16:43, Anita Graser ha scritto:
> 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 <[hidden email]
> <mailto:[hidden email]>> 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 <[hidden email]
>     <mailto:[hidden email]>
>     >>> <mailto:[hidden email] <mailto:[hidden email]>>>
>     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 <[hidden email]
>     <mailto:[hidden email]>
>     >>> <mailto:[hidden email] <mailto:[hidden email]>>> escreveu:
>     >>>
>     >>>     Hi
>     >>>
>     >>>
>     >>>>     On 21 Nov 2019, at 16:36, Paolo Cavallini
>     <[hidden email] <mailto:[hidden email]>
>     >>>>     <mailto:[hidden email]
>     <mailto:[hidden email]>>> 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>
>     >>>     <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>
>     <http://www.faunalia.eu/>
>     >>>>     QGIS.ORG <http://QGIS.ORG> <http://qgis.org/> Chair:
>     >>>>     http://planet.qgis.org/planet/user/28/tag/qgis%20board/
>     >>>>     _______________________________________________
>     >>>>     Qgis-psc mailing list
>     >>>>     [hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>
>     >>>>     https://lists.osgeo.org/mailman/listinfo/qgis-psc
>     >>>
>     >>>      
>     >>>
>     >>>
>     >>>
>     >>>
>     >>>     ---
>     >>>
>     >>>     *Tim Sutton*
>     >>>     [hidden email] <mailto:[hidden email]> <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     >>>
>     >>>
>     >>>
>     >>>
>     >>>     _______________________________________________
>     >>>     Qgis-psc mailing list
>     >>>     [hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>
>     >>>     https://lists.osgeo.org/mailman/listinfo/qgis-psc
>     >>>
>     >>> <qgis-icon-60x60.png>_______________________________________________
>     >>> Qgis-psc mailing list
>     >>> [hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>
>     >>> 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 
>     >> *<a class="moz-txt-link-freetext" href="IRC:*">IRC:* timlinux on #qgis at freenode.net <http://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
>     >> [hidden email] <mailto:[hidden email]>
>     >> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>     >>
>     >
>
>     --
>     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
>     [hidden email] <mailto:[hidden email]>
>     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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc

_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc

_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Documentation meeting? Was: Toughts after November PSC

ghtmtt
In reply to this post by Alexandre Neto
Hi all,

Harrissou and Havard are the most active contributors, a meeting without
them is useless IMHO (of course if both can/want to join the call).

Cheers

Matteo

_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Documentation meeting? Was: Toughts after November PSC

Alexandre Neto
+1

A quinta, 28/11/2019, 11:44, matteo <[hidden email]> escreveu:
Hi all,

Harrissou and Havard are the most active contributors, a meeting without
them is useless IMHO (of course if both can/want to join the call).

Cheers

Matteo

_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc

_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Documentation meeting? Was: Toughts after November PSC

DelazJ
Hi people,
Sorry, I forgot to check this list the last days.

I'm of course interested in a meeting about docs and will try to be available (easier for me at lunch time and after 6 pm, except Wednesday. Also note that we are organizing the French qgis-user meeting in two weeks (12-13) so that end of week could be complicated for me).
But from what I understand about the doc meeting subject, we better need people out of the "Core" contributors. People that are documenting QGIS around and how we could involve them in a shared project. Or did I misunderstand and a clearer topics list would hence be welcome.
This is to say that imho my presence should not be a requirement. If there are enough people interested in giving a new look/heart/orientation to QGIS official docs, please do the meeting. I'll read the notes if ever I were absent.
And to get those people (and this was my unclear question in the doodle form), I think the psc list is not the right place for a call. Since the main parts of the discussions were held in the doc list (aka qgis-community) and there are likely more people involved (or who could be) in that place, let's do the next invitation there. Piers message is an example and I'm not sure that Håvard either subscribed to this list.

Regards,

Harrissou


Le 28 novembre 2019 20:24:14 GMT+01:00, Alexandre Neto <[hidden email]> a écrit :
+1

A quinta, 28/11/2019, 11:44, matteo <[hidden email]> escreveu:
Hi all,

Harrissou and Havard are the most active contributors, a meeting without
them is useless IMHO (of course if both can/want to join the call).

Cheers

Matteo

_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc

--
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Documentation meeting? Was: Toughts after November PSC

Alexandre Neto
Hi Harrissou,

I was the one that suggested the meeting. I did it, because it seems that the PSC has been discussing the Documentation "struggle" and trying to find solutions for it. Out of it there were some proposals. Because in open source world proposals worth nothing unless people agree with them, I believe that the most active members of the documentation team (mostly you and Håvart) need to be present.

The idea is beetween the PSC, the docs "team" and any other interested parties we set some kind of strategy that would allow us to have good and updated documentation for QGIS.

This being said, although the meeting should be open to everyone, you two are crucial, lMHO. The same for the members of the PSC.

I will set a new doodle for the next two weeks. I will remove the less voted hours and had some in the evening.

Thank,

Alex Neto

A sábado, 30/11/2019, 09:41, Harrissou <[hidden email]> escreveu:
Hi people,
Sorry, I forgot to check this list the last days.

I'm of course interested in a meeting about docs and will try to be available (easier for me at lunch time and after 6 pm, except Wednesday. Also note that we are organizing the French qgis-user meeting in two weeks (12-13) so that end of week could be complicated for me).
But from what I understand about the doc meeting subject, we better need people out of the "Core" contributors. People that are documenting QGIS around and how we could involve them in a shared project. Or did I misunderstand and a clearer topics list would hence be welcome.
This is to say that imho my presence should not be a requirement. If there are enough people interested in giving a new look/heart/orientation to QGIS official docs, please do the meeting. I'll read the notes if ever I were absent.
And to get those people (and this was my unclear question in the doodle form), I think the psc list is not the right place for a call. Since the main parts of the discussions were held in the doc list (aka qgis-community) and there are likely more people involved (or who could be) in that place, let's do the next invitation there. Piers message is an example and I'm not sure that Håvard either subscribed to this list.

Regards,

Harrissou


Le 28 novembre 2019 20:24:14 GMT+01:00, Alexandre Neto <[hidden email]> a écrit :
+1

A quinta, 28/11/2019, 11:44, matteo <[hidden email]> escreveu:
Hi all,

Harrissou and Havard are the most active contributors, a meeting without
them is useless IMHO (of course if both can/want to join the call).

Cheers

Matteo

_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc

--
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.

_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
12