Improving the functioning of PSC

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

Improving the functioning of PSC

pcav
Hi all,
here my proposal to improve the functioning of the PSC.

Decision making
=================
* one PSC member raise on the PSC mailing list a topic to be decided
* if the proponent believes the discussion in ML is sufficient, he calls
for a vote
* if not, he adds the point to the next PSC voice meeting, where it will
be discussed and voted
* once voted, he passes the decision to the Secretary, who adds the
resolution to the list of resolutions (see below)

Meetings
=========
* regular meeting once a month, at a fixed date
* ad hoc short meetings can be called anytime, to discuss single issues
and to have faster decisions and avoid too long regular meetings; only a
subset of the PSC members can be present at the ad hoc meetings, if they
are not interested in that specific topic; their vote will be counted as +0
* every meeting will have a Chair, normally the PSC Chair, and a
Secretary, who will have the responsibility for completing the minutes

List of resolutions
====================
* each resolution will be listed according to a simple template:
Date of voting
Proponent
Rationale
Votes
Decision
Notes
* all resolutions will be added to a single location#

Reporting
==========
* for each expenditure, before payment, a report must be completed by
the proponent, according to a simple template:
Date of resolution
Date of delivery
Proponent
Description of results
Eventual links to full description, commit etc.
Evaluation (success, partial success, failure)
* for recurring costs, only the initial report should be done
* all reports will be added to a single location#

To Do list
===========
* a list of tasks to be completed will be maintained and available on
the web#
* for each item it will be listed:
Date of proposal
Deadline
Proponent
Responsible
Description
Notes
Status (standby, in progress, completed)


# I propose to add all documents to
https://github.com/qgis/QGIS-Website/tree/master/source/site/getinvolved/governance
and compiled into the main website, as this is simple and easy to
search, also in the long term.
Minutes IMHO can stay in a dynamic infrastructure, like GDocs, where the
advantages of communal editing are evident.
--
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: Improving the functioning of PSC

Andreas Neumann-4

Hi Paolo,

Thanks for your suggestions for improvements.

About that secretary: do you want a permanent role for the secretary or would we define a "scribe"/secretary for each meeting? Of course, giving the nature of Google Docs, it would still be useful for everyone being able to write stuff into the document. And if the secretary is quite a lot involved in a certain discussion, it would be useful if someone else steps in for minuting. So we all should be a attentive and step in for others.

My comments are below:

On 2019-11-22 14:25, Paolo Cavallini wrote:

Hi all,
here my proposal to improve the functioning of the PSC.

Decision making
=================
* one PSC member raise on the PSC mailing list a topic to be decided
* if the proponent believes the discussion in ML is sufficient, he calls
for a vote
* if not, he adds the point to the next PSC voice meeting, where it will
be discussed and voted
* once voted, he passes the decision to the Secretary, who adds the
resolution to the list of resolutions (see below)
 
Sounds all good to me.
 
 


Meetings
=========
* regular meeting once a month, at a fixed date
* ad hoc short meetings can be called anytime, to discuss single issues
and to have faster decisions and avoid too long regular meetings; only a
subset of the PSC members can be present at the ad hoc meetings, if they
are not interested in that specific topic; their vote will be counted as +0
* every meeting will have a Chair, normally the PSC Chair, and a
Secretary, who will have the responsibility for completing the minutes
 
 
Sounds good
 


List of resolutions
====================
* each resolution will be listed according to a simple template:
Date of voting
Proponent
Rationale
Votes
Decision
Notes
* all resolutions will be added to a single location#
 
 
Public on our website? On Github or in a central Google Docs document?
 
 


Reporting
==========
* for each expenditure, before payment, a report must be completed by
the proponent, according to a simple template:
Date of resolution
Date of delivery
Proponent
Description of results
Eventual links to full description, commit etc.
Evaluation (success, partial success, failure)
* for recurring costs, only the initial report should be done
* all reports will be added to a single location#
 
 
Again - here I think we need some flexibility. I very much agree for QGIS grant projects, other large projects or contributor meetings. But for other work, such as for packaging, bug queue management, PR + code reviews, etc. - I don't think we gain much with such reports.
 


To Do list
===========
* a list of tasks to be completed will be maintained and available on
the web#
* for each item it will be listed:
Date of proposal
Deadline
Proponent
Responsible
Description
Notes
Status (standby, in progress, completed)
 
We already have todo lists in our meeting minutes. Do we need an additional one? Maybe a central one would be useful to avoid duplication in the meeting minutes. So the meeting minutes would point to the central TODO file - right?
 



# I propose to add all documents to
https://github.com/qgis/QGIS-Website/tree/master/source/site/getinvolved/governance
and compiled into the main website, as this is simple and easy to
search, also in the long term.
Minutes IMHO can stay in a dynamic infrastructure, like GDocs, where the
advantages of communal editing are evident.
 
 
Sounds reasonable. So everything (TODO, decisions, etc.) would basically be public?
 
What to do the others think?

Greetings,

Andreas


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

Re: Improving the functioning of PSC

Tim Sutton-6
Hi

On 25 Nov 2019, at 11:14, Andreas Neumann <[hidden email]> wrote:

Hi Paolo,

Thanks for your suggestions for improvements.

About that secretary: do you want a permanent role for the secretary or would we define a "scribe"/secretary for each meeting? Of course, giving the nature of Google Docs, it would still be useful for everyone being able to write stuff into the document. And if the secretary is quite a lot involved in a certain discussion, it would be useful if someone else steps in for minuting. So we all should be a attentive and step in for others.

Yeah I quite like it when we all collaboratively edit the document - it results in something more balanced than just one person reaffirming their personal bias by putting what they thing is important into a document. It goes back a little to what I said in my previous email: we should all attend the meeting with our laptops in front of us so that we can see the agenda and contribute to the notes. Maybe the role of secretary could be more of a nominal role of someone who ensures the document is maintained in a consistent way (I like proposal, notes, votes) for each agenda item, and that each discussion point is documented and the doc link is added to the wiki page.


My comments are below:

On 2019-11-22 14:25, Paolo Cavallini wrote:

Hi all,
here my proposal to improve the functioning of the PSC.

Decision making
=================
* one PSC member raise on the PSC mailing list a topic to be decided
* if the proponent believes the discussion in ML is sufficient, he calls
for a vote
* if not, he adds the point to the next PSC voice meeting, where it will
be discussed and voted
* once voted, he passes the decision to the Secretary, who adds the
resolution to the list of resolutions (see below)
 
Sounds all good to me.


As noted before, I am -1 for recording holding votes in mailing lists. Can we not just test and use the voting platform we set up in projects (where the QGIS changelog is kept). I am happy to work to resolve any issues that may be preventing us from using it. We could also do similar work to what Richard did for the sustaining member feed and changelogs, to pull the summary of motions and decisions onto a PSC decisions page on the web site. This way we can remove all the manual drudge work from the process.

 
 


Meetings
=========
* regular meeting once a month, at a fixed date
* ad hoc short meetings can be called anytime, to discuss single issues
and to have faster decisions and avoid too long regular meetings; only a
subset of the PSC members can be present at the ad hoc meetings, if they
are not interested in that specific topic; their vote will be counted as +0
* every meeting will have a Chair, normally the PSC Chair, and a
Secretary, who will have the responsibility for completing the minutes
 
 
Sounds good

Right this is no change from how things are already except for the last bullet where we formalise who is chair and scribe at the start of each meeting. If your connection is bad it is going to make it difficult for you to effectively chair the meetings, so may be good to think about Andreas’ previous comments. I’m afraid to suggest it, but maybe we should try one_more_time on doodle to find an optimal time for the call that works for everyone so that Paolo can be in a quiet place with a good connection?


 


List of resolutions
====================
* each resolution will be listed according to a simple template:
Date of voting
Proponent
Rationale
Votes
Decision
Notes
* all resolutions will be added to a single location#



 
 
Public on our website? On Github or in a central Google Docs document?

I wonder if the resolutions in our minutes have a different significance to things we vote on formally? For me they kinda do. I don’t think we need to e.g. publish to the list of historical decisions the fact that we asked PSC member to go and speak to group A and report their findings back their findings to the PSC in the next meeting. So maybe we could have some kind of simple split of ‘public decisions’ e.g. PSC resolved to remove QGIS 1.x from the download archive (which we would vote for on project with a link to the vote from the minutes) and ‘house keeping’ decisions e.g. PSC ask Bob to speak to Joe about Al (which we would record in the google doc in a format like above).


 
 


Reporting
==========
* for each expenditure, before payment, a report must be completed by
the proponent, according to a simple template:
Date of resolution
Date of delivery
Proponent
Description of results
Eventual links to full description, commit etc.
Evaluation (success, partial success, failure)
* for recurring costs, only the initial report should be done
* all reports will be added to a single location#
 
 
Again - here I think we need some flexibility. I very much agree for QGIS grant projects, other large projects or contributor meetings. But for other work, such as for packaging, bug queue management, PR + code reviews, etc. - I don't think we gain much with such reports.
 


To Do list
===========
* a list of tasks to be completed will be maintained and available on
the web#
* for each item it will be listed:
Date of proposal
Deadline
Proponent
Responsible
Description
Notes
Status (standby, in progress, completed)
 
We already have todo lists in our meeting minutes. Do we need an additional one? Maybe a central one would be useful to avoid duplication in the meeting minutes. So the meeting minutes would point to the central TODO file - right?

Yeah we already keep a rolling TODO list in the PSC notes - TODO items get rolled forward if not done into the next meeting doc and I would prefer just one place to look. Using Paolo’s proposed TODO format sounds good to me.


 



# I propose to add all documents to
https://github.com/qgis/QGIS-Website/tree/master/source/site/getinvolved/governance
and compiled into the main website, as this is simple and easy to
search, also in the long term.
Minutes IMHO can stay in a dynamic infrastructure, like GDocs, where the
advantages of communal editing are evident.

-1 on this for me - its a lot of work unless we are using a feed system like my suggestion above for Voting. We already have an archive of all the meeting docs in the wiki here: https://github.com/qgis/QGIS/wiki#psc-meeting-minutes which I think many people are already aware of and the list is easy to maintain. We can just link to that page on the PSC pages if we haven’t already. Basically I would like to avoid anything that involves regular editing of our web site sphinx project :-P


 
 
Sounds reasonable. So everything (TODO, decisions, etc.) would basically be public?

Yes I am big +1 for keeping everything public.

Thanks for this Paolo!

Regards

Tim

 
What to do the others think?

Greetings,

Andreas

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

Re: Improving the functioning of PSC

pcav
In reply to this post by Andreas Neumann-4
Hi Andreas,
thanks for your comments

Il 25/11/19 12:14, Andreas Neumann ha scritto:
> About that secretary: do you want a permanent role for the secretary or
> would we define a "scribe"/secretary for each meeting? Of course, giving
> the nature of Google Docs, it would still be useful for everyone being
> able to write stuff into the document. And if the secretary is quite a
> lot involved in a certain discussion, it would be useful if someone else
> steps in for minuting. So we all should be a attentive and step in for
> others.

I don't have a strong opinion on this, but I think having always/mostly
the same person will guarantee consistence

> My comments are below:
>
> On 2019-11-22 14:25, Paolo Cavallini wrote:
>
>> Hi all,
>> here my proposal to improve the functioning of the PSC.
>>
>> Decision making
>> =================
>> * one PSC member raise on the PSC mailing list a topic to be decided
>> * if the proponent believes the discussion in ML is sufficient, he calls
>> for a vote
>> * if not, he adds the point to the next PSC voice meeting, where it will
>> be discussed and voted
>> * once voted, he passes the decision to the Secretary, who adds the
>> resolution to the list of resolutions (see below)
>  
> Sounds all good to me.
>  
>  
>>
>>
>> Meetings
>> =========
>> * regular meeting once a month, at a fixed date
>> * ad hoc short meetings can be called anytime, to discuss single issues
>> and to have faster decisions and avoid too long regular meetings; only a
>> subset of the PSC members can be present at the ad hoc meetings, if they
>> are not interested in that specific topic; their vote will be counted
>> as +0
>> * every meeting will have a Chair, normally the PSC Chair, and a
>> Secretary, who will have the responsibility for completing the minutes
>>  
>  
> Sounds good
>  
>>
>>
>> List of resolutions
>> ====================
>> * each resolution will be listed according to a simple template:
>> Date of voting
>> Proponent
>> Rationale
>> Votes
>> Decision
>> Notes
>> * all resolutions will be added to a single location#
>>  
>  
> Public on our website? On Github or in a central Google Docs document?

see note # below

>> Reporting
>> ==========
>> * for each expenditure, before payment, a report must be completed by
>> the proponent, according to a simple template:
>> Date of resolution
>> Date of delivery
>> Proponent
>> Description of results
>> Eventual links to full description, commit etc.
>> Evaluation (success, partial success, failure)
>> * for recurring costs, only the initial report should be done
>> * all reports will be added to a single location#
>>  
>  
> Again - here I think we need some flexibility. I very much agree for
> QGIS grant projects, other large projects or contributor meetings. But
> for other work, such as for packaging, bug queue management, PR + code
> reviews, etc. - I don't think we gain much with such reports.

of course, I'll not insisting in having pointless reports; nevertheless,
a simple two lines description will add clarity for everybody, and will
be good IMHO
I'm thinking to something like: rental of new server @Hetzner for
hosting .... etc., proposed by ... and so on, not more than this.

>> To Do list
>> ===========
>> * a list of tasks to be completed will be maintained and available on
>> the web#
>> * for each item it will be listed:
>> Date of proposal
>> Deadline
>> Proponent
>> Responsible
>> Description
>> Notes
>> Status (standby, in progress, completed)
>  
> We already have todo lists in our meeting minutes. Do we need an
> additional one? Maybe a central one would be useful to avoid duplication
> in the meeting minutes. So the meeting minutes would point to the
> central TODO file - right?

exactly; I find the todo in the minutes confusing, with lots of
replication, and easy to overlook

>> # I propose to add all documents to
>> https://github.com/qgis/QGIS-Website/tree/master/source/site/getinvolved/governance
>> and compiled into the main website, as this is simple and easy to
>> search, also in the long term.
>> Minutes IMHO can stay in a dynamic infrastructure, like GDocs, where the
>> advantages of communal editing are evident.
>>  
>  
> Sounds reasonable. So everything (TODO, decisions, etc.) would basically
> be public?

yes

> What to do the others think?

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: Improving the functioning of PSC

Anita Graser
In reply to this post by Andreas Neumann-4
Hi, 

On Mon, Nov 25, 2019 at 12:14 PM Andreas Neumann <[hidden email]> wrote:

Hi Paolo,

Thanks for your suggestions for improvements.

About that secretary: do you want a permanent role for the secretary or would we define a "scribe"/secretary for each meeting? Of course, giving the nature of Google Docs, it would still be useful for everyone being able to write stuff into the document. And if the secretary is quite a lot involved in a certain discussion, it would be useful if someone else steps in for minuting. So we all should be a attentive and step in for others.

+1

My comments are below:

On 2019-11-22 14:25, Paolo Cavallini wrote:

Hi all,
here my proposal to improve the functioning of the PSC.

Decision making
=================
* one PSC member raise on the PSC mailing list a topic to be decided
* if the proponent believes the discussion in ML is sufficient, he calls
for a vote
* if not, he adds the point to the next PSC voice meeting, where it will
be discussed and voted
* once voted, he passes the decision to the Secretary, who adds the
resolution to the list of resolutions (see below)
 
Sounds all good to me.  

I would suggest that the PSC member could directly add the decision to the list of resolutions without involving a secretary. This would reduce the number of steps in the process.

Meetings
=========
* regular meeting once a month, at a fixed date
* ad hoc short meetings can be called anytime, to discuss single issues
and to have faster decisions and avoid too long regular meetings; only a
subset of the PSC members can be present at the ad hoc meetings, if they
are not interested in that specific topic; their vote will be counted as +0
* every meeting will have a Chair, normally the PSC Chair, and a
Secretary, who will have the responsibility for completing the minutes 
 
Sounds good

+1

List of resolutions
====================
* each resolution will be listed according to a simple template:
Date of voting
Proponent
Rationale
Votes
Decision
Notes
* all resolutions will be added to a single location#
 
Public on our website? On Github or in a central Google Docs document?
 
Reporting
==========
* for each expenditure, before payment, a report must be completed by
the proponent, according to a simple template:
Date of resolution
Date of delivery
Proponent
Description of results
Eventual links to full description, commit etc.
Evaluation (success, partial success, failure)
* for recurring costs, only the initial report should be done
* all reports will be added to a single location#
 
Again - here I think we need some flexibility. I very much agree for QGIS grant projects, other large projects or contributor meetings. But for other work, such as for packaging, bug queue management, PR + code reviews, etc. - I don't think we gain much with such reports.

+1 for having the exceptions that Andreas has listed. 
  
To Do list
===========
* a list of tasks to be completed will be maintained and available on
the web#
* for each item it will be listed:
Date of proposal
Deadline
Proponent
Responsible
Description
Notes
Status (standby, in progress, completed)
 
We already have todo lists in our meeting minutes. Do we need an additional one? Maybe a central one would be useful to avoid duplication in the meeting minutes. So the meeting minutes would point to the central TODO file - right?
 
# I propose to add all documents to
https://github.com/qgis/QGIS-Website/tree/master/source/site/getinvolved/governance
and compiled into the main website, as this is simple and easy to
search, also in the long term.
Minutes IMHO can stay in a dynamic infrastructure, like GDocs, where the
advantages of communal editing are evident. 
 
Sounds reasonable. So everything (TODO, decisions, etc.) would basically be public?

Would that mean that we retire the current list at https://github.com/qgis/QGIS/wiki

Anita



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

Re: Improving the functioning of PSC

pcav
Hi Anita,

Il 25/11/19 13:25, Anita Graser ha scritto:

>     On 2019-11-22 14:25, Paolo Cavallini wrote:

>>     Decision making
>>     =================
>>     * one PSC member raise on the PSC mailing list a topic to be decided
>>     * if the proponent believes the discussion in ML is sufficient, he
>>     calls
>>     for a vote
>>     * if not, he adds the point to the next PSC voice meeting, where
>>     it will
>>     be discussed and voted
>>     * once voted, he passes the decision to the Secretary, who adds the
>>     resolution to the list of resolutions (see below)
>      
>     Sounds all good to me.  
>
>
> I would suggest that the PSC member could directly add the decision to
> the list of resolutions without involving a secretary. This would reduce
> the number of steps in the process.

this is an option; I'd still prefer having someone independent from the
proponent adding it, to ensure consistency

>>     List of resolutions
>>     ====================
>>     * each resolution will be listed according to a simple template:
>>     Date of voting
>>     Proponent
>>     Rationale
>>     Votes
>>     Decision
>>     Notes
>>     * all resolutions will be added to a single location#
>      
>     Public on our website? On Github or in a central Google Docs document?

see note # below

>>     To Do list
>>     ===========
>>     * a list of tasks to be completed will be maintained and available on
>>     the web#
>>     * for each item it will be listed:
>>     Date of proposal
>>     Deadline
>>     Proponent
>>     Responsible
>>     Description
>>     Notes
>>     Status (standby, in progress, completed)
>      
>     We already have todo lists in our meeting minutes. Do we need an
>     additional one? Maybe a central one would be useful to avoid
>     duplication in the meeting minutes. So the meeting minutes would
>     point to the central TODO file - right?
>      
>>     # I propose to add all documents to
>>     https://github.com/qgis/QGIS-Website/tree/master/source/site/getinvolved/governance
>>     and compiled into the main website, as this is simple and easy to
>>     search, also in the long term.
>>     Minutes IMHO can stay in a dynamic infrastructure, like GDocs,
>>     where the
>>     advantages of communal editing are evident. 
>      
>     Sounds reasonable. So everything (TODO, decisions, etc.) would
>     basically be public?
>
>
> Would that mean that we retire the current list
> at https://github.com/qgis/QGIS/wiki

yes, IMHO they belong to our main website (which is also under revision
control).

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: Improving the functioning of PSC

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

Il 25/11/19 13:14, Tim Sutton ha scritto:

>>
>> About that secretary: do you want a permanent role for the secretary
>> or would we define a "scribe"/secretary for each meeting? Of course,
>> giving the nature of Google Docs, it would still be useful for
>> everyone being able to write stuff into the document. And if the
>> secretary is quite a lot involved in a certain discussion, it would be
>> useful if someone else steps in for minuting. So we all should be a
>> attentive and step in for others.
>
> Yeah I quite like it when we all collaboratively edit the document - it
> results in something more balanced than just one person reaffirming
> their personal bias by putting what they thing is important into a
> document. It goes back a little to what I said in my previous email: we
> should all attend the meeting with our laptops in front of us so that we
> can see the agenda and contribute to the notes. Maybe the role of
> secretary could be more of a nominal role of someone who ensures the
> document is maintained in a consistent way (I like proposal, notes,
> votes) for each agenda item, and that each discussion point is
> documented and the doc link is added to the wiki page.

I understand this point, but IMHO the end result is too messy. I think
minutes can be anything, resolutions should be very concise and clear.

>>> Decision making
>>> =================
>>> * one PSC member raise on the PSC mailing list a topic to be decided
>>> * if the proponent believes the discussion in ML is sufficient, he calls
>>> for a vote
>>> * if not, he adds the point to the next PSC voice meeting, where it will
>>> be discussed and voted
>>> * once voted, he passes the decision to the Secretary, who adds the
>>> resolution to the list of resolutions (see below)
>>  
>> Sounds all good to me.
>
>
> As noted before, I am -1 for recording holding votes in mailing lists.
> Can we not just test and use the voting platform we set up in projects
> (where the QGIS changelog is kept). I am happy to work to resolve any
> issues that may be preventing us from using it. We could also do similar
> work to what Richard did for the sustaining member feed and changelogs,
> to pull the summary of motions and decisions onto a PSC decisions page
> on the web site. This way we can remove all the manual drudge work from
> the process.

we are so few in the PSC that having a voting platform looks really
overkill to me. It will be up the proponent to resume the 6 votes in a
final mail with the outcome, then the resolution will be saved in the
website. In case of any doubt, the list messages are archived, so it's
easy to check. In general, my idea here is to simplify everything. I'm
pretty sure people outside the PSC don't understand what we are doing.

>>> Meetings
>>> =========
>>> * regular meeting once a month, at a fixed date
>>> * ad hoc short meetings can be called anytime, to discuss single issues
>>> and to have faster decisions and avoid too long regular meetings; only a
>>> subset of the PSC members can be present at the ad hoc meetings, if they
>>> are not interested in that specific topic; their vote will be counted
>>> as +0
>>> * every meeting will have a Chair, normally the PSC Chair, and a
>>> Secretary, who will have the responsibility for completing the minutes
>>>  
>>  
>> Sounds good
>
> Right this is no change from how things are already except for the last
> bullet where we formalise who is chair and scribe at the start of each
> meeting.

the other important point to me is rely more on ad hoc meetings, to keep
the monthly ones shorter and more effective

> If your connection is bad it is going to make it difficult for
> you to effectively chair the meetings, so may be good to think about
> Andreas’ previous comments. I’m afraid to suggest it, but maybe we
> should try one_more_time on doodle to find an optimal time for the call
> that works for everyone so that Paolo can be in a quiet place with a
> good connection?

this has been made clear previously: I'll participate to meetings only
when conditions are suitable.

>>> List of resolutions
>>> ====================
>>> * each resolution will be listed according to a simple template:
>>> Date of voting
>>> Proponent
>>> Rationale
>>> Votes
>>> Decision
>>> Notes
>>> * all resolutions will be added to a single location#
>
>
>
>>>  
>>  
>> Public on our website? On Github or in a central Google Docs document?
>
> I wonder if the resolutions in our minutes have a different significance
> to things we vote on formally? For me they kinda do. I don’t think we
> need to e.g. publish to the list of historical decisions the fact that
> we asked PSC member to go and speak to group A and report their findings
> back their findings to the PSC in the next meeting. So maybe we could
> have some kind of simple split of ‘public decisions’ e.g. PSC resolved
> to remove QGIS 1.x from the download archive (which we would vote for on
> project with a link to the vote from the minutes) and ‘house keeping’
> decisions e.g. PSC ask Bob to speak to Joe about Al (which we would
> record in the google doc in a format like above).

to me votes==resolutions; the 'house keeping' you mention IMHO are not
resolution, and in any case I did not mean to generally save them in the
public archive
I believe this is mostly semantics, thanks for detailing this

> Yeah we already keep a rolling TODO list in the PSC notes - TODO items
> get rolled forward if not done into the next meeting doc and I would
> prefer just one place to look. Using Paolo’s proposed TODO format sounds
> good to me.

>>> # I propose to add all documents to
>>> https://github.com/qgis/QGIS-Website/tree/master/source/site/getinvolved/governance
>>> and compiled into the main website, as this is simple and easy to
>>> search, also in the long term.
>>> Minutes IMHO can stay in a dynamic infrastructure, like GDocs, where the
>>> advantages of communal editing are evident.
>
> -1 on this for me - its a lot of work unless we are using a feed system
> like my suggestion above for Voting. We already have an archive of all
> the meeting docs in the wiki
> here: https://github.com/qgis/QGIS/wiki#psc-meeting-minutes which I
> think many people are already aware of and the list is easy to maintain.
> We can just link to that page on the PSC pages if we haven’t already.
> Basically I would like to avoid anything that involves regular editing
> of our web site sphinx project :-P

quite the contrary to me - I think adding an rst file to git takes a few
seconds, all this google stuff is just more confusing to me.

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: Improving the functioning of PSC

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

On 25 Nov 2019, at 13:21, Paolo Cavallini <[hidden email]> wrote:

   Sounds reasonable. So everything (TODO, decisions, etc.) would
   basically be public?


Would that mean that we retire the current list
at https://github.com/qgis/QGIS/wiki? 

yes, IMHO they belong to our main website (which is also under revision
control).


Just factual correction here: The wiki itself is a git repo with full version control. 

Regards

Tim

 




---

Tim Sutton





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

Re: Improving the functioning of PSC

Tim Sutton-6
Hi

On 25 Nov 2019, at 14:03, Tim Sutton <[hidden email]> wrote:

Hi

On 25 Nov 2019, at 13:21, Paolo Cavallini <[hidden email]> wrote:

   Sounds reasonable. So everything (TODO, decisions, etc.) would
   basically be public?


Would that mean that we retire the current list
at https://github.com/qgis/QGIS/wiki? 

yes, IMHO they belong to our main website (which is also under revision
control).


Just factual correction here: The wiki itself is a git repo with full version control. 

Double update :-) : The google docs we use also have versioning / history letting you see all the history of edits.

Regards

Tim


Regards

Tim

 <qgis-icon-60x60.png>




---

Tim Sutton













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: Improving the functioning of PSC

Richard Duivenvoorde
In reply to this post by Tim Sutton-6
On 25/11/2019 15.03, Tim Sutton wrote:

> Just factual correction here: The wiki itself is a git repo with full
> version control. 

Cool, did not know this. I knew Gitlab was doing that but thought Github
held this private...

Just tested/cloned, I see we should try to use relative links then in
the pages (instead of full github url's), to be able to have links that
will still work if we do something like md2html or so... Else the links
will still go to github.

Regards,

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

Re: Improving the functioning of PSC

Tim Sutton-6
Ah cool, good tip! 

A segunda, 25 de nov de 2019, 19:49, Richard Duivenvoorde <[hidden email]> escreveu:
On 25/11/2019 15.03, Tim Sutton wrote:

> Just factual correction here: The wiki itself is a git repo with full
> version control. 

Cool, did not know this. I knew Gitlab was doing that but thought Github
held this private...

Just tested/cloned, I see we should try to use relative links then in
the pages (instead of full github url's), to be able to have links that
will still work if we do something like md2html or so... Else the links
will still go to github.

Regards,

Richard Duivenvoorde
_______________________________________________
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: Improving the functioning of PSC

pcav
In reply to this post by pcav
Hi all,
a revised proposal based on previous replies and OSGeo experience.

Decision making
=================
* one PSC member raise on the PSC mailing list a topic to be decided
* if the proponent believes the discussion in ML is sufficient, he calls
for a vote
* if not, he adds the point to the next PSC voice meeting, where it will
be discussed and voted
* once voted, he passes the decision to the Secretary, who adds the
resolution to the list of resolutions (see below)

Meetings
=========
* regular meeting once a month, at a fixed date
* ad hoc short meetings are encouraged, and can be called anytime, to
discuss single issues and to have faster decisions and avoid too long
regular meetings; only a subset of the PSC members can be present at the
ad hoc meetings, if they are not interested in that specific topic;
their vote will be counted as +0
* every meeting will appoint a Chair, normally the PSC Chair, and a
Secretary (not necessarily always the same person), who will have the
responsibility for completing the minutes; cooperative editing should be
allowed

List of resolutions
====================
* each decision will be listed according to a simple template:
Date of voting
Proponent
Rationale
Votes
Decision
Notes
* all decisions will be added to a single location#

Reporting
==========
* for each expenditure, before payment, a report must be completed by
the proponent, according to a simple template:
Date of resolution
Date of delivery
Proponent
Description of results
Eventual links to full description, commit etc.
Evaluation (success, partial success, failure)
* reports can be very short in case they are simple tasks, but we aim at
completeness
* for recurring costs, only the initial report should be done
* all reports will be added to a single location#

To Do list
===========
* managed through a trouble ticketing system (GitHub or similar) that
will automatically record Proponent and Date of proposal
* for each item it will be listed a Deadline and a Responsible


# I propose to add all documents to
https://github.com/qgis/QGIS-Website/tree/master/source/site/getinvolved/governance
and compiled into the main website, as this is simple and easy to
search, also in the long term.
Minutes IMHO can stay in a dynamic infrastructure, like GDocs, where the
advantages of communal editing are evident.
--
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: Improving the functioning of PSC

Anita Graser
Hi Paolo,

Thanks for the revision! I'm wondering about the ad hoc meetings:

On Tue, Nov 26, 2019 at 3:40 PM Paolo Cavallini <[hidden email]> wrote:
* ad hoc short meetings are encouraged, and can be called anytime, to
discuss single issues and to have faster decisions and avoid too long
regular meetings; only a subset of the PSC members can be present at the
ad hoc meetings, if they are not interested in that specific topic;
their vote will be counted as +0

We'll have to see how common these become, what kind of decisions will be made there, and how ad hoc they will be organized. Will it be possible to vote without being present? We all have times when we're not available after all but we still might feel strongly about a topic.

Regards,
Anita


On Tue, Nov 26, 2019 at 3:40 PM Paolo Cavallini <[hidden email]> wrote:
Hi all,
a revised proposal based on previous replies and OSGeo experience.

Decision making
=================
* one PSC member raise on the PSC mailing list a topic to be decided
* if the proponent believes the discussion in ML is sufficient, he calls
for a vote
* if not, he adds the point to the next PSC voice meeting, where it will
be discussed and voted
* once voted, he passes the decision to the Secretary, who adds the
resolution to the list of resolutions (see below)

Meetings
=========
* regular meeting once a month, at a fixed date
* ad hoc short meetings are encouraged, and can be called anytime, to
discuss single issues and to have faster decisions and avoid too long
regular meetings; only a subset of the PSC members can be present at the
ad hoc meetings, if they are not interested in that specific topic;
their vote will be counted as +0
* every meeting will appoint a Chair, normally the PSC Chair, and a
Secretary (not necessarily always the same person), who will have the
responsibility for completing the minutes; cooperative editing should be
allowed

List of resolutions
====================
* each decision will be listed according to a simple template:
Date of voting
Proponent
Rationale
Votes
Decision
Notes
* all decisions will be added to a single location#

Reporting
==========
* for each expenditure, before payment, a report must be completed by
the proponent, according to a simple template:
Date of resolution
Date of delivery
Proponent
Description of results
Eventual links to full description, commit etc.
Evaluation (success, partial success, failure)
* reports can be very short in case they are simple tasks, but we aim at
completeness
* for recurring costs, only the initial report should be done
* all reports will be added to a single location#

To Do list
===========
* managed through a trouble ticketing system (GitHub or similar) that
will automatically record Proponent and Date of proposal
* for each item it will be listed a Deadline and a Responsible


# I propose to add all documents to
https://github.com/qgis/QGIS-Website/tree/master/source/site/getinvolved/governance
and compiled into the main website, as this is simple and easy to
search, also in the long term.
Minutes IMHO can stay in a dynamic infrastructure, like GDocs, where the
advantages of communal editing are evident.
--
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: Improving the functioning of PSC

pcav
Hi Anita,

Il 27/11/19 08:55, Anita Graser ha scritto:

> We'll have to see how common these become, what kind of decisions will
> be made there, and how ad hoc they will be organized. Will it be
> possible to vote without being present? We all have times when we're not
> available after all but we still might feel strongly about a topic.
very good point. I think we can correct this by adding the possibility
for a PSC member to block an ad hoc meeting if he feels strongly about
participating but has not a time slot available. In this case it will be
postponed to the monthly standard meeting.
How do you feel about this?
All the best.
--
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: Improving the functioning of PSC

pcav
In reply to this post by pcav
Hi all,
a third revision of the proposal based on previous replies.
I call for a vote on this.

Decision making
=================
* one PSC member raise on the PSC mailing list a topic to be decided
* if the proponent believes the discussion in ML is sufficient, he calls
for a vote
* if not, he adds the point to the next PSC voice meeting, where it will
be discussed and voted
* once voted, he passes the decision to the Secretary, who adds the
resolution to the list of resolutions (see below)

Meetings
=========
* regular meeting once a month, at a fixed date
* ad hoc short meetings are encouraged, and can be called anytime, to
discuss single issues and to have faster decisions and avoid too long
regular meetings; only a subset of the PSC members can be present at the
ad hoc meetings, if they are not interested in that specific topic;
their vote will be counted as +0. A PSC member can block an ad hoc
meeting if he feels strongly about participating but has not a time slot
available. In this case it will be postponed to the monthly standard meeting
* every meeting will appoint a Chair, normally the PSC Chair, and a
Secretary (not necessarily always the same person), who will have the
responsibility for completing the minutes; cooperative editing should be
allowed

List of resolutions
====================
* each decision will be listed according to a simple template:
Date of voting
Proponent
Rationale
Votes
Decision
Notes
* all decisions will be added to a single location#

Reporting
==========
* for each expenditure, before payment, a report must be completed by
the proponent, according to a simple template:
Date of resolution
Date of delivery
Proponent
Description of results
Eventual links to full description, commit etc.
Evaluation (success, partial success, failure)
* reports can be very short in case they are simple tasks, but we aim at
completeness
* for recurring costs, only the initial report should be done
* all reports will be added to a single location#

To Do list
===========
* managed through a trouble ticketing system (GitHub or similar) that
will automatically record Proponent and Date of proposal
* for each item it will be listed a Deadline and a Responsible


# I propose to add all documents to
https://github.com/qgis/QGIS-Website/tree/master/source/site/getinvolved/governance
and compiled into the main website, as this is simple and easy to
search, also in the long term.
Minutes IMHO can stay in a dynamic infrastructure, like GDocs, where the
advantages of communal editing are evident.
--
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: Improving the functioning of PSC

Marco Bernasocchi-2
Thanks a lot Paolo for the updated version, looks interesting

looking forward to discuss it shortly in the PSC meeting as, as this
thread proves, following decision making by email is terrible in my opinion.

Cheers

Marco

On 02.12.19 18:16, Paolo Cavallini wrote:

> Hi all,
> a third revision of the proposal based on previous replies.
> I call for a vote on this.
>
> Decision making
> =================
> * one PSC member raise on the PSC mailing list a topic to be decided
> * if the proponent believes the discussion in ML is sufficient, he calls
> for a vote
> * if not, he adds the point to the next PSC voice meeting, where it will
> be discussed and voted
> * once voted, he passes the decision to the Secretary, who adds the
> resolution to the list of resolutions (see below)
>
> Meetings
> =========
> * regular meeting once a month, at a fixed date
> * ad hoc short meetings are encouraged, and can be called anytime, to
> discuss single issues and to have faster decisions and avoid too long
> regular meetings; only a subset of the PSC members can be present at the
> ad hoc meetings, if they are not interested in that specific topic;
> their vote will be counted as +0. A PSC member can block an ad hoc
> meeting if he feels strongly about participating but has not a time slot
> available. In this case it will be postponed to the monthly standard meeting
> * every meeting will appoint a Chair, normally the PSC Chair, and a
> Secretary (not necessarily always the same person), who will have the
> responsibility for completing the minutes; cooperative editing should be
> allowed
>
> List of resolutions
> ====================
> * each decision will be listed according to a simple template:
> Date of voting
> Proponent
> Rationale
> Votes
> Decision
> Notes
> * all decisions will be added to a single location#
>
> Reporting
> ==========
> * for each expenditure, before payment, a report must be completed by
> the proponent, according to a simple template:
> Date of resolution
> Date of delivery
> Proponent
> Description of results
> Eventual links to full description, commit etc.
> Evaluation (success, partial success, failure)
> * reports can be very short in case they are simple tasks, but we aim at
> completeness
> * for recurring costs, only the initial report should be done
> * all reports will be added to a single location#
>
> To Do list
> ===========
> * managed through a trouble ticketing system (GitHub or similar) that
> will automatically record Proponent and Date of proposal
> * for each item it will be listed a Deadline and a Responsible
>
>
> # I propose to add all documents to
> https://github.com/qgis/QGIS-Website/tree/master/source/site/getinvolved/governance
> and compiled into the main website, as this is simple and easy to
> search, also in the long term.
> Minutes IMHO can stay in a dynamic infrastructure, like GDocs, where the
> advantages of communal editing are evident.

--
Marco Bernasocchi

QGIS.org Co-chair
http://berna.io

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